跳转到： 导航, 搜索

结构化状态管理

起草人: Harlowja

修订于：2013年5月25日，Harlowja

原理

从资源获取和修改的临时状态和状态转换转向更明确、更有组织的的状态管理系统。这个新的状态管理系统将拥有先进、闪亮的新特性，例如比当前系统更高的稳定性、自动恢复机制和更大的可扩展性（以及更多！）。

定义

状态
某人或某物在特定时间所处的特定条件：“实例请求的状态”。
状态转换
通过在状态上应用一个函数来改变状态（该函数可以接收输入并提供输出），从而产生一个新的状态。
任务
在给定状态上应用状态转换。
工作流程
工作流程通过一系列的行政/其他流程，从启动到完成。
状态管理引擎
安排或控制元素以实现期望整体效果的个人或实体。

试图解决的问题

  • 提高状态和状态转换的 ['可扩展性', '可恢复性', '可靠性', '稳定性']。
  • 使添加、调试、审查、测试、理解和验证现有和新的状态和状态转换更容易。
  • 消除难以发现的状态和转换依赖关系和交互。
  • 确保状态转换由一个实体正确可靠地完成，该实体的唯一职责是正确可靠地执行这些转换。
  • 解决以前通过临时补丁解决的各种问题。
  • 消除当前临时工作流程的固有脆弱性。
  • 允许在不需稍后手动清理这些操作的情况下，升级云/软件并进行进行中的操作。
  • 可以以统一的方式审计和跟踪在给定资源上执行的状态转换。
    • 注意：目前存在通知、日志记录、事件报告作为不同的机制（这些机制并非以统一的方式使用）。
  • 消除了某些类型的周期性任务的需求，这些任务随着集群的扩大而消耗越来越多的资源。
  • 朝着行动在中断事件（节点故障、资源故障、网络故障等）时自动恢复的道路发展。
  • 消除了周期性任务清理垃圾（孤立的实例/资源/任务...）的需求。
  • 为在发生错误时更可靠和自动的恢复过程奠定了基础。
  • 鼓励使用更['复杂', '自定义', '实验性']的工作流程来['更改', '扩展']默认工作流程。

解决已知需求

Blueprints

相关论文

相关 Wiki

潜在需求

https://etherpad.openstack.org/task-system

峰会讨论

Havana 峰会

计划

步骤 1

创建原型

  1. 创建核心工作流/任务库，并在 nova 中使用该库对 run_instance 操作进行原型设计。
  2. 将此操作（重构）拆分为小的原子任务块（暂时不要追求完美，因为这是一个原型）。
  3. 将块组织成一个工作流并测试工作流。
  4. 在峰会期间展示工作原型（以及相关文档...）。

步骤 2

  1. 从参与创建它的人员 + 其他感兴趣方那里获取原型反馈。
  2. 从峰会获取反馈。
  3. 从邮件列表 + 其他感兴趣方那里获取更多反馈。
  4. 组建一个感兴趣的团队，他们希望帮助推进原型设计原则和在其他核心项目中的使用。

步骤 3

  1. 选择单个第一个目标项目来使用新的 taskflow 库。
  2. 在所述项目中孵化 taskflow 库，使用来自原型的部分。
    1. 从一开始就让其他活跃项目参与进来（以便可以轻松地在这些项目中使用的库）。
  3. 通过使用它来完成一个关键工作流程，在所述单个第一个目标项目中证明库。
    1. 调整所述目标项目中的工作流程，分块使用所述库。
  4. 调整每个小块的测试（取决于它更改的内容）并为新功能添加新的测试。
  5. 将块提交到 http://review.openstack.org（在准备好启用之前禁用整个/部分组件？）。

步骤 4

  1. 将 taskflow 库（以及相关的测试）移动到 oslo。

步骤 5

  1. 选择另一个流程并在所述第一个项目中重构它和/或选择另一个感兴趣的项目来处理所述流程。
  2. 使用所述库将此其他流程拆分为小块。
  3. 调整每个小块的单元测试（取决于它更改的内容）并为新功能添加新的测试。
  4. 将块提交到 http://review.openstack.org（在准备好启用之前禁用整个/部分组件？）。
  5. 漂洗并重复。

原型

https://github.com/Yahoo/NovaOrc

设计

New-arch.png

工作流程

Run workflow.png

更多细节！

参见：结构化状态管理细节

参见：结构化工作流原语

参与：结构化工作流

检索自 "https://wiki.openstack.org/w/index.php?title=StructuredStateManagement&oldid=23471"