修改活动节点的服务步骤

https://storyboard.openstack.org/#!/story/2010647

在系统运维的现实中，有时需要更改某些东西。更不幸的现实是，我们越接近底层基础设施，采用“只需使用新设置重新部署”的模型就越困难。

不幸的是，Ironic 在这方面为希望自动化诸如“升级固件”或“更改低级设置”等活动的 инфраструктура 运维人员提供的选项有限，尤其是在系统已经部署的情况下。目前他们可能可以利用 rescue 流程，但这同时也意味着他们必须在 rescue 流程完成后阐述所有内容。

然而，Ironic 也有很多工具可以实现设置更改以及在清理和部署过程中升级固件，我们应该提供利用这些工具的功能，作用于处于 active 状态的节点。

问题描述

已部署的系统需要能够被更改或评估

  • 固件设置和软件有时需要被修改或更新。

  • “数据处理单元”（SmartNICs 的进一步发展）的引入，配备了完整的操作系统，意味着可能会出现额外的维护操作，并且可能无法直接访问设备。

  • 安全运营团队有时需要能够检查硬件和软件的状态，通过“带外”流程，这可能导致硬件从库存中移除，或者如果未检测到问题则返回到运行状态。

  • 运维团队需要测试内存、CPU 或网络，以识别问题或解决客户疑虑。

在这种情况下，硬件管理器和/或供应商驱动程序方法可以促进一些操作员所需的动作。在其他情况下，可能需要额外的工具，这些工具可能不适合在“正常”条件下安装。

提议的变更

实现一种将处于 active 状态的节点，执行步骤并将节点返回到 active 状态的功能，以及一个常态化状态，以便操作员执行他们需要的其他操作。

为此，我们将实现一个 service API 动词，它会将节点移动到 servicing 状态，与现有的清理和部署流程一致。IPA ramdisk 将被启动，节点将进入 service wait 状态。

一旦 IPA 在线，就可以采取两种可能的路径。

如果使用 service_steps 参数调用了 service 动词，与 clean steps 处于同一行，那么节点状态将返回到 servicing 状态，心跳，并且在所有步骤完成后，节点将自动返回到 active 状态。

为了实现这一点，我们还需要

  • 在 Node 对象中添加一个额外的 service_step 字段。类似于 clean steps，节点 driver_internal_info 字段中也将使用 service_steps 条目。

  • 增加 API 版本。

  • 引入一个 unhold 置备状态动词，以允许恢复步骤处理/执行。

  • 根据部署步骤和清理步骤进行适当的装饰器修改，这也将与现有的部署和清理步骤保持一致。

  • 引入或修改现有的 housekeeping 定期步骤，以包括对新提议状态的处理。从数据库效率的角度来看，修改是首选，但最终由实施者决定。

在 ramdisk 使用方面，现有的 deploy_kernel 和 deploy_ramdisk 将默认用于此功能，但是 service_kernel 和 service_ramdisk 也将作为覆盖选项可用。

为了促进交接或暂停/恢复操作，我们将向步骤流程中引入两个显式步骤。

  • hold - 此步骤将暂停当前节点上步骤的执行，除非发出 unhold 命令，或者收到一组新的步骤。

  • pause - 此步骤将暂停步骤执行一段用户定义的时间。可以将其视为“睡眠”。很可能，此步骤可能会受到心跳窗口的最大睡眠时间的限制。

  • wait - 此步骤将允许操作员告诉 Ironic 等待满足某个条件才能继续执行步骤。这可能是代理上的文件出现，或者代理本地命令成功执行。此步骤可能会主动等待满足真实条件，出于逻辑原因，这将允许自动恢复。例如，需要等待的异步固件步骤。

当使用时，这些临时持有状态将采取适当的路径，例如对于 hold，节点将移动到 clean hold、deploy hold，或者在本规范中的情况，service hold 状态。暂停和等待操作将是情境性的，并且可能被视为在待定的约束条件内的瞬态操作。

对于 hold，预计 conductor 故障不会从长远来看是致命的，只要代理继续心跳。预计 unhold provision_state 操作只需删除正在进行的当前步骤名称，从而在下次心跳时允许进行下一步。

注意

