解耦 TripleO 任务¶
https://blueprints.launchpad.net/tripleo/+spec/decouple-tripleo-tasks
本文档提出通过以管理对象为分组方式组织任务来解耦 TripleO 中的任务。目标是能够更好地隔离并减少为特定管理操作需要运行的任务数量。解耦任务的过程是通过将任务移动到 tripleo-ansible 中的独立原生 Ansible roles 和 playbooks 来实现的。
问题描述¶
目前，TripleO 在每次执行 openstack overcloud deploy 时一次性管理 overcloud 的整个软件配置。无论节点是否已经部署，是否因为某些原因需要完全重新部署，或者是否是新节点（扩展、替换），都会执行所有任务。仅执行所需任务的功能在于 Ansible。
完全依赖 Ansible 来确定是否需要任何更改的问题是，它会导致部署时间过长。即使不需要做任何事情，仅仅让 Ansible 检查每个任务也可能需要几个小时才能做出确定。
此外，TripleO 对外部工具（Puppet、容器配置脚本、bootstrap 脚本等）的依赖意味着执行这些工具的任务必须由 Ansible 执行，因为 Ansible 没有必要的数据来确定是否需要执行这些任务。这些任务通常会对确定需要运行的其他任务产生级联效应。这是 TripleO 中的一个普遍问题，也是为什么仅仅在每次部署时执行所有任务成为可接受模式的原因。
提议的变更¶
本文档提出解耦任务，并根据需要在 TripleO 中管理不同功能的方式将它们分离出来。根据所需的管理操作，tripleoclient 将包含触发正确任务的必要功能。解耦和重构任务将通过迁移到 tripleo-ansible 中的独立 ansible role 和 playbooks 来完成。这将允许重用 tripleo-ansible 中的独立 ansible artifacts，并使用 ansible-playbook 原生使用它们。与此同时，tripleo-heat-templates 接口将通过使用来自 tripleo-ansible 的新 roles 和 playbooks 来维护。
概述¶
为了实现本文档，提出了 3 个主要变更
将 ansible 任务从
tripleo-heat-templates重构为 tripleo-ansible 中的独立 roles。在 tripleo-ansible 中开发独立 playbooks 以使用 tripleo-ansible roles。
更新 tripleo-heat-templates 以使用来自
tripleo-ansible的独立 roles 和 playbooks，并使用新的role_data接口来驱动特定功能，以及新的openstack overcloud命令。
在 tripleo-ansible 中编写独立 roles 将很大程度上是对 tripleo-heat-templates 中任务列表的复制/粘贴。随着任务移动到独立 roles，tripleo-heat-templates 可以直接更新为使用 include_role 从这些 roles 运行任务。这种模式已经在 tripleo-heat-templates 中通过使用现有独立 roles 的可组合服务得到了很好的建立。
将在 tripleo-ansible 中开发新的 playbooks，以使用纯 ansible-playbook 驱动独立 roles。这些 playbooks 将提供使用 tripleo-ansible 进行部署的本机 ansible 体验。
独立 role 和 playbooks 的设计原则是
使用 ansible-playbook、inventory 和变量文件进行本机执行。
不使用 Heat。虽然 Heat 仍然是 TripleO 架构的一部分，但它对 tripleo-ansible 中本机 ansible 的开发方式没有影响。tripleo-heat-templates 可以使用来自 tripleo-ansible 的独立 ansible playbooks 和 roles，但它不会规定接口。接口应根据本机 ansible 最佳实践定义。
不使用 puppet。在开发独立 roles 时，它们将不依赖 puppet 进行配置或任何其他任务。为了允许与 tripleo-heat-templates 和现有 TripleO 接口（Hiera、Heat 参数）集成，roles 将允许跳过配置生成和其他使用 puppet 的部分，以便可以通过
tripleo-heat-templates特定任务覆盖这些部分。使用本机 Ansible 时，将使用模板化配置文件和本机 ansible 任务代替 Puppet。虽然解耦的任务将允许为执行特定管理操作提供更清晰的接口，但所有任务将保持幂等性。重新运行所有任务的完整部署仍然有效，并且对于具有相同输入集的已部署云，不会产生任何有效更改。
独立 roles 将使用为每个解耦的管理接口公开的单独任务文件。playbooks 也将按管理接口分隔，以便仅执行特定的管理功能。
解耦的管理接口定义如下
bootstrap
install
pre-network
network
configure
container-config
service-bootstrap
新的 tripleo-heat-templates 接口将在 role_data 下添加，以与新的管理接口对应，并使用来自 tripleo-ansible 的独立 ansible。这将允许仅执行特定的管理接口，并直接使用 tripleo-ansible 中的独立 playbooks。
将向 tripleoclient 添加新的子命令，以触发新的管理接口操作，openstack overcloud install、openstack overcloud configure 等。
openstack overcloud deploy 将继续像现在一样工作，即使用所有任务对系统状态进行完全断言。底层的 playbook deploy-steps-playbook.yaml 将根据需要更新，以包含其他 playbooks，以便可以执行所有任务。
替代方案¶
- 替代方案 1 - 使用 –tags/–skip-tags:
使用 --tags / --skip-tags，可以有选择地执行任务。过去这在 TripleO 中引发了其他问题。使用 tags 无法将任务组合到所需级别，并且通常会导致在不需要时运行任务或忘记标记所需的任务。必须添加特殊的 always tag，以便在需要时运行某些任务。当查看整个执行时，tags 难以维护，因为不清楚标记了哪些任务。此外，TripleO 中的并非所有操作都一一映射到 Ansible 任务。容器启动声明为自定义 YAML 格式，然后将该格式用作任务的输入。除非在用于容器启动的自定义模块中添加了 tag 处理逻辑，否则无法标记单个容器启动。
- 替代方案 2 - 使用 –start-at-task:
使用 --start-at-task 同样存在问题，并且它并不能真正分割完整的任务集。为了使 --start-at-task 有效，需要重新排序 TripleO 中的许多任务。如果需要重新排序大量任务，则按 playbook 分离会更简单。
安全影响¶
应特别考虑与安全相关的任务，以确保在需要时执行关键任务。
升级影响¶
升级和更新任务已经分离到它们自己的 playbooks 中。但是，在更新或升级后，将执行完整的 deploy_steps_playbook.yaml。如果任务解耦得足够充分，以便隔离地运行必要的组件（配置、bootstrap 等），则此完整任务集可能会减少。
其他最终用户影响¶
用户需要了解使用新的管理命令和 playbooks 的限制。TripleO 中的期望一直是系统在扩展和配置操作中被完全重新断言。
虽然仍然可以进行完全断言，但不再是必需的。操作员和用户需要了解，仅运行某些管理操作可能不会完全应用所需的更改。如果仅执行重新配置，则可能不会意味着重新启动容器。随着向独立和本机 ansible 组件的移动，以及更少的基于 config-download 的生成，应该更清楚地了解每个 playbooks 负责管理的内容。本机 ansible 接口将帮助操作员了解何时需要运行什么。
性能影响¶
由于需要运行的任务更少，并且能够仅运行给定操作所需的任务，因此受影响的管理操作的性能应得到提高。
在运行所有任务时，不应产生任何影响。必须以不会降低整体部署过程速度的方式重构任务，即使运行所有任务时也是如此。
其他部署者影响¶
讨论将影响您部署和配置 OpenStack 的事情，这些事情尚未提及，例如
正在添加哪些配置选项？它们是否应该比建议的更通用（例如，其他 hypervisor 驱动程序可能想要实现的标志）？默认值是否适用于实际部署？
此更改是否在合并后立即生效，还是需要显式启用？
开发人员影响¶
TripleO 开发人员将负责更新他们维护的服务模板，以重构任务。
实现¶
负责人¶
- 主要负责人
James Slagle <jslagle@redhat.com>
工作项¶
工作项目或任务 – 将该功能分解为实施它需要完成的事情。这些部分可能最终由不同的人完成，但我们主要试图了解实施的时间表。
依赖项¶
无。
测试¶
现有的 CI 任务将涵盖任务重构的更改。可以添加新的 CI 任务来涵盖新的隔离管理操作。
文档影响¶
必须记录新的命令和 playbooks。
