面向操作的软件配置¶

https://blueprints.launchpad.net/heat/+spec/action-aware-sw-config

Heat 资源具有明确定义的生命周期，处理 CREATE、DELETE、SUSPEND、RESUME 和 UPDATE 等生命周期操作。Heat 模板中的软件组件应遵循相同的生命周期感知，并允许用户为上述操作提供配置钩子。

问题描述¶

使用当前 Heat 软件编排的设计，通过 SoftwareConfig 资源定义的“软件组件”仅允许指定一种配置（例如，一个脚本）。然而，通常情况下，软件组件的生命周期很难用单个脚本来表达。例如，必须安装软件（创建），应该支持暂停/恢复处理，并且应该能够允许删除逻辑。这与 Heat 资源的一般生命周期一致。

为了实现期望的行为，即在当前设计中拥有所有这些生命周期钩子，人们不得不定义多个 SoftwareConfig 资源以及多个 SoftwareDeployment 资源，每个资源处理一个特定的生命周期操作。或者，人们必须以这样一种方式设计自动化脚本，使其能够有条件地处理每个生命周期操作。这两种选择都缺乏一定的直观性，或者给自动化脚本的创建带来了复杂性。通过使软件组件像其他 Heat 资源一样感知操作，从而利用 Heat 引擎更多的编排能力，可以简化用户软件配置自动化和相应的 Heat 模板的创建。

提议的变更¶

建议通过允许用户为所有标准 Heat 生命周期操作（CREATE、DELETE、SUSPEND、RESUME、UPDATE）为单个软件组件提供配置脚本，从而使软件组件（通过 SoftwareComponent 和 SoftwareDeployment 资源定义）感知生命周期操作。这些集体属于一个软件组件（例如，Tomcat Web 服务器、MySQL 数据库）的配置可以在一个地方定义（即，一个 *SoftwareComponent* 资源），并且可以通过单个 SoftwareDeployment 资源关联到服务器。

新的 SoftwareComponent 资源将 - 类似于 SoftwareConfig 资源 - 不会获得任何新的行为，但它也将是软件配置数据的静态存储。与 SoftwareConfig 相比，它将扩展为在一个地方提供多个与 Heat 生命周期操作对应的配置，并遵循明确定义的结构，以便 SoftwareDeployment 资源与实例中的代理结合使用，从而以生命周期感知的方式进行操作。

新的 SoftwareComponent 资源¶

建议实现一个新的资源类型 OS::Heat::SoftwareComponent，它类似于现有的 SoftwareConfig 资源，但具有更丰富的结构和语义。或者，我们可以选择扩展现有的“SoftwareConfig”资源，但过载的语义可能会导致用户混淆。此外，扩展现有资源可能会在维护与 SoftwareConfig 的现有用途的向后兼容性时带来额外的复杂性。

OS::Heat::SoftwareComponent 的属性集如下

# HOT representation of new SoftwareComponent resource

sw-config:
  type: OS::Heat::SoftwareComponent
  properties:
    # per action configurations
    configs:
      - actions: [ string, ... ]
        config: string
        tool: string
      - actions: [ string, ... ]
        config: string
        tool: string
      # ...
    # inputs and outputs
    inputs: [ ... ]
    outputs: [ ... ]
    options: { ... }

configs 属性是软件组件的各种生命周期操作的配置列表。该列表中的每个条目定义以下属性

actions

此属性定义了应用相应配置的资源操作列表。该列表中可能的值对应于 Heat 资源模型的生命周期操作（即 CREATE、DELETE、SUSPEND、RESUME 和 UPDATE）。将此属性设置为操作列表允许在需要时为多个资源操作重用一个配置。例如，用于部署某些软件的 Chef 脚本（即 CREATE 操作）也可以用于处理软件配置属性的更新（即 UPDATE 操作）。

注意：一个操作，例如 CREATE，仅允许出现在最多一个配置的 actions 属性中。否则，在运行时针对一个生命周期操作的多个配置的顺序将不明确。此约束将在 SoftwareComponent 资源的 validate() 方法中进行验证。允许一个操作出现在多个配置中（可能带有额外的顺序注释）是可以作为未来工作来完成的。

config

此属性定义要应用的实际配置，类似于 OS::Heat::SoftwareConfig 的 config 属性。

tool

此属性指定要使用的配置工具。请注意，这类似于 SoftwareConfig 资源的 group 属性，但建议在此处使用更直观的名称。为每个配置条目提供 tool 属性允许在一个软件组件中混合使用不同的配置工具。例如，软件部署（即 CREATE）可以使用 Chef 或 Puppet 完成，但简单的脚本可以用于 SUSPEND 或 RESUME。

inputs 和 outputs 属性将为完整的 SoftwareComponent 定义定义为全局的，而不是为每个配置钩子提供。否则，在运行时，根据上次运行的资源操作，相应的 SoftwareDeployment 资源可能会具有不同的或过时的属性，这可能会引入更多的复杂性。模板作者必须确保定义的 inputs 和 outputs 涵盖所有操作钩子的输入和输出的超集。通常，CREATE 钩子将需要最广泛的输入并产生最多的输出。

options 属性也将为完整的 SoftwareComponent 定义为全局的。此属性旨在为要使用的相应配置工具提供额外的选项。假设相同的选项适用于 SoftwareComponent 的所有配置调用，因此将此设置为每个配置设置没有意义。请注意，在 SoftwareComponent 中使用多个配置工具的情况下，需要对选项进行命名空间化，以便可以将其映射到相应的工具。为此，options 地图必须包含各个工具的子部分。例如，对于 Chef，options 地图将包含一个“chef”条目，其值为 Chef 特定选项的地图。

