通过 Swift 部署信号软件部署资源

https://blueprints.launchpad.net/heat/+spec/software-config-swift-signal

目前，唯一可用于信号部署资源的方法是向 heat 发出经过身份验证的 API 请求。SoftwareDeployment 资源 signal_transport: TEMP_URL_POLL 将允许使用类似于 OS::Heat::SwiftSignal 的方法进行未经验证的信号传递。

问题描述

OS::Heat::SoftwareDeployment signal_transport 选项当前都需要资源范围的凭证以及服务器到 heat API 的网络连接才能工作。

提议的变更

与 OS::Heat::SwiftSignal 类似，signal_transport:TEMP_URL_POLL 将创建一个长期有效的 swift TempURL，heat 将轮询该 URL，直到对象包含来自执行配置部署的 nova 服务器的预期数据。最初，“长期有效”意味着在 2038 年过期。

实现 signal_transport:TEMP_URL_POLL 将具有以下好处

• 每个 OS::Heat::SoftwareDeployment 资源都不需要创建堆栈用户

• 与访问 keystone 和 heat API 相比，云运营商更有可能提供从 nova 服务器访问 swift 对象的功能。

此外，heat.conf default_software_config_transport 选项将被添加，以便运营商可以选择最适合其云的传输方式。选择默认值将取决于云是否支持 keystone v3、swift 和 cloudformation 端点。

备选方案

Blueprint software-config-zaqar 将实现 signal_transport:ZAQAR_MESSAGE，这将是提供 zaqar 端点的云的首选方式。由于 Swift 的部署比 Zaqar 更广泛，因此应首先推荐 ZAQAR_MESSAGE，然后是 TEMP_URL_POLL。

实现

负责人

主要负责人

<steve-stevebaker>

里程碑

完成目标里程碑

Kilo-3

工作项

• 在 SoftwareDeployment 中实现 TempURL 创建和轮询

• 在 heat-templates 55-heat-config 中实现 TempURL POSTing（如果接口与 CFN_SIGNAL 相同，则可能不需要）

• 在 hot-guide 的软件部署部分记录使用 TEMP_URL_POLL 和 AUTO 的影响。

依赖项

不依赖于新的库或现有的蓝图。