工作流简化¶

https://blueprints.launchpad.net/tripleo/+spec/workflow-simplification

TripleO 工作流对于许多（大多数？）用户来说仍然过于复杂，难以成功执行。我们可以采取一些相当简单的步骤来改善这种情况。

问题描述¶

当前的 TripleO 工作流是从最初构成 instack-undercloud 的一组 bash 脚本中逐渐发展而来的。这些脚本最初主要是作为一项概念验证练习，旨在证明该想法是可行的，虽然这些步骤在正确执行时仍然有效，但似乎“正确执行”在今天来说太困难了，至少根据我从用户那里听到的反馈是这样。

提议的变更¶

概述¶

似乎有很多可以清理的低垂果实。按照它们在文档中出现的顺序，这些是

节点注册 为什么这是两个步骤？是否有任何情况下我们只想注册节点但不配置它以能够启动？如果有，这是否是一个重要的用例，足以证明每次用户注册节点时增加的步骤？

我建议在注册新节点时自动配置启动。请注意，这可能需要我们更新镜像时更新启动配置，但同样这也是一个好的工作流改进。用户可能会忘记在 Glance 中更新镜像后重新配置节点的启动镜像。

注意

这不会删除 openstack baremetal configure boot 命令，用于独立更新 Ironic 节点的启动配置。本质上，它只是会在注册节点后立即调用配置启动命令，因此它不会成为一个强制步骤。

这也意味着在注册节点之前必须构建并加载部署 ramdisk 到 Glance 中，但我们记录的流程已经满足了这一要求，并且我们可以提供一个 –no-configure-boot 参数给 import 命令，用于在有人想要注册节点但不配置它们的情况下使用。
Flavor 创建 我们的文档中没有任何地方推荐或提供有关定制将用于部署的 flavor 的指导。虽然可以仅基于 flavor 硬件值（ram、disk、cpu）进行部署，但在实践中，将 profile 分配给 Ironic 节点并仅基于此进行调度通常更简单。这也是我们目前记录的方法。

我建议我们在 undercloud 安装时创建所有推荐的 flavor，并在那时分配适当的 localboot 和 profile 属性。这些 flavor 将使用受支持的最小 cpu、ram 和 disk 值创建，因此它们可以适用于任何有效的硬件配置。这也会减少 flavor 创建命令中拼写错误导致可避免的部署失败的可能性。

如果用户需要，这些默认 flavor 可以随时自定义，因此更改不会导致任何功能丢失。
节点 profile 分配 这目前不是标准工作流的一部分，但在大多数实际的具有异构硬件的控制器、计算节点、ceph 等部署中，我们实际上需要这样做。现在文档要求运行一个 ironic node-update 命令，指定所有必要的 capabilities（在手动情况下，本节不适用于 AHC 工作流）。

os-cloud-config 支持在导入的 JSON 文件中指定节点 profile，但据我所知，我们在文档中没有任何地方提到这一点。这将是最低的低垂果实，因为这只是记录我们已经拥有的东西的问题。

我们甚至可以给通用的 baremetal flavor 一个 profile，并在我们的默认 instackenv.json 模板中包含它[1]，并附带说明可以将其覆盖为更具体的 profile（如果用户想要更改注册后的 profile 分配，ironic 的节点更新命令仍然可用）。

1. 为了向后兼容，我们可能希望创建一个名为 ‘default’ 之类的新的 flavor 并使用它，保留旧的 baremetal flavor 作为未配置 profile 的东西，供具有现有未配置 profile 的节点的用户使用。

替代方案¶

tripleo.sh¶

tripleo.sh 在某种程度上解决了开发人员的问题，但它不是现实世界部署的可行选择（恕我直言）。但是，可以参考 tripleo.sh 以获取更简单的流程的指导，因为这在很大程度上是该脚本的目的。将类似的流程编入客户端/API 将是这些提议更改的一个很好的结果。

节点注册¶

Dmitry 提出的一种选择是使节点注册操作具有幂等性，以便可以多次运行它，并且只会更新已注册节点的详细信息。他还建议将批量导入功能从 os-cloud-config 移出，并（希望）移入 Ironic 本身。

我完全赞同这两个选项，但我怀疑它们将比本规范中的其他项目需要更多的工作，因此我认为应该将它们作为独立的规范来处理，因为这个规范已经相当大。

安全影响¶

最小，或者没有。这只是将现有的部署步骤结合起来。如果我们要添加一个新的节点 profile 分配 API，那将会有一些轻微的安全影响，因为它会增加我们的攻击面，但我认为即使那样也会微不足道。

其他最终用户影响¶

更简单的部署。这都是关于最终用户。

性能影响¶

一些单独的步骤可能需要更长的时间，但只是因为它们将执行先前在单独步骤中执行的操作。总体而言，该过程应该花费相同的时间。

其他部署者影响¶

如果所有这些建议的改进都已实施，它将使标准的部署过程略微不那么灵活。但是，在“提议的更改”部分，我尝试解决任何新的限制，并且我认为它们仅限于最边缘的边缘情况，在大多数情况下仍然可以通过一些额外的手动步骤来实现（这可能无论如何都是必要的——毕竟它们是边缘情况）。

开发人员影响¶

工作流会有一些变化，但如上所述，将运行相同的基本步骤。开发人员会受到提议的更改的影响，但由于他们可能仍然使用 tripleo.sh 进行已经简化的工作流，因此影响应该很小。

实现¶

负责人¶

bnemec

工作项¶

自动配置新注册节点的启动。
在更新部署镜像后重新配置节点的启动。
从文档中删除配置启动的显式步骤，但将实际函数保留在客户端中，以便在需要时仍然可以使用。
在 undercloud 安装时创建 flavor，并将文档中手动创建 flavor 的内容移动到文档的高级部分。
在 undercloud 中添加一个 ‘default’ flavor。
更新示例 instackenv.json 以包含设置 profile（默认情况下，是来自上一步的 flavor 关联的 ‘default’ profile）。

依赖项¶

据我所知，没有。

测试¶

随着这些更改的实施，我们需要更新 tripleo.sh 以匹配新的流程，这将导致更改在 CI 中被覆盖。

文档影响¶

这将减少文档中基本部署流程中的步骤数量。旨在简化文档。

参考资料¶

提议的更改，在 undercloud 安装时创建 flavor：https://review.openstack.org/250059 https://review.openstack.org/251555

工作流简化