示例¶

以下片段显示了应用程序服务器的 SoftwareComponent 定义示例。SoftwareComponent 定义了 CREATE、UPDATE 和 SUSPEND 操作的专用钩子。

appserver-config:
  type: OS::Heat::SoftwareComponent
  properties:
    # per action configurations
    configs:
      - actions: [ CREATE ]
        config: { get_file: scripts/install_appserver.sh }
        tool: script
      - actions: [ UPDATE ]
        config: { get_file: scripts/reconfigure_appserver.sh }
        tool: script
      - actions: [ SUSPEND ]
        config: { get_file: scripts/drain_sessions.sh }
        tool: script
    # inputs and outputs
    inputs:
      - name: http_port
      - name: https_port
      - name: default_con_timeout
    outputs:
      - name: admin_url
      - name: root_url

SoftwareDeployment 资源的调整¶

SoftwareDeployment 资源 (OS::Heat::SoftwareDeployment) 将被调整以应对新的 SoftwareComponent 资源，例如以适当的形式向实例提供 configs 属性的内容。此外，SoftwareDeployment 资源的动作和状态（例如，CREATE 和 IN_PROGRESS）将被传递到实例，以便实例中的配置钩子可以选择要应用的正确配置（请参阅实例中配置钩子的更新）。

SoftwareDeployment 资源在运行时为提供数据给实际执行软件配置的实例工具而创建临时配置对象。当 SoftwareComponent 资源与 SoftwareDeployment 资源关联时，软件组件的完整配置集（即完整的 configs 属性）将存储在该临时配置对象中，因此它将可供实例工具使用。

SoftwareDeployment 属性不会发生变化，但必须对 actions 属性进行特殊处理：当 SoftwareComponent 资源与 SoftwareDeployment 资源关联时，将忽略 actions 属性。在这种情况下，configs 属性中定义的条目将提供 SoftwareDeployment 或实例工具分别应该响应的操作集。

注意：作为将 SoftwareComponent 中定义的完整配置集以及 SoftwareDeployment 的操作和状态传递到实例的一种替代方法，我们可以使 SoftwareDeployment 资源根据其操作和状态选择正确的配置，并仅将其传递到实例。这可能允许在不进行更改的情况下使用现有的实例钩子。但是，在撰写本文时，决定在实例钩子中实现配置选择，因为它为可能的未来增强提供了更多的能力。

实例中配置钩子的更新¶

实例钩子 (55-heat-config) 必须更新，以便根据关联的 SoftwareDeployment 资源指示的动作和状态选择要应用的适当配置。

在部署 SoftwareComponent 的情况下，完整的配置集将通过 Heat 元数据提供给实例钩子。此外，SoftwareDeployment 资源会将它们的动作和状态添加到元数据中（例如，CREATE 和 IN_PROGRESS）。基于这些信息，实例钩子将能够选择并在运行时应用正确的配置。

或者，我们可以选择以仅将与当前操作和状态对应的配置（通过 Heat 元数据）传递到实例的方式来实现 SoftwareDeployment。然后，实例工具可能无需更改（请参阅上一节中的说明）。

备选方案¶

在不更改当前实现的情况下，将存在以下为软件组件提供特定于操作的配置钩子的替代方案

使用 OS::Heat::StructuredConfig: StructuredConfig 允许定义配置的映射，即它将允许定义要添加到 SoftwareConfig 的 configs 属性的建议结构。但是，StructuredConfig 没有为该映射定义模式，因此它将允许任何自由形式的数据，这将使强制执行明确定义的处理更加困难。此外，这将更改 StructuredConfig 中映射结构的语义，因此这将是滥用此资源。
使用多个 SoftwareConfigs 和 SoftwareDeployments: 如问题描述中已经概述，使用当前设计，可以定义单独的 SoftwareConfigs 和 SoftwareDeployments，每个 SoftwareConfigs 和 SoftwareDeployments 对应一个生命周期资源操作。但是，这会使模板更加冗长，因为许多资源代表一个软件组件，并且整体结构与所有其他 Heat 资源的总体结构不一致。
使用有条件地处理操作的脚本: 可以提供在资源的整个生命周期操作中调用的脚本。这些脚本必须包含大量的条件逻辑，这会使它们非常复杂。

潜在的后续工作¶

当前规范和实现仅涵盖 Heat 的基本生命周期操作 CREATE、DELETE、SUSPEND、RESUME 和 UPDATE。认识到特殊处理对于服务器被静默以进行升级或需要为缩放操作而被撤离的情况可能是有意义的。此外，用户可能希望定义完整的自定义操作（请参阅新的 SoftwareComponent 资源）。处理这些操作目前不在范围内，但可以通过在实现此规范之上的后续工作来启用。例如，可以向 SoftwareDeployment 添加一个额外的属性 extended_action，该属性可以设置为上述扩展操作。当将此额外属性传递给实例钩子时，钩子可以然后选择并应用指定的扩展操作的相应配置。

实现¶

负责人¶

主要负责人: Thomas Spatzier

里程碑¶

完成目标里程碑: Juno-2

工作项¶

创建新的 OS::Heat::SoftwareComponent 资源
调整 OS::Heat::SoftwareDeployment 以适应新的 SoftwareComponent
调整实例钩子以选择要应用的正确配置

依赖项¶

无

感知操作的软件配置