添加资源链支持¶

问题描述¶

资源注册表通过将特定模板/实现映射到资源类型名称，从而实现模板扩展和自定义。TripleO 广泛使用这种模式，以便在堆栈部署的各个步骤中提供集成点，可用于添加第三方集成，例如服务和驱动程序配置。

问题在于，对于这些钩子中的每一个，只能指定一个模板。此规范试图通过引入一种新的类型来缓解这个问题，该类型会将一个或多个模板聚合到一个嵌套堆栈中。

提议的变更¶

建议的更改是引入一种 ResourceChain 类型，其行为类似于现有的 ResourceGroup。例如

resources:
  MyChainResource:
    type: OS::Heat::ResourceChain
    properties:
      resources: <list>  # resource types to add to the chain's nested stack
      concurrent: <boolean>  # optional; default is false
      resource_properties:
        # properties to pass each template in the chain

在内部，Heat 将创建一个嵌套堆栈，该堆栈由链的配置中指定的每个模板组成。

默认情况下，每个资源将被视为依赖于列表中它之前的资源。如果将 concurrent 属性设置为 true，则不会在创建的资源之间建立任何依赖关系。

链中资源创建失败将中止剩余资源的创建（并且显然将链资源标记为失败）。这将允许用户控制链中资源的创建顺序。如果设置为 false，则链中的资源将并发创建。

resource_properties 参数类似于 resource_def 中使用的 properties 部分，将被传递到链堆栈中的每个资源。

可以通过索引访问链中的资源，其中索引对应于模板在 resources 属性中的位置。

主要缺点是它将模板选择从资源注册表移到了参数部分。对于尝试扩展模板的用户来说，如果一些替换在注册表中完成，而另一些通过参数完成，则可能会造成混淆。这也会使功能检测变得复杂，因为我们必须考虑到不仅在注册表中指定的模板，还要通过参数指定的模板。

为了将此应用于 TripleO 用例，以下是如何使用资源链来配置在部署的特定步骤中创建哪些资源的示例

ControllerDeploymentSteps:
  type: json
  default:
    step1: [controller/loadbalancer.yaml]
    step2: [controller/db.yaml, controller/rabbit.yaml]
    step3: [controller/keystone.yaml, controller/glance-api.yaml ...]

[snip]

DeploymentStep1:
  type: OS::Heat::ResourceChain
    properties:
      resources: {get_param: [ControllerDeploymentSteps, step1]}
      resource_properties:
        servers: {get_param: servers}

DeploymentStep2:
  type: OS::Heat::ResourceChain
    properties:
      resources: {get_param: [ControllerDeploymentSteps, step2]}
      resource_properties:
        servers: {get_param: servers}

备选方案¶

无

实现¶

负责人¶

主要负责人: jdob

里程碑¶

完成目标里程碑: mitaka-1

工作项¶

为 ResourceChain 添加资源插件
添加相应的功能测试

依赖项¶

无

添加资源链的支持