由 Mistral Workflows 管理的自定义资源类型¶

https://blueprints.launchpad.net/heat/+spec/mistral-new-resource-type-workflow-execution

允许用户通过将他们的操作实现为 Mistral 工作流来定义自定义资源类型。

问题描述¶

Heat 资源类型由 Python 插件定义。如果用户想要管理现有插件无法处理的资源，例如 OpenStack 外部的资源，他们当前需要在某个服务器上部署软件来管理该资源。

如果我们提供一个插件，其中操作由用户定义的 Mistral 工作流处理，那么我们可以允许我们的用户在 Heat 的正常操作中管理自定义资源。

提议的变更¶

模板中将这样定义提出的资源类型

custom:
  type: OS::Mistral::ExternalResource
  properties:
    actions:
      CREATE:
        workflow: {get_resource: create_workflow}
        params:
          target: create_my_custom_thing
      UPDATE:
        workflow: {get_resource: update_workflow}
      DELETE:
        workflow: {get_resource: delete_workflow}
    input:
      foo1: 123
      foo2: 456
    replace_on_change_inputs:
      - foo2
    always_update: true

属性

actions - 操作到工作流的映射。允许的操作是 CREATE、UPDATE、DELETE、SUSPEND 和 RESUME。所有操作都是可选的。

workflow - 工作流名称或 ID

params - 要传递给 Mistral 工作流执行的参数。参数取决于工作流类型。

input - 要作为输入传递给工作流的值

replace_on_change_inputs - 一个输入名称列表，当输入值发生变化时，应该替换资源而不是就地更新。在这种情况下，我们将对替换资源运行 CREATE 工作流，然后对现有资源运行 DELETE 工作流，而不是 UPDATE 工作流。

always_update - 如果为 true，则在更新时将始终运行 UPDATE 操作，即使输入没有变化。默认值为 false。

属性

output - 工作流执行输出

对于每个 Heat 操作，资源插件将启动指定工作流的执行（如果有），并等待其完成。输出将被收集并存储在 CREATE 和 UPDATE 操作中。如果执行失败，资源操作也将失败。

如果输出包含一个名为 resource_id 的键，Heat 将将其视为资源的物理 ID。这是 get_resource 固有函数返回的值。

对于 CREATE 以外的操作，当前输出将以 heat_extresource_data 键传递到 Mistral 环境中。如果用户在 params 中已经指定了环境，那么此键将被合并。每次工作流完成时，其输出都将合并到“当前”输出中，这样就不需要每个操作都重新输出所有先前输出以避免丢失数据。

备选方案¶

很难知道一个好的名称是什么。首先，尚不清楚此资源是否属于 OS::Mistral:: 或 OS::Heat:: 命名空间。不错的名称可能包括“ExternalResource”、“CustomResource”、“WorkflowResource”。

SoftwareComponent 资源允许为每个配置指定多个操作。这里的等效项可能如下所示

properties:
  workflows:
    - actions: [CREATE]
      workflow: {get_resource: create_workflow}
    - actions: [CREATE, UPDATE]
      workflow: {get_resource: update_workflow}
    - actions: [DELETE]
      workflow: {get_resource: delete_workflow}

然而，当每个操作有多个工作流时，如何正确处理输出尚不清楚。获取第一个操作的输出？最后一个？某种组合？鉴于已经很容易从一个工作流调用另一个工作流，似乎最好将此交到用户手中，并要求他们为每个操作指定一个工作流。Mistral 专为工作流调用彼此而设计。

CloudFormation 中的等效项，AWS::CloudFormation::CustomResource 使用 Lambda 来管理外部资源，允许 Lambda 函数确定何时替换资源。如果它返回新的资源 ID，则认为资源已被替换，然后删除旧资源。在 Heat 中复制这一点将很困难 - 虽然资源可以在更新期间的任何时间引发 UpdateReplace，但没有机制可以保留更新工作流执行返回的数据并在新资源中存储它。（此外，如果替换资源不运行 CREATE 工作流，那将很奇怪。）因此，我们选择强制用户提前选择何时根据输入参数的变化来替换资源，即使这灵活性明显较低（尽管 Lambda 函数比 Mistral 工作流更容易编写，因此灵活性将伴随着巨大的复杂性）。

将来，我们可以添加一个单独的 should-update-replace 工作流步骤，以允许用户运行一个工作流，该工作流返回 True 以替换或 False 以就地更新。

实现¶

负责人¶

主要负责人: gfidente therve

里程碑¶

完成目标里程碑: pike-2

工作项¶

实现新的资源类型

依赖项¶

无。

由 Mistral 工作流管理的自定义资源类型