带内部署步骤¶
https://storyboard.openstack.org/#!/story/2006963
自 Rocky 版本发布以来，Ironic 已经支持 部署步骤。这些步骤允许驱动程序自定义节点部署流程。目前这些步骤仅限于带外执行 - 部署期间可能无法通过 IPA 在节点上执行步骤。本规范建议支持执行带内部署步骤，方式类似于带内清理步骤。
示例用例
部署期间的软件 RAID 配置
部署期间的带内 BIOS 配置
问题描述¶
Ironic 的部署过程在历史上一直相当严格，不允许在支持的功能范围之外进行太多自定义。从 部署步骤开始，情况正在发生变化，驱动程序可以使用与清理建立的模式定义在部署期间执行的自定义任务。 部署模板 功能通过应用于风味或镜像的特性将这些部署步骤暴露给 nova 的用户。
我们旨在通过本规范解决部署步骤的一些限制
部署步骤无法在部署期间带内执行（通过 IPA 在节点上）
部署步骤只能在我们这里将称为“mega step”的内容之前或之后执行
正如我们所见，这两个问题是相关的，因为我们必须分解 mega step 才能支持带内部署步骤。
Mega step¶
“mega step”从节点关机并配置为在配置网络上启动开始。完成时，镜像已写入磁盘，启动设备已配置，节点已连接到租户网络并已启动。这涵盖了部署过程的很大一部分。
用例¶
以下是带内部署步骤的一些用例。
作为 ironic 的用户，我希望一台机器在部署期间配置了特定的软件 RAID 布局
作为 ironic 的用户，我希望一台机器在部署期间配置了特定的 BIOS 设置
作为 ironic 的用户，我希望在部署期间安装自定义固件
作为 ironic 的用户，我希望在部署期间应用自定义 NIC 配置
以下是分解 mega step 的一些用例。
作为 ironic 驱动程序维护者，我希望创建一个在配置网络上启动的节点上执行的部署步骤
作为 ironic 驱动程序维护者，我希望创建一个在镜像写入磁盘后执行的部署步骤，同时节点连接到配置网络并已启动
提议的变更¶
Mega step 上下文¶
“mega step”实际上是 deploy 接口上的名为 deploy 的部署步骤。为了理解它将如何更改，我们首先必须了解它做什么以及它如何适应整体部署流程。以下的一些细节取决于所使用的特定驱动程序和配置，但我们将尝试涵盖最常见的用法。
我们的故事从 ironic conductor 开始，在那里收到了一条 do_node_deploy RPC。
do_node_deployRPC 接收power和deploy接口、特性和部署模板的验证节点的置备状态设置为
deploying（如果rebuild为True，则为rebuilding）
执行继续在一个新的工作线程中
如果使用 config drive，则构建并存储 config drive
调用
deploy接口的prepare方法根据驱动程序和部署模板确定要执行的部署步骤，然后存储在
driver_internal_info.deploy_steps中触发执行下一个部署步骤
对于每个部署步骤
将
driver_internal_info.deploy_step_index更新为当前步骤的索引执行部署步骤
如果它返回
DEPLOYWAIT，则这是一个异步步骤。退出工作线程并等待continue_node_deployRPC如果它返回
None，则继续执行下一个部署步骤
如果所有部署步骤完成
清理
driver_internal_info如果需要，启动节点的控制台
节点的置备状态设置为
active
看起来不太糟糕……直到我们意识到其中隐藏着一些复杂性和异步性。
Prepare¶
首先，让我们看一下 deploy 接口的 prepare 方法。对于 agent 和 iscsi 部署接口，这涉及
关闭节点
删除租户网络（用于重建，在写入镜像时）
添加配置网络（在写入镜像时）
附加卷
准备 ramdisk 启动
因此，我们知道如果将镜像写入节点，那么在 prepare 之后，节点将准备好在配置网络的 IPA ramdisk 上启动。
Continue node deploy RPC¶
这里要解包的下一个项目是异步步骤和 continue_node_deploy RPC。在等待异步步骤执行时，节点的置备状态设置为 wait callback。通过周期性任务（驱动程序设置 driver_internal_info.deployment_polling）或通过 IPA 心跳处理程序检查步骤的完成情况。完成时，触发 continue_node_deploy RPC，节点返回到 deploying 置备状态。
Mega step¶
这里的最后一部分是“mega step”本身：deploy 接口上的 deploy 方法。
重新启动节点，等待心跳（在写入镜像时）
在第一个 IPA 心跳上
同步将镜像写入磁盘（
iscsi部署接口）调用 IPA
standby.prepare_imageAPI，等待心跳直到完成（direct部署接口）
准备实例启动
关闭节点
删除配置网络
配置租户网络
启动节点
此时，将执行优先级低于 mega step 的优先级（100）的任何部署步骤。但是，此时需要小心，因为节点已经连接到租户网络并正在启动。
带内清理步骤¶
以下是带内清理的工作方式的快速概述，供参考。
带内清理首先在配置网络上配置节点并启动 IPA ramdisk。在第一个心跳上，查询带内步骤列表，与带外步骤组合并存储在 driver_internal_info.clean_steps 中。
带内清理步骤由 deploy 接口通告，该接口通过 IPA API 执行它们来覆盖 execute_clean_step 方法。带内清理步骤始终是异步的，通过 IPA 心跳触发轮询。
带内清理步骤可以请求在步骤定义中的 reboot_requested 标志后完成步骤后重新启动节点。在这种情况下，如果 IPA 在重新启动后返回不同版本，则有一些处理。在这种情况下，将重新启动自动清理，并中止手动清理。
最后一点是通过 @post_clean_step_hook 装饰器定义的在带内清理步骤完成后执行的钩子。
观察¶
为了收集带内部署步骤列表，我们需要能够与 IPA 通信。这在 mega step 的第 2 步时首次成为可能。
我们可能仍然希望在 IPA 启动之前执行带外部署步骤，以避免不必要的延迟。这里的一个例子是在 Dell iDRAC 上进行 BIOS 或 RAID 配置，这可能需要节点启动才能使生命周期控制器执行配置作业。额外的启动周期会显着延迟部署过程。
在从卷启动时，可能没有要写入的镜像。目前，在这种情况下，不使用 IPA。这将阻止使用带内部署步骤，但仅为了收集部署步骤列表而启动 IPA 会增加从卷启动所需的时间。
上述部署描述没有涵盖快速跟踪部署。此功能允许已经启动了 IPA ramdisk 的节点（例如，从发现），绕过 mega step 中的重新启动。
建议的 mega step 分解¶
以下描述了“mega step”分解为单独步骤的建议。
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” 方法的 HeartbeatMixin 目前提供了“deploy” 步骤逻辑的扩展。这包括在第一次 heartbeat 时调用 continue_deploy，以及在部署完成后调用 reboot_to_instance。当这些方法作为部署步骤时，此逻辑将是不必要的，但为了向后兼容性，它将保留一段时间。驱动程序将通过从名为 has_decomposed_deploy_steps 的方法返回 True 来通告对分解部署步骤的支持。
建议的同步部署步骤支持¶
同步部署步骤将以类似于同步清理步骤的方式处理，但有一些区别
优先级大于 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 启动之前执行异步部署步骤。有关详细信息，请参阅“观察”部分。
允许从卷启动的同步步骤。这些可以通过可选的部署步骤提供，该步骤在配置网络上启动节点。
数据模型影响¶
无
状态机影响¶
无
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)
工作项¶
分解核心部署步骤
通过 IPA 通告和执行同步步骤
从 IPA 收集和执行同步步骤
Update documentation
依赖项¶
测试¶
理想情况下，将添加 tempest 测试来涵盖同步部署步骤的执行。软件 RAID 配置是合理的候选对象，因为可以验证结果配置。
升级和向后兼容性¶
这已经在其他地方讨论过了。
文档影响¶
将更新部署步骤文档，特别是涵盖新的流程和用户步骤所需的优先级。
参考资料¶
无