Ironic 可能需要一个步骤来启用删除代理令牌，以便可以重启或重新启动代理。这预计不是一项功能，但如果认为稍后需要，则不应引起争议。

备选方案

另一种可能的替代方案似乎是继续并鼓励使用 rescue 框架，这并不是理想的，并且没有步骤执行能力，这意味着采取的任何操作都需要手动组合和外部执行。当然，今天就可以部分实现相同的基本效果。Rescue 本身启发了本规范作为功能的超集。

另一种可能性可能是扩展现有的 rebuild 动词，以允许在非破坏性、非重新部署场景中传递步骤。但是 rebuild 动词一直暗示“重新部署”，并且分离这种身份可能很困难且耗时，只能提供所需功能的一部分。贡献者不认为这是一个可行的替代方案，并且还注意到操作员混淆的问题，因此这不太可能成为另一种替代方案。

数据模型影响

添加一个新的 node 字段 service_step，这将需要在数据库中添加一列，但这是一个相对低影响的数据库更改。该字段将不会被索引。

使用子字段值 driver_internal_info[‘service_steps’] 和 driver_internal_info[‘service_step_index’]。

状态机影响

将向状态机添加新的状态

State

描述

states.SERVICING

修改“不稳定”状态，指示已持有锁并正在发生操作。

states.SERVICEWAIT

一个中间的不稳定状态，Ironic 正在等待一个操作，例如来自代理的 heartbeat 开始。开始。

states.SERVICEFAIL

一个错误状态，指示在处理请求的过程中发生错误。这是一种稳定状态，直到操作员将其从状态中移除。这可能是任何服务或取消服务过程中发生的任何故障的结果。

states.SERVICEHOLD

一个稳定状态，用于基于使用 hold 步骤的节点。从 hold 状态移除节点将涉及 unhold 置备状态动词。

一般流程将是

ACTIVE -> SERVICING -> SERVICEWAIT -> SERVICE

在自动化流程的情况下

ACTIVE -> SERVICING -> SERVICEWAIT -> SERVICING ->

如果用户确定他们需要分阶段执行操作，则应能够在已经处于 service 状态时调用 service step。

SERVICE -> SERVICING -> SERVICEWAIT -> SERVICE

在完全 conductor 端修改的情况下，例如应用带外固件更新

ACTIVE -> SERVICING -> ACTIVE

如果发生错误，可以使操作失效或将节点返回到 *active* 状态

SERVICING -> SERVICEFAIL -> ACTIVE SERVICING -> SERVICEFAIL -> SERVICING

为了促进与此相关的流程增强，将添加额外的状态以与现有的步骤框架更改保持一致。

State

描述

states.DEPLOYHOLD

一个 hold 状态，允许使用 hold 步骤名称，以允许跨步骤框架的功能。

states.CLEANHOLD

一个具有不同状态名称的相同状态，与前面指示的 deploy hold 状态不同。这些区分开来的名称主要是为了防止混淆以及 target_provision_state 的额外逻辑。

除了这些新状态之外，预计还会出现新的状态动词

  • service - 触发 service steps 框架的动词。

  • unhold - 触发释放持有状态并启用步骤继续执行的动词。

在从 service 状态返回的过程中，如果 ramdisk 在执行 service 请求的过程中被启动，节点将启动到默认启动设备。

REST API 影响

与社区现有的实践一致，关于节点的 provision state 字段的内容将不会受到版本保护。

注意

虽然这看起来像一个潜在的破坏性更改，但我们只有在重命名或更改状态的整体含义时才这样做。例如，None -> Available 和 Inspect Wait -> Inspecting 用于较旧的 API 客户端。换句话说，这些是全新的，不应该破坏。

注意

Nova 影响如下。

将向 API 提交新的 provision state 动词将受到版本保护，并且新的 service_steps 的有效负载将与现有的 clean_steps 和 deploy_steps 通过使用 JSON 有效负载对齐。处理请求的能力也将取决于所使用的 RPC 版本。

还需要进行相应的 API 客户端更改，并添加一个 RBAC 策略以允许限制 service 动词，因为项目范围的 lessee-admin 用户能够发出 provision state 更改。该规则的访问范围预计将限制为适当的系统范围和项目范围所有者角色，与现有的策略别名 SYSTEM_MEMBER_OR_OWNER_ADMIN 一致。

