多环境支持¶

https://blueprints.launchpad.net/heat/+spec/multi-environments

我们允许用户在客户端指定多个环境文件，但这些文件在客户端被合并，任何冗余信息、优先级等都无法传递给 heat-engine。这给环境的 PATCH 更新带来问题，尤其是在 TripleO 中。

问题描述¶

在对环境是多个文件组合的 stack 进行 PATCH 更新时，用户无法（在一般情况下）安全地更新任何环境文件，除非显式地将之前包含的所有文件再次传递给客户端（因为顺序很重要，并且引擎不知道给定文件在层级结构中的位置）。这使他们与没有环境 PATCH 更新时的情况类似：必须记住 stack 环境的所有组成部分。

这对于 TripleO 来说尤其成问题，即使在相当典型的部署中，TripleO 也可能使用许多环境文件。如果用户自定义了默认环境文件之一，则更改不会被拾取，因为 TripleO 客户端不会在其 PATCH 更新中发送环境文件，除非它们被显式指定；相反，再次发送默认环境文件可能会覆盖用户指定的环境（例如用于网络隔离的环境），除非要求用户始终传递所有环境文件。

提议的变更¶

在 stack 创建或更新请求的主体中添加一个可选的“environment_files”键。此键的有效内容是文件名列表。文件名本身可以是任意的。文件内容必须包含在请求的“files”部分中，以文件名作为键，就像其他额外文件（脚本、嵌套模板）一样。

“environment_files”键位于现有的 environment 部分之外，以确保它仅由客户端插入；此更改不会修改环境文件格式本身。这可以防止循环包含等问题。

多个文件将以与当前客户端方式相同的方式由引擎组合。当环境文件包含冲突的信息时，最后指定的文件获胜。

在合并所有环境文件之后，将应用显式指定的参数值（即在环境外部），以保持与当前方法的一致性（在客户端完成文件组合，在 heat-api 中合并参数）。这意味着执行此操作的代码必须从 heat-api 移动到 heat-engine。

在 PATCH 更新时，指定的任何 additional_environment 文件都会被附加到列表中。Heat 将在每次 stack 更新时重新计算组合的环境，以便拾取“files”部分中的任何更改。

备选方案¶

我们可以允许在环境文件格式本身中包含 includes。但是，这将要求我们处理循环包含等问题，或者为包含的环境文件与“主”环境使用不同的格式。虽然能够将给定 stack 的所有环境记录在单个地方（例如存储在 Git 中）会很好，但可能最好完全在客户端实现这一点，作为 CLI 选项，以从文件读取环境列表，而不是/以及从多个 –environment 选项读取。

实现¶

负责人¶

主要负责人: jdob

里程碑¶

完成目标里程碑: Mitaka-1

工作项¶

在 heat-engine 中添加支持组合环境的功能
在 RPC API 上添加支持传递 environment_files 列表 + 参数的功能
在 heat-api 中添加对 environment_files 的支持
修改客户端以列表形式传递环境
添加一个 CLI 选项，以从文件读取环境列表

依赖项¶

无。

多环境支持