可组合服务升级¶
https://blueprints.launchpad.net/tripleo/+spec/overcloud-upgrades-per-service
在 Newton 版本中，TripleO 提供了一种新的能力，可以部署任意自定义 角色（节点组），并且可以灵活地将哪些服务放置在哪些角色上（使用 roles_data.yaml）。这意味着我们不能再对特定服务运行在特定角色上做出相同的假设（例如 Controller）。
当前的升级 工作流程围绕节点角色确定升级给定节点和其中部署的服务顺序来组织。该工作流程规定“swifts”在“controllers”之前，“cinders”在“computes”之前，“cephs”之前。这种排序的原因超出了本文的范围，最终无关紧要，因为重要的是要注意，在给定服务和给定节点之间存在硬编码的关系，关于升级该服务（例如，一个升级“Compute”节点上所有服务的脚本）。对于从 Newton 到 Ocata 的升级，我们不能再对服务与特定角色绑定做出这些假设，因此需要更可组合的模型。
在 Ocata 设计峰会 会议期间的初步讨论后达成共识
重新设计 Newton 到 Ocata 的升级工作流程是必要的，因为‘自定义角色’
我们应该首先将升级逻辑移动到 tripleo-heat-templates 中的可组合服务模板中（即，进入每个服务）。
仍然需要一个总体的流程 - 尽管是面向服务而不是面向角色。
什么将驱动该工作流程尚未确定。我们将使用对第一次迭代‘更容易’的任何方式，特别是考虑到 Ocata 开发时间限制。
问题描述¶
如上文介绍中所述，当前的升级 工作流程不再适用于可组合服务部署。现在，升级脚本围绕特定节点组织，甚至针对特定节点：用于 swifts 的升级脚本与用于 computes 或 controllers（分成一个 数量 的 步骤）cinders 或 cephs 不同。这些脚本作为工作流程的一部分被调用，其中每个步骤要么是 heat stack 更新，要么是调用 upgrade-non-controller.sh 脚本，以便在非控制器上执行节点特定的升级脚本（作为工作流程的早期步骤之一提供）。
处理此问题的一种方法是将升级逻辑从这些单片 per-node 升级脚本分解为 per-service 升级逻辑。这应该位于 tripleo-heat-templates puppet services 模板中的每个服务的 puppet 模板中。对于给定服务的升级，我们需要表达
任何升级前要求（运行迁移，停止服务，固定 RPC）
任何升级后操作（迁移，服务启动/重新加载配置）
对其他服务的任何依赖关系（仅在升级 foo 之后才升级 bar）
如果我们以这种方式组织升级逻辑，其想法是获得将这些动态组合到新的升级工作流程中的灵活性。除了 per-service 升级逻辑之外，工作流程还需要处理并提供任何部署范围的升级相关操作，例如，一旦所有服务都成功运行 Ocata，取消固定 RPC 版本，或者升级未直接由 tripleo 部署管理或配置的服务（例如 openvswitch），甚至交付新的内核，这将在所有服务升级后需要在给定服务节点上进行重新启动。
提议的变更¶
第一步是确定将升级相关配置添加到 tripleo-heat-templates services 模板中每个服务的哪个位置。确切的格式将取决于我们最终使用什么来驱动工作流程。我们可以将它们包含在 outputs 中，如‘upgrade_config’，例如
outputs:
role_data:
description: Role data for the Nova Compute service.
value:
service_name: nova_compute
...
upgrade_tasks:
- name: RPC pin nova-compute
exec: "crudini --set /etc/nova/nova.conf upgrade_levels compute $upgrade_level_nova_compute"
tags: step1
- name: stop nova-compute
service: name=openstack-nova-compute state=stopped
tags: step2
- name: update heat database
command: nova-manage db_sync
tags: step3
- name: start nova-compute
service: name=openstack-nova-compute state=started
tags: step4
...
当前建议是用 Ansible 表达升级片段。初步重点是通过现有的 tripleo 工具驱动升级，例如 heat 应用 ansible，类似于 heat 应用非可组合实现中的脚本。将来，也可能将 per-role ansible playbook 暴露给高级操作员，以便他们直接驱动升级工作流程，也许与 tripleo 验证提供的动态库存结合使用。
Ocata 设计峰会 会议中提出的另一个值得注意的点是，操作员可能希望分阶段运行升级，而不是一次性完成。新的工作流程仍然可以区分‘controlplane’与‘non-controlplane’服务。然后，操作员可以将 controlplane 服务作为独立的升级步骤进行升级，稍后再开始推出 non-controlplane 服务的升级。
替代方案¶
另一种选择是拥有一个独立的升级工作流程，由 ansible 驱动。进行了一些早期工作和原型设计，以及（链接自 Ocata 设计峰会 会议）。最终该提案被放弃，但我们仍然有可能像上面描述的那样使用 ansible 进行升级逻辑。我们还可以探索将生成的 ansible playbook 暴露给高级操作员，以便将其作为他们自己的工具的一部分调用。
其他最终用户影响¶
TripleO 升级工作流程的重大变化。
实现¶
负责人¶
主要负责人：shardy
其他贡献者：marios, emacchi, matbu, chem, lbezdick,
工作项¶
shardy 在“WIP prototyping composable upgrades with Heat+Ansible”中进行了一些原型设计，网址为 I39f5426cb9da0b40bec4a7a3a4a353f69319bdf9
将升级逻辑分解到 tht 中的每个服务模板中
设计一个包含迁移、per-service 升级脚本和任何部署范围升级操作的工作流程。
确定如何调用此工作流程（mistral？puppet？bash？）
盈利！
依赖项¶
测试¶
希望我们能够使用即将添加的升级 作业来帮助开发和测试此功能，并明显防止破坏升级的更改。理想情况下，我们将扩展它以包含每个稳定分支的作业（升级 M->N 和 N->O）。M->N 将执行以前的升级工作流程，而 N->O 将执行作为本规范的一部分开发的工作。
