带内部署步骤¶
https://storyboard.openstack.org/#!/story/2006963
自 Rocky 版本发布以来，Ironic 已经支持 部署步骤。这些步骤允许驱动程序自定义节点部署流程。目前这些步骤仅限于带外执行 - 部署期间可能无法通过 IPA 在节点上执行步骤。此规范建议支持机内部署步骤的执行，方式类似于机内清理步骤。
示例用例
部署期间的软件 RAID 配置
部署期间的机内 BIOS 配置
问题描述¶
Ironic 的部署过程在历史上一直相当严格，不允许在支持的功能范围之外进行太多自定义。从 部署步骤开始，情况正在发生变化，驱动程序可以使用为清理建立的模式，定义在部署期间执行的自定义任务。 部署模板 功能通过应用于风味或镜像的特性，将这些部署步骤暴露给 nova 的用户。
我们旨在通过此规范解决部署步骤的一些限制
部署步骤无法在机内执行（在节点上，通过 IPA）在部署期间
部署步骤只能在我们将在这里称为“mega 步骤”之前或之后执行
正如我们所见，这两个问题是相关的，因为我们必须分解 mega 步骤才能支持机内部署步骤。
Mega 步骤¶
“mega 步骤”从节点关机并配置为在配置网络上启动开始。完成后，镜像已写入磁盘，启动设备已配置，节点已连接到租户网络并已启动。这涵盖了部署过程的很大一部分。
用例¶
以下是机内部署步骤的一些用例。
作为 ironic 的用户，我希望一台机器在部署期间配置了特定的软件 RAID 布局
作为 ironic 的用户，我希望一台机器在部署期间配置了特定的 BIOS 设置
作为 ironic 的用户，我希望在部署期间安装自定义固件
作为 ironic 的用户，我希望在部署期间应用自定义 NIC 配置
以下是一些用于分解 mega 步骤的用例。
作为 ironic 驱动程序维护者，我希望创建一个在配置网络上启动的节点时执行的部署步骤
作为 ironic 驱动程序维护者，我希望创建一个在镜像写入磁盘后执行的部署步骤，同时节点连接到配置网络并已启动
提议的变更¶
Mega 步骤上下文¶
“mega 步骤”实际上是 deploy 接口上的一个名为 deploy 的部署步骤。为了理解它将如何被更改，我们首先必须了解它做什么以及它如何融入到整体部署流程中。以下的一些细节将取决于所使用的特定驱动程序和配置，但我们将尝试涵盖最常见的用法。
我们的故事从 ironic conductor 开始，在那里收到了一条 do_node_deploy RPC。
do_node_deployRPC 收到验证
power和deploy接口、特性和部署模板节点的置备状态设置为
deploying（如果rebuild为True，则为rebuilding）
执行在新的工作线程中继续
构建并存储 config drive（如果使用）
调用
deploy接口的prepare方法根据驱动程序和部署模板确定要执行的部署步骤，然后存储在
driver_internal_info.deploy_steps中触发执行下一个部署步骤
对于每个部署步骤
将
driver_internal_info.deploy_step_index更新为当前步骤的索引执行部署步骤
如果它返回
DEPLOYWAIT，则这是一个异步步骤。退出工作线程并等待continue_node_deployRPC如果它返回
None，则继续执行下一个部署步骤
如果所有部署步骤完成
清理
driver_internal_info如果需要，启动节点的控制台
节点的置备状态设置为
active
看起来不太糟糕……直到我们意识到其中隐藏着一些复杂性和异步性。
准备¶
首先，让我们看一下 deploy 接口的 prepare 方法。对于 agent 和 iscsi 部署接口，这涉及
关闭节点
删除租户网络（重建时，在写入镜像时）
添加配置网络（在写入镜像时）
附加卷
准备 ramdisk 启动
因此，我们知道如果将镜像写入节点，那么在 prepare 之后，节点将准备好启动到配置网络上的 IPA ramdisk。
继续节点部署 RPC¶
接下来要解包的是异步步骤和 continue_node_deploy RPC。在等待异步步骤执行时，节点的置备状态设置为 wait callback。通过驱动程序中的定期任务（驱动程序设置 driver_internal_info.deployment_polling）或通过 IPA 的心跳处理程序检查步骤的完成情况。完成时，会触发 continue_node_deploy RPC，节点返回到 deploying 置备状态。
Mega 步骤¶
这里的最后一部分是“mega 步骤”本身：deploy 接口上的 deploy 方法。
重新启动节点，等待心跳（在写入镜像时）
在第一个 IPA 心跳上
同步将镜像写入磁盘（
iscsi部署接口）调用 IPA
standby.prepare_imageAPI，等待心跳直到完成（direct部署接口）
准备实例启动
关闭节点
删除配置网络
配置租户网络
启动节点
此时，将执行优先级低于 mega 步骤（100）的任何部署步骤。但是，需要小心，因为节点已经连接到租户网络并正在启动。
机内清理步骤¶
以下是机内清理工作方式的快速概述，供参考。
机内清理首先在配置网络上配置节点并启动 IPA ramdisk。在第一个心跳上，查询机内步骤列表，与带外步骤结合并存储在 driver_internal_info.clean_steps 中。
机内清理步骤由 deploy 接口通告，该接口会覆盖 execute_clean_step 方法以通过 IPA API 执行它们。机内清理步骤始终是异步的，通过 IPA 心跳触发轮询。
机内清理步骤可以请求在步骤完成之后通过其步骤定义中的 reboot_requested 标志重新启动节点。在这种情况下，如果 IPA 以不同的版本返回，则有一些处理。在这种情况下，将重新启动自动清理，并中止手动清理。
一个最终的细节是定义在机内清理步骤完成之后通过 @post_clean_step_hook 装饰器执行的钩子的能力。
观察¶
为了收集机内部署步骤列表，我们需要能够与 IPA 通信。这在 mega 步骤的第 2 步时首次成为可能。
我们可能希望仍然允许在 IPA 启动之前执行带外部署步骤，以避免不必要的延迟。这里的一个例子是在 Dell iDRAC 上，BIOS 或 RAID 配置，这可能需要为生命周期控制器执行配置作业而上电节点。额外的启动周期会显着延迟部署过程。
在从卷启动时，可能没有要写入的镜像。目前，在这种情况下，不使用 IPA。这将阻止使用机内部署步骤，但仅为了收集部署步骤列表而启动 IPA 会增加从卷启动所需的时间。
上述部署描述没有涵盖快速跟踪部署。此功能允许已经启动了 IPA ramdisk 的节点（例如，从发现），绕过 mega 步骤中的重新启动。
建议的 mega 步骤分解¶
以下描述了“mega 步骤”分解为单独步骤的建议。
deploy[100]:重新启动节点，等待心跳（在写入镜像时？）
从代理收集机内部署步骤
write_image[80]:同步将镜像写入磁盘（
iscsi部署接口）机内部署步骤，它执行等效于
standby.prepare_imageIPA API 并等待写入完成（direct部署接口）
prepare_instance_boot[60]:安装引导加载程序（如果需要）
配置引导接口
tear_down_agent[40]:关闭节点
switch_to_tenant_network[30]:删除配置网络
添加租户网络
boot_instance[20]:启动节点
插入自定义机内步骤的有用优先级范围是
99 到 81：在写入镜像之前准备（例如，软件 RAID）。
79 到 61：在写入引导加载程序之前对镜像进行修改（例如，GRUB 默认更改）。
59 到 41：对最终实例进行修改（例如，软件配置）。
deploy¶
优先级：100
此部署步骤将与当前的 deploy 步骤基本相同。快速跟踪部署需要进行更改，以跳过直接调用 continue_deploy 并依赖新的部署步骤。对于从卷启动，此步骤当前执行租户网络配置、实例准备和重新启动，但是也可以将其移动到新的步骤。
write_image¶
优先级：80
对于 iscsi 接口，continue_deploy 方法将被拆分为 write_image 部署步骤和 prepare_instance_boot、tear_down_agent、switch_to_tenant_network 和 boot_instance 部署步骤。
对于 direct 接口，此步骤将从带外步骤开始，收集必要的信息，然后切换为通过 IPA 执行机内步骤。它将等效于通过代理 API 执行现有的 standby.prepare_image 命令，并将阻塞直到写入镜像完成。这使我们能够删除命令状态轮询的特殊情况。需要有一个过渡期来支持不支持机内部署步骤的旧 IPA ramdisk。
prepare_instance_boot¶
优先级：60
这将大致等同于 AgentDeployMixin 的 prepare_instance_to_boot 方法。
tear_down_agent¶
优先级: 40
在此步骤中，节点将被关机，并且 ramdisk 启动环境将被移除。
switch_to_tenant_network¶
优先级: 30
在此步骤中，节点将从配置网络切换到租户网络。
boot_instance¶
优先级: 20
在此步骤中，节点将被开启。
Agent heartbeat handler¶
目前，heartbeat 方法的 HeartbeatMixin 提供了 deploy 步骤逻辑的扩展。这包括在第一次 heartbeat 时调用 continue_deploy，以及在部署完成后调用 reboot_to_instance。当这些方法作为部署步骤时，此逻辑将是不必要的，但为了向后兼容性，它将保留一段时间。驱动程序将通过从名为 has_decomposed_deploy_steps 的方法返回 True 来宣传对分解部署步骤的支持。
Proposed in-band deploy step support¶
带内部署步骤将以类似于带内清理步骤的方式处理，但有一些区别
优先级大于 100 的带外部署步骤可能在节点启动之前执行
deploy接口可以提供带内和带外部署步骤没有手动清理的等效操作
IPA 版本不匹配将导致部署终止
带内部署步骤必须具有 41 到 99 之间的优先级，以确保它们在 deploy 之后和 tear_down_agent 之前执行。
带内部署步骤将通过 agent 的 heartbeat 机制驱动。第一次 heartbeat 将查询带内步骤，将它们与带外步骤结合起来，并将它们存储在 driver_internal_info.deploy_steps 中。
带内部署步骤由 deploy 接口进行宣传，该接口将覆盖 get_deploy_steps 方法以从 IPA 查询步骤，以及 execute_deploy_step 方法以通过 IPA API 执行它们。这将与清理步骤略有不同，以支持在 deploy 接口上执行带外步骤。带内部署步骤始终是异步的，通过 IPA heartbeat 触发轮询。
带内部署步骤可以请求在步骤完成之后重新启动节点，通过其步骤定义中的 reboot_requested 标志。如果 IPA 在重新启动后返回不同的版本，部署将被终止。
通过 @post_deploy_step_hook 装饰器支持部署后步骤钩子，例如设置节点的 RAID 配置字段。
IPA ramdisk 将被修改以添加一个新的 deploy 扩展。这将与现有的 clean 扩展非常相似。硬件管理器应实现一个 get_deploy_steps 方法，该方法应以类似于现有的 get_clean_steps 方法的方式工作。
备选方案¶
禁止在 IPA 启动之前执行带外部署步骤。有关详细信息，请参阅 Observations。
允许从卷启动的带内步骤。这些可以通过可选的部署步骤提供，该步骤在配置网络上启动节点。
数据模型影响¶
无
状态机影响¶
无
REST API 影响¶
无
客户端 (CLI) 影响¶
无
RPC API 影响¶
无
驱动程序 API 影响¶
驱动程序 API 将不会有任何更改，但 AgentDeployMixin 类将发生更改，该类由所有树内驱动程序以及潜在的树外驱动程序使用。这些更改将向后兼容，为树外驱动程序提供过渡期，以切换到新的分解步骤模型（通过从 has_decomposed_deploy_steps 返回 True 进行宣传）。
Nova 驱动程序影响¶
无
Ramdisk 影响¶
上述讨论了对 IPA ramdisk 的更改。通过忽略缺少的 deploy 扩展，将提供向后兼容性。
安全影响¶
带内部署步骤由于直接在节点上执行，因此将具有对节点的额外访问权限。这些步骤和 IPA ramdisk 处于操作员的控制之下，操作员需要采取措施以确保它们不会引入任何安全问题。
其他最终用户影响¶
无
可扩展性影响¶
无
性能影响¶
无
其他部署者影响¶
无
开发人员影响¶
无
实现¶
负责人¶
- 主要负责人
Mark Goddard (mgoddard) Arne Wiebalck (arne_wiebalck)
工作项¶
Decompose core deploy step
Advertise & execute in-band steps via IPA
Collect & execute in-band steps from IPA
Update documentation
依赖项¶
测试¶
理想情况下，将添加 tempest 测试以涵盖带内部署步骤的执行。软件 RAID 配置是此目的的一个合理候选，因为可以验证结果配置。
升级和向后兼容性¶
这已经在其他地方讨论过了。
文档影响¶
将更新部署步骤文档，特别是涵盖新的流程和用户步骤所需的优先级。
参考资料¶
无
