重构顶层 Puppet 清单¶
Launchpad蓝图
https://blueprints.launchpad.net/tripleo/+spec/refactor-puppet-manifests
当前的 overcloud 控制器 Puppet 清单在 pacemaker（HA）和非 HA 版本之间重复了大量的代码。通过重构这段代码，我们可以减少添加新功能所需的工作量，并且由于已经存在 puppet-tripleo 模块，这似乎是合乎逻辑的目的地。
问题描述¶
大量的 puppet/manifests/overcloud_controller.pp 与 puppet/manifests/overcloud_controller_pacemaker.pp 共享。当在前者中添加功能或修复错误时，通常也会在后者中出现问题。这违反了常见的编程原则 DRY（Don't Repeat Yourself，不要重复自己），虽然这并非绝对规则，但通常被认为是良好的实践。
此外，将这段代码移动到另一个模块中的单独类中，将简化组件的启用/禁用，只需控制包含哪些类（profile）即可。
最后，它允许更容易地试验修改“ha 策略”。目前这是使用‘step’完成的，但理论上可以使用服务注册表。通过重构为 ha + 非 ha 类，这将很容易地进行替换。
提议的变更¶
概述¶
虽然 HA 和非 HA 部署之间存在显著差异，但在几乎所有情况下，HA 代码都将是非 HA 代码的超集。一个简单的例子是在这两个文件的顶部，负载均衡器的处理方式。非 HA 版本只是包含负载均衡类，而 HA 版本实例化完全相同的类，但参数有所更改。在整个过程中，相同的类都包含在 OpenStack 服务中，但在 HA 情况下，管理服务设置为 false。
我建议首先将非 HA 版本分解为可以驻留在 puppet-tripleo/manifests/profile/nonha 中的 profile，然后添加使用这些类在 puppet-tripleo-manifests/profile/pacemaker 下的 HA 版本。Pacemaker 可以被描述为一种“ha 策略”，理论上应该可以替换。因此，我们使用 pacemaker 子文件夹，因为也许有一天我们会拥有替代方案。
替代方案¶
我们可以保持现状，这可行且并非世界末日，但可能不是最优的。
我们可以使用 kolla 或其他消除对 Puppet 需求的方案，但此讨论超出了此规格的范围。
安全影响¶
无
其他最终用户影响¶
这将使下游用户满意，因为他们可以更轻松地替换类。
性能影响¶
添加包装类不会对 Puppet 编译时间产生太大影响。
其他部署者影响¶
无
开发人员影响¶
t-h-t 和 puppet-tripleo 中的更改通常是相关的，因为 t-h-t 定义了 puppet-tripleo 所依赖的数据。
实现¶
负责人¶
- 主要负责人
michaeltchapman
工作项¶
将 overcloud 控制器移动到 profile 类 将 overcloud 控制器 pacemaker 移动到 profile 类 将 t-h-t 中较小清单中的任何其他类移动到 profile 类
依赖项¶
无
测试¶
没有新功能，因此当前测试完全适用。可以为每个 profile 类添加额外的测试
文档影响¶
无
参考资料¶
无