客户端 (CLI) 影响

“openstack baremetal” CLI

需要在客户端中添加 baremetal node service 和 baremetal node unservice 命令。

“openstacksdk”

OpenStackSDK 的 set_provision_state 方法需要一个额外的参数才能传递 service steps。

RPC API 影响

需要一个新的 do_node_service RPC 方法，这也需要增加 RPC 接口版本。

从 service 状态移除节点预计将使用 do_provision_action RPC 方法，但 API 可能需要在发出调用之前验证正在运行的 RPC 版本。

由于此添加，在可以使用此功能之前，两个服务都需要升级。

驱动程序 API 影响

将添加/修改装饰器以启用适当验证和调用步骤，并在需要该功能时启用。预计不会有其他驱动程序 API 更改。我们仅指出这一点，因为它需要在相关操作/步骤上执行。

Nova 驱动程序影响

对 Nova 的 virt/ironic/driver.py 代码的审查表明，由于新状态被忽略，预计不会产生影响。因此，考虑到我们不将新状态隐藏在 API 版本更改之后，除非影响到 Nova，我们认为不需要额外的处理。

我们 可能希望引入一个版本保护来返回 VirtDriverNotReady 异常，如果 Nova 用户在 baremetal 节点处于这些状态之一时尝试执行取消置备或 vif 操作，因为这是一个通常无害的“暂时不可用”异常，但应该与 Nova 团队进一步讨论。

Ramdisk 影响

预计需要 get_service_steps 和 execute_service_step 方法来支持代理中的此功能。缺乏这些代理端命令不应被视为故障。

预计我们希望代理继续心跳，同时等待工作，这不会破坏旧版本的代理。

安全影响

存在潜在的安全影响，即在 Ironic 的默认安全模型下，lessee admin 能够触发 provision state 更改。允许 lessee，至少是手动分配的 lessee，能够服务固件，只要它与“批准”和“已知”版本一致，这是一种有效的操作用例。

最好同时推进 keylime 集成，并对 service 动词的使用放置一个策略规则。

注意

我们可能希望允许代理心跳和回调 URL，如果它已移动到不同的网络。这确实存在安全影响，但可以更快地应用 fast-track。

其他最终用户影响

无

可扩展性影响

为了协调错误，可能需要引入一个额外的定期任务来识别故障。除了这种潜在的额外定期状态之外，预计不会产生可扩展性影响。

性能影响

预计不会产生性能影响。

其他部署者影响

此功能承认并鼓励操作员以认识到我们可能不是工作流程的驱动程序的方式进行集成，但节点需要在继续之前处于特定状态。

话虽如此，预计不会对部署者产生直接影响，但操作员可能需要并期望大量信息来适当解释该功能，以及他们如何利用它来自动化工作流程并获得一致的操作体验。

开发人员影响

预计没有。

实现

负责人

待办事项

志愿者？如果我能得到人们承诺进行审查，我很乐意参与其中。

主要负责人

<IRC handle, email address, or None>

其他贡献者

<IRC 用户名、电子邮件地址、无>

工作项

  • 将 service_step 添加到节点对象模型和数据库。

  • 更新状态机配置

  • 将步骤检索方法添加到代理。

  • 添加用于触发状态动作和调用的导体内部方法。

  • 添加代理客户端方法调用，以从代理检索步骤列表。

  • 添加代理客户端方法调用，以便将代理的 DHCP 作为服务步骤重新触发。

  • 添加服务动作的 RPC 方法。

  • 添加服务动词的 API 支持。

  • 添加网络内部机制，将机器放置到有效的网络上，以便进行服务操作。

  • 将适当的步骤动作装饰为“服务步骤”。

  • 编写 tempest 测试场景。

依赖项

无

测试

需要为此编写 tempest 测试场景。预计测试场景将执行 pause、wait 或 hold 步骤之一。

升级和向后兼容性

除了本文档中已经记录和探讨的内容外，预计不会出现额外的升级或兼容性问题。

文档影响

我们的“管理员”文档需要添加一个额外的部分来涵盖此功能，就像过去其他主要功能一样。

参考资料