限制堆栈更新范围¶

https://blueprints.launchpad.net/heat/+spec/stack-update-restrict

在更新堆栈时，目前没有办法阻止更新销毁给定的资源。

问题描述¶

用户会（并且确实会）担心堆栈更新会发生奇怪的事情。update-preview 端点通过显示可能发生的情况来部分解决这个问题。预览功能的局限性在于，资源可以在任何时候引发 UpdateReplace 异常，使得在执行更新之前，无法确定更新的结果。

提议的变更¶

使用现有的 ‘update_policy’ 资源属性，让用户在更新期间保护某些资源不被替换。

如果无法满足 update_policy，heat 将把堆栈移动到 ‘UPDATE_FAILED’ 并停止。如果可能的话，应该在应用更新之前验证约束，从而在 update_policy 不正确时直接将堆栈移动到 ‘UPDATE_FAILED’。更新失败后，用户可以调整限制并重试。

update_policy 属性已经用于 CloudFormation 自动伸缩首选项，这些首选项嵌套在 “AutoScalingScheduledAction” 和 “AutoScalingRollingUpdate” 键中。CFN 首选项将不受 HOT 版本 update policy 的影响。

用户将为每个资源指定更新可以有多激进。这些限制可以是关于完全不更新资源，或者只是关于销毁资源（包括 UpdateReplace）。

基本情况如下

限制销毁/替换
限制非破坏性更新
限制两者
不限制任何内容
完全省略 update_policy

这些限制的键将嵌套在一个 ‘actions’ 键中，如下所示。

resources:
  myresource:
    type: Foo::Bar::Baz
    update_policy:
      allow:
        update: <bool>
        replace: <bool>

嵌套允许的操作的原因是为了避免在未来用户想要限制更多操作时添加顶层键。

用户可以通过更新资源模板来添加或删除限制。新的限制将对当前更新有效。例如，如果某个资源原本会被替换，但如果在当前更新中添加了 update policy，则该资源将被保护。

在嵌套堆栈中，可能会出现冲突的指令。如果内部资源具有 “replace: true”，但外部范围具有 “replace: false”，则 heat 将把堆栈转移到 UPDATE_FAILED，以便将问题呈现给用户。

备选方案¶

处理冲突指令的另一种方法可能是遵守最保守的适用策略。这种方法对用户来说会更加混乱，因此让更新失败会更好。

限制堆栈更新范围

限制堆栈更新范围¶

问题描述¶

提议的变更¶

备选方案¶

陷阱¶

实现¶

负责人¶

里程碑¶

工作项¶

依赖项¶

heat-specs 0.0.1.dev353

页面内容