统一资源信号¶

https://blueprints.launchpad.net/heat/+spec/uniform-resource-signals

本文档涵盖了 heat 资源统一信号框架的实现。

问题描述¶

标准的信号资源方式是通过向 heat-api 发送请求。这对于用户生成的信号来说效果很好，但通常信号并非直接由用户生成，而是由资源或服务在满足特定条件时触发。触发这些内部信号的困难在于无法使用用户凭据，因此 heat 资源实现了各种机制来使信号在这种情况下工作。

例如，OS::Heat::ScalingPolicy 资源暴露了一个 alarm_url 属性，它是一个 EC2 签名 URL，因此 heat-api-cfn 兼容性服务必须可用才能使这些信号工作。OS::Heat::WaitConditionHandle 资源，另一方面，暴露了一个适当的 heat-api 端点和一个用于对其进行身份验证的令牌，但这仅允许在令牌过期之前发送信号。不幸的是，无法更新令牌，因此这些资源不能用于长时间的任务。其他 heat 资源使用 swift 临时 URL 作为信号，还有一些资源暴露了一组更传统的 heat 拥有的 keystone 凭据，可用于获取用于对 heat-api 进行身份验证的令牌。

在所有这些身份验证方法中，只有一种是在所有资源都可以访问的基础类中实现的，那就是基于 heat-api-cfn 端点的 EC2 签名 URL。其他方法都是由各个资源作为“一次性”实现，这使得在不进行代码重复的情况下在资源之间实现它们变得困难。

提议的变更¶

heat-engine 服务包含一个 SignalResponder 基类，资源可以从该基类继承以接收信号。为了使不同类型的信号可用于所有资源，它们的实现将被移动到这个类中，该类已经包含对 EC2 签名 URL 的支持。

通过在 SignalResponder 中实现对所有不同类型信号的支持，资源将能够提供不同的信号选择，而无需处理每种实现的细节。

资源可以选择暴露单一信号类型，或者实现一个 signal_transport 属性，该属性允许操作员选择信号类型。

触发信号所需的凭据将在资源中作为名为 signal 的属性暴露出来，类型为 map。map 中包含的项目将取决于所选的信号类型。

将支持以下信号类型

CFN_SIGNAL：当前可用的 EC2 签名 URL 信号。通过向 URL 发送请求来触发信号。请求方法和 URL 在 signal 属性中给出。URL 基于 heat-api-cfn 服务。
TEMP_URL_SIGNAL：基于 swift 临时 URL 的信号。通过向 URL 发送请求来触发信号。请求方法和 URL 在 signal 属性中给出。URL 基于 swift 服务。
HEAT_SIGNAL：基于标准的 heat-api 信号端点的信号。触发此信号的过程涉及请求 keystone 令牌，然后使用此令牌将信号请求发送到 heat-api。获取令牌所需的 keystone 凭据在 signal 属性中给出。请注意，这些凭据不是用户的凭据，而是 heat 创建的临时用户的凭据。

备选方案¶

实现一个类似于 EC2 签名 URL 的 webhook 解决方案，该解决方案基于 heat-api 端点。这是一种不太灵活的方法，并且有一个缺点是身份验证令牌嵌入在 URL 中，而 URL 通常会写入日志文件。所提出的解决方案的好处是，将来可以随时将 webhook 信号添加到信号选项列表中。

实现¶

负责人¶

主要负责人: miguelgrinberg

里程碑¶

完成目标里程碑: liberty-1

工作项¶

重构 SignalResponder 类中的 EC2 签名 URL 支持，以允许定义其他信号类型。
在 SignalResponder 类中实现 heat-api 信号。
在 SignalResponder 类中实现 swift 临时 URL 信号。
在等待条件中添加对所有信号类型的支持。
在缩放策略资源中添加对所有信号类型的支持。
基于 SignalResponder 类，在 SoftwareDeployment 中基于信号。
弃用等待条件和缩放策略资源中的当前信号。
弃用 default_deployment_signal_transport 配置项，并将其替换为适用于所有资源的通用配置项，例如 default_signal_transport。
受影响的各种资源的文档。
受影响的各种资源的单元测试。

依赖项¶

无

统一资源信号