更灵活的环境合并¶
https://blueprints.launchpad.net/heat/+spec/environment-merging
由于我们现在支持服务器端环境文件合并，这很好，但它仅支持与 heatclient 中先前相同的“最后胜出”合并策略。
在某些情况下，需要更高的灵活性，例如通过多个环境文件组成部署时，参数键冲突会发生。
问题描述¶
考虑以下场景
heat stack-create foo -f foo.yaml -e one.yaml -e two.yaml
one.yaml 包含
- parameters
- ControllerServices
Keystone
two.yaml 包含
- parameters
- ControllerServices
Glance
使用当前的环境合并，我总是会得到
- parameters
- ControllerServices
Glance
但实际上我想要的是
- parameters
- ControllerServices
Keystone
Glance
因此，我需要某种方式来指定 heat 服务器端环境合并将追加到，而不是覆盖 ControllerServices 参数。（同样的问题也存在于例如 json 映射参数中，在那里我们可能希望提供浅合并和深合并与仅仅覆盖的选项）。
请注意，这与一些其他接受潜在重叠的 yaml 数据部分（例如 cloud-init[1]）面临并解决的完全相同的问题
[1] http://cloudinit.readthedocs.io/en/latest/topics/merging.html
提议的变更¶
由于 parameters/parameter_defaults 只是简单的键/值对，很难想出一个在参数映射中添加合并策略数据的接口，因此我们可能需要一个单独的环境部分，例如
为所有参数指定全局合并策略
- merge_strategy
list: extend dict: merge # 我们可以在这里支持“merge”和“deep_merge”吗？ string: append
为每个参数指定合并策略
- merge_strategy
- parameters
ControllerServices: extend
这与 cloud-init 的“merge_how”指令非常相似。
如果多个环境指定了冲突的 merge_strategy 值，我们将引发验证错误。
备选方案¶
另一种选择基本上是客户端模板修改，这可行，但会使模板可移植性降低（例如，我们将最终在 tripleo-common 中实现 TripleO 特定的解决方案，这将导致我们的环境无法直接通过 heatclient 传递给 heat）。
实现¶
由于 jdob 在 engine/service.py 中添加了对合并 environment_files 列表的支持，这应该只是在那个文件中的 _merge_environments 函数中添加对这些可选策略的支持。
负责人¶
- 主要负责人
ramishra
里程碑¶
- 完成目标里程碑
newton-2
工作项¶
更新 heat-engine 代码以支持新的可选 merge_strategy 键
此新接口的全面测试和文档
为 heatclient 添加支持（不是为了支持合并，只是为了接受该键）
依赖项¶
无
