解耦嵌套堆栈

https://blueprints.launchpad.net/heat/+spec/decouple-nested

作为朝着更精细的架构迈出的步骤，如 convergence-engine 规范中所述，我们提出可以更有效地解耦现有 heat 架构中的嵌套堆栈。

问题描述

创建许多嵌套堆栈的树形结构会导致每次堆栈操作时，单个 heat-engine 进程都会处理整个堆栈树，并且对每个嵌套堆栈的访问都由相同的全局锁序列化（该锁用于访问顶级堆栈）。

虽然 convergence-engine 中描述的更复杂和更具侵入性的步骤仍在研究中（这可能需要一些时间，并且可能会因为下面描述的解耦而变得更简单），我们建议更有效地将嵌套堆栈与其父堆栈解耦，以便我们可以利用现有的 RPC 轮询调度来使嵌套堆栈操作（例如创建/更新/删除）能够以更可扩展的方式处理，通过将每个堆栈的工作分散到多个引擎进程或工作器上。

提议的变更

  • 重构引擎 RPC 接口，以便能够传递一些额外的参数给创建/更新操作，从而打破父堆栈和嵌套堆栈之间的现有耦合（例如传递 user_creds ID）。

  • 重构 StackResource 基类，通过 RPC 执行操作，而不是在执行生命周期操作时直接操作 parser.Stack 对象

请注意，StackResource 的重构将侧重于通过 RPC 调用执行更改堆栈状态的操作（例如，通过 IN_PROGRESS 状态异步执行的操作），而保持堆栈内省的现有代码不变。这应该允许以最小的 StackResource 子类重工来实现向新接口的风险较低的过渡。

一个可能留待未来增强的领域是在通过 RPC 触发操作后轮询 COMPLETE 状态，例如，当我们通过 RPC 调用触发嵌套堆栈创建时，我们将直接轮询 DB 等待 CREATE COMPLETE 状态在 check_create_complete 中。将来，最好等待通知以避免轮询 DB 的开销。

备选方案

等待完整的 convergence-engine 愿景成真吧，但我认为对于主要关心这些类型工作负载的用户子集来说，我们需要一个更直接的缓解计划。

实现

负责人

Steven Hardy (shardy)

里程碑

完成目标里程碑

Juno-3

工作项

  • 重构 RPC 接口

  • 将 StackResource 创建操作转换为通过 RPC 创建堆栈

  • 将 StackResource 删除操作转换为通过 RPC 删除堆栈

  • 将 StackResource 暂停操作转换为通过 RPC 暂停堆栈

  • 将 StackResource 恢复操作转换为通过 RPC 恢复堆栈

  • 将 StackResource 检查操作转换为通过 RPC 检查堆栈

  • 将 StackResource 更新操作转换为通过 RPC 更新堆栈

依赖项

没有，但这可以被认为是 convergence-engine 工作的前奏。