所有部署的临时 Heat 堆栈¶
https://blueprints.launchpad.net/tripleo/+spec/ephemeral-heat-overcloud
本规范建议对所有部署类型（包括 overcloud）使用临时 Heat 堆栈模型。使用临时 Heat 已经应用于使用“tripleo deploy”命令的独立部署，以及 undercloud 安装。将其使用扩展到 overcloud 部署将使不同的部署方法统一为一种方法。它还将使安装过程更加无状态，并且具有更好的可预测性，因为没有 Heat 堆栈会被损坏或可能具有错误的 state 或配置。
问题描述¶
由于用户或软件错误，维护 Heat 堆栈可能存在问题。备份通常不可用，即使存在，也不能保证恢复堆栈。Heat 堆栈的损坏或丢失，例如意外删除，需要自定义恢复过程或重新部署。
Heat 部署本身需要维护、更新和升级。这些任务不是很大的工作量，但它们是使用临时 Heat 可以消除的维护领域。
依赖于长期存在的 Heat 进程会降低部署的可移植性，因为 TripleO 中有许多假设，所有命令都直接从 undercloud 运行。使用临时 Heat 至少允许堆栈操作和 config-download 生成完全可移植，以便可以从安装了 python-tripleoclient 的任何节点运行。
当前所有部署中存在的每个 Heat 堆栈的状态都存在很大的未知数。这些未知数可能在更新/升级期间导致问题，因为我们无法考虑到所有这些项目，例如过时的参数使用或旧/不正确的资源注册映射。每次堆栈操作创建一个新的堆栈将消除这些问题。
提议的变更¶
概述¶
临时 Heat 堆栈模型涉及启动一个短期的 heat 进程，使用数据库引擎来创建堆栈。最初的建议是使用已经存在于 undercloud 上的 MySQL 实例作为数据库引擎。为了与已经实现的“tripleo deploy”代码路径保持兼容，SQLite 也将支持单节点部署。如果 SQLite 不会成为瓶颈，SQLite 也可能支持其他足够小的部署。
创建堆栈后，将运行 config-download 工作流以下载和渲染 ansible 项目目录以完成部署。短期的 heat 进程将被杀死，数据库将被删除，但是，将保存足够的工件以在必要时重现 Heat 堆栈，包括数据库转储。undercloud 备份和恢复过程将被修改以考虑删除 Heat 数据库。
此模型已经由“tripleo deploy”命令用于独立和 undercloud 安装，并且对于这些用例已经得到了充分的验证。将 overcloud 部署切换为也使用临时 Heat 可以使所有不同的部署使用相同的方式使用 Heat。
我们可以通过使用封装 heat-api、heat-engine 和我们需要的任何其他进程的容器的 podman pod 来扩展临时 Heat 进程。以容器化形式运行单独的 Heat 进程而不是单个 heat-all 进程将允许启动多个引擎 worker 以允许扩展。heat pod 的管理和配置将是规范性的，它将使用默认的 podman 网络，因为我们不需要 Heat 进程扩展到单个主机之外。今后，undercloud minions 将不再安装 heat-engine 进程作为扩展的一种方式。
作为此更改的一部分，我们还将添加一种能力，可以针对给定部署的已保存数据库运行 Heat 命令。这将为操作员提供一种检查为调试目的创建的 Heat 堆栈的方式。
管理部署过程中使用的模板变得更加重要，因为传递到“overcloud deploy”命令的模板和环境是重现部署的整个真相来源。我们可能会考虑对模板进行进一步的管理，例如 git 存储库，但这超出了本规范的范围。
在部署操作之前，有时会检查堆栈中保存的状态。两个例子是在输入和堆栈中存在的 Ceph fsid 之间进行比较，以及检查缺少 network-isolation.yaml 环境。
在这些情况下，我们需要一种在不检查 Heat 堆栈本身的情况下执行这些检查的方法。一种直接的方法是添加 ansible 任务，这些任务会检查现有的已部署 overcloud（而不是堆栈），然后导致一个错误，该错误将停止部署，如果检测到无效的更改。
替代方案¶
另一种选择是不做任何更改，并继续像今天一样为 overcloud 部署使用 Heat。由于已经完成的工作将 Heat 与 Nova、Ironic 和现在 Neutron 解耦，因此似乎下一步迭代是为我们所有的部署类型使用临时 Heat。
安全影响¶
短期的临时 heat 进程不使用身份验证。这与我们今天在 undercloud 上使用的 Heat 进程形成对比，后者使用 Keystone 进行身份验证。实际上，此更改对安全性影响很小，因为所有敏感数据实际上都从模板传递到 Heat。但是，我们应该确保生成的文件受到适当的保护。
由于 Heat 进程是临时的，因此不需要与 SRBAC（Secure RBAC）相关的任何更改。
升级影响¶
当用户升级到 Wallaby 时，undercloud 上的 Heat 进程将被关闭，并且进一步的堆栈操作将使用临时 Heat。
overcloud 的升级操作将按预期工作，因为所有的更新和升级任务都在每次堆栈操作时使用 config-download 完全生成。但是，我们需要确保进行适当的升级测试，以确保所有服务都可以使用临时 Heat 进行适当的升级。
其他最终用户影响¶
最终用户将不再拥有一个正在运行的 Heat 实例来与之交互或运行 heat client 命令。但是，我们将添加管理功能，以便能够使用先前使用的数据库启动临时 Heat 进程，以便进行调试检查（堆栈资源列表/显示等）。
性能影响¶
临时 Heat 进程目前是单线程的。通过使用 podman pod 来实现 Heat 进程来解决此限制，将允许部署扩展以满足 overcloud 部署需求，同时保持流程的临时性和易于管理，只需几个命令即可。
使用 MySQL 数据库而不是 SQLite 作为数据库引擎应该可以消除数据库成为瓶颈的任何影响。在部署操作后备份数据库后，它将被从 MySQL 中擦除，以便在部署生成的文件之外不保存任何状态。
或者，我们可以完成在 使用 Ansible 库存进行扩展 中启动的工作。这项工作将能够为每个角色部署一个计数为 1 的 Heat 堆栈。有了这个改变，堆栈操作时间将随着部署中角色的数量而扩展，而不是节点数量，这将允许与当前存在的类似性能。即使在使用库存进行扩展时，我们仍然可能比今天使用单个 heat-all 进程的性能更差。只有几个角色时，仅使用 heat-all 就会成为瓶颈。
其他部署者影响¶
最初，部署者将可以选择为 overcloud 部署启用使用临时 Heat 模型，直到它成为默认设置。
开发人员影响¶
开发人员需要注意将添加的新命令，这些命令将用于启用检查 Heat 堆栈以进行调试目的。
在某些情况下，可能需要更新一些服务模板，因为这些模板依赖于 Heat 堆栈中保存的状态。
实现¶
负责人¶
- 主要负责人
james-slagle
工作项¶
计划是开始原型化这项工作，并在 Wallaby 中为默认 overcloud 部署提供该选项。我们可能会在 X 版本中完成一些额外的微调，并计划将其回溯到 Wallaby。理想情况下，我们希望在 Wallaby 中使其成为默认行为。这在多大程度上是可能的将由原型工作决定。
将 Heat podman pod 的管理添加到 tripleoclient
向“overcloud deploy”添加选项以使用临时 Heat
使用“tripleo deploy”中的代码来管理临时 Heat
确保部署生成的文件保存在已知位置并且可以根据需要重用
更新 undercloud 备份/恢复以考虑与 Heat 数据库相关的更改。
添加命令以启用使用先前使用的数据库运行 Heat 命令
修改 undercloud minion 安装程序以不再安装 heat-engine
切换一些 CI 作业以使用可选的临时 Heat
最终使“overcloud deploy”中默认使用临时 Heat
将“tripleo deploy”中的功能与“overcloud deploy”命令对齐，并最终弃用“tripleo deploy”。
依赖项¶
这项工作依赖于其他正在进行的工作，以将 Heat 与管理其他 OpenStack API 资源解耦，特别是可组合网络 v2 的工作。
测试¶
最初，该更改将在“overcloud deploy”命令中是可选的。我们可以选择一些 CI 作业来切换到选择加入。最终，它将成为默认行为，并且所有 CI 作业都将受到影响。
文档影响¶
需要更新文档以详细说明有关使用临时 Heat 的更改。具体来说
用户界面更改
如何运行 Heat 命令来检查堆栈
保存部署生成的文件的位置以及如何使用它们
