使 Applier 并行¶

https://blueprints.launchpad.net/watcher/+spec/parallel-applier

问题描述¶

Watcher Applier 开始执行 Action plan，其中包含一组 Actions，这些 Actions 按照顺序执行。在 planner-storage-action-plan 实现后，我们有了新的 parents 字段，该字段包含 action 的 uuid 子 action 所连接到的列表。有了 parents 字段，Watcher 可以构建有向无环图，其中每个独立的 Action 都可以并行运行，而具有某些依赖关系的操作必须满足这些依赖关系才能执行。

用例¶

作为管理员，我希望能够运行一个 Action plan，该 plan 将为每个节点（计算、网络、存储）并行启动 actions。

提议的变更¶

我们可以根据它们的 parents 启动多个并发 actions。

Watcher Applier 的工作流引擎仍然将使用 watcher_flow flow，但节点之间的边应根据 action parents 建立。没有 parents 的未链接 actions 应直接连接到 watcher_flow 并首先执行。

需要修改的主要类是 DefaultWorkFlowEngine，它定义了 actions 执行的工作流。由于 Watcher 默认 Planner 根据权重将 actions 添加到 DB（例如，所有迁移 actions 将首先添加，然后是调整大小 actions 等），Applier 将获得按权重排序的 actions，这些 actions 可以添加到 watcher_flow flow 并链接在一个 for loop 中。在这种情况下，构建有向无环图的算法应具有 O(n) 的复杂度。

这里有一些估计的伪代码，用于展示默认 planner 工作流的一部分

flow = gf.Flow("watcher_flow")
for a in actions:
    task = TaskFlowActionContainer(a, self)
    flow.add(task)
    if a.parents:
        for parent_id in action.parents:
            parent_action = get_action(actions, parent_id)
            flow.link(parent_action, action, decider=self.decider)

e = engines.load(flow)
e.run()

备选方案¶

无

数据模型影响¶

无

REST API 影响¶

无

安全影响¶

无

通知影响¶

无

其他最终用户影响¶

无

性能影响¶

由于这是一个性能相关的补丁，因此预计由于并行执行 actions 而不是顺序执行，性能会得到改善。为了减少对系统性能和稳定性的影响，最好设置最大并发数。

其他部署者影响¶

无

开发人员影响¶

无

实现¶

负责人¶

主要负责人：Alexander Chadin <a.chadin@servionica.ru>

工作项¶

修改 watcher/applier/workflow_engine/default.py 以构建新的并行工作流引擎。
更新文档。
添加适当的单元测试。

依赖项¶

https://blueprints.launchpad.net/watcher/+spec/planner-storage-action-plan

测试¶

将添加单元测试以验证这些修改。

文档影响¶

根据新的更改更新 Applier 文档。

参考资料¶

历史¶

无

使 Applier 并行化