Bare Metal State Machine

状态机图

下图显示了 Ironic 节点在其生命周期内经历的配置状态。该图还描绘了将节点转换为不同状态的事件。

稳定的状态用较粗的边框突出显示。从稳定状态的所有转换均由 API 请求启动。从非稳定状态也可以进行一些其他的 API 启动转换。这些 API 启动转换的事件用‘(通过 API)’表示。内部地，conductor 启动其他的转换（以灰色显示）。

Ironic state transitions

请点击上方的图片以查看完整尺寸的图表，因为在文档中存在会导致它被缩放。

注意

某些转换有别名

  • deploy 是 active 的别名。

  • undeploy 是 deleted 的别名

注册和准备

enroll (稳定状态)

这是使用 API 版本 1.11 或更高版本创建的所有节点开始的状态。当节点处于 enroll 状态时，ironic 唯一知道的是它存在，并且 ironic 自身无法采取任何进一步的操作。一旦节点在其 node.driver_info 中设置了驱动程序/接口及其所需的信息，就可以通过使用 manage 动词设置节点的配置状态，将其转换为 verifying 状态。

有关注册节点的更多信息，请参阅 使用 Ironic 注册硬件。

verifying

ironic 将验证它是否可以使用在 node.driver_info 中提供的信息以及分配给它的驱动程序/硬件类型和接口来管理该节点。这包括访问它们所通信的任何节点控制机制的凭据是否有效。

manageable (稳定状态)

一旦 ironic 验证了可以使用在节点创建时传递的驱动程序/接口和凭据来管理该节点，该节点将被转换为 manageable 状态。从 manageable，节点可以转换为

  • manageable (通过 cleaning) 通过使用 clean 动词设置节点的配置状态。

  • manageable (通过 inspecting) 通过使用 inspect 动词设置节点的配置状态。

  • available (如果启用了自动清理，则通过 cleaning) 通过使用 provide 动词设置节点的配置状态。

  • active (通过 adopting) 通过使用 adopt 动词设置节点的配置状态。

manageable 是当需要对节点进行任何更新时（例如更改 driver_info 中的字段以及对分配给节点的 ironic 端口上的网络信息的更新）应将节点移动到的状态。

manageable 也是可以从这些失败状态转换到的唯一稳定状态

  • adopt failed

  • clean failed

  • inspect failed

inspecting

inspecting 将利用节点内省来更新硬件派生的节点属性，以反映硬件的当前状态。通常，如果检查是同步的，节点将转换为 manageable，或者如果检查是异步的，则转换为 inspect wait。如果发生错误，节点将转换为 inspect failed。

有关检查的更多信息，请参阅 硬件检查。

inspect wait

当异步检查正在进行时，使用此配置状态。成功检查的节点应转换为 manageable 状态。

inspect failed

当节点的检查失败时，节点将进入此状态。从这里，节点可以转换为

  • inspecting 通过使用 inspect 动词设置节点的配置状态。

  • manageable 通过使用 manage 动词设置节点的配置状态

cleaning

处于 cleaning 状态的节点正在被擦除并重新编程为已知配置。

当节点处于 cleaning 状态时，这意味着 conductor 正在执行清理步骤（对于带外清理步骤）或准备环境（构建 PXE 配置文件、配置 DHCP 等）以运行带内清理步骤的 ramdisk。

clean wait

就像 cleaning 状态一样，处于 clean wait 状态的节点正在被擦除和重新编程。不同之处在于，在 clean wait 状态下，conductor 正在等待 ramdisk 启动或正在运行的带内清理步骤完成。

如果任务允许，可以通过使用 abort 动词设置节点的配置状态来中断处于 clean wait 状态的节点的清理过程。

部署和撤销

available (稳定状态)

在节点成功预配置和清理后，它们将被移动到 available 状态，并准备好进行配置。从 available，节点可以转换为

  • active (通过 deploying) 通过使用 active 或 deploy 动词设置节点的配置状态。

  • manageable 通过使用 manage 动词设置节点的配置状态

deploying

处于 deploying 的节点正在准备在其上运行工作负载。这包括运行一系列任务，例如

  • 设置适当的 BIOS 配置

  • 分区驱动器并铺设文件系统。

  • 创建任何其他资源（节点特定的网络配置、config drive 分区等），这些资源可能由其他子系统需要。

有关部署节点的更多信息，请参阅 使用 Bare Metal 服务部署 和 使用部署步骤和模板。

wait call-back

就像 deploying 状态一样，处于 wait call-back 的节点正在被部署。不同之处在于，在 wait call-back 中，conductor 正在等待 ramdisk 启动或执行需要在节点上带内运行的部署部分（例如，安装引导加载程序或将镜像写入磁盘）。

可以通过使用 deleted 或 undeploy 动词设置节点的配置状态来中断处于 wait call-back 的节点的部署。

deploy failed

当部署失败时，节点将进入此状态，例如等待 ramdisk PXE 启动超时。从这里，节点可以转换为

  • active (通过 deploying) 通过使用 active、deploy 或 rebuild 动词设置节点的配置状态。

  • available (通过 deleting 和 cleaning) 通过使用 deleted 或 undeploy 动词设置节点的配置状态。

active (稳定状态)

处于 active 的节点在其上运行着工作负载。ironic 可能会定期收集带外传感器信息（包括电源状态）。处于 active 的节点可以转换为

  • available (通过 deleting 和 cleaning) 通过使用 deleted 或 undeploy 动词设置节点的配置状态。

  • active (通过 deploying) 通过使用 rebuild 动词设置节点的配置状态。

  • rescue (通过 rescuing) 通过使用 rescue 动词设置节点的配置状态。

deleting

处于 deleting 状态的节点正在被从运行活动工作负载中拆除。在 deleting 中，ironic 拆除并删除在 deploying 或 rescuing 中添加的任何配置和资源。

error (稳定状态)

当删除活动部署失败时，节点将进入此状态。从 error，节点可以转换为

  • available (通过 deleting 和 cleaning) 通过使用 deleted 或 undeploy 动词设置节点的配置状态。

adopting

此状态允许 ironic 接管具有现有工作负载的裸机节点的管理。通常，当裸机节点使用 API 版本 1.11 或更高版本注册并由 ironic 管理时，它必须通过 cleaning 和 deploying 才能到达 active 状态。但是，那些具有现有工作负载的裸机节点不需要再次部署或清理，因此此转换允许这些节点直接从 manageable 移动到 active。

有关此功能的更多信息，请参阅 节点采用。

Rescue

rescuing

处于 rescuing 的节点正在准备执行救援操作。这包括运行一系列任务，例如

  • 设置适当的 BIOS 配置。

  • 创建任何其他资源（节点特定的网络配置等），这些资源可能由其他子系统需要。

有关此功能的更多信息，请参阅 救援模式。

rescue wait

就像 rescuing 状态一样，处于 rescue wait 的节点正在被救援。不同之处在于，在 rescue wait 中，conductor 正在等待 ramdisk 启动或执行需要在节点上带内运行的救援部分（例如，为名为 rescue 的用户设置密码）。

可以通过使用 abort 动词设置节点的配置状态来中止处于 rescue wait 的节点的救援操作。

rescue failed

当救援操作失败时，节点将进入此状态，例如等待 ramdisk 通过 PXE 启动超时。从这里，节点可以过渡到

  • rescue (通过 rescuing) 通过使用 rescue 动词设置节点的配置状态。

  • active（通过 unrescuing）通过使用 unrescue 动词设置节点的配置状态。

  • available（通过 deleting）通过使用 deleted 动词设置节点的配置状态。

rescue（稳定状态）

处于 rescue 状态的节点在其上运行着救援 ramdisk。Ironic 可能会定期收集带外传感器信息（包括电源状态）。处于 rescue 状态的节点可以过渡到

  • active（通过 unrescuing）通过使用 unrescue 动词设置节点的配置状态。

  • available（通过 deleting）通过使用 deleted 动词设置节点的配置状态。

unrescuing

处于 unrescuing 状态的节点正在被准备以从 rescue 状态过渡到 active 状态。这包括运行一系列任务，例如设置适当的 BIOS 配置，例如更改启动设备。

unrescue failed

当取消救援操作失败时，节点将进入此状态。从这里，节点可以过渡到

  • rescue (通过 rescuing) 通过使用 rescue 动词设置节点的配置状态。

  • active（通过 unrescuing）通过使用 unrescue 动词设置节点的配置状态。

  • available（通过 deleting）通过使用 deleted 动词设置节点的配置状态。

Servicing

servicing

处于 servicing 状态的节点是正在对其进行维护的节点。此维护类似于清洁，但是在当前处于 active 状态的节点上执行的，并在完成后将其返回到 active 状态。

当节点处于 servicing 状态时，这意味着 conductor 正在执行服务步骤或准备环境以执行该步骤。

有关节点维护的更多详细信息，请参阅 节点维护。

service wait

与 servicing 状态一样，处于 service wait 状态的节点正在使用服务步骤进行维护。不同之处在于，在 service wait 状态下，conductor 正在等待 ramdisk 启动或正在带内运行的清洁步骤完成。

如果正在运行的任务允许，可以通过使用 abort 动词设置节点的配置状态来中断处于 service wait 状态的节点的维护。

service failed

当服务操作失败时，节点将进入此状态，例如等待 ramdisk 通过 PXE 启动超时。从这里，节点可以过渡到

  • active（通过 servicing）通过使用 service 动词设置节点的配置状态。

  • rescue (通过 rescuing) 通过使用 rescue 动词设置节点的配置状态。

  • active 通过使用 abort 动词设置节点的配置状态。

注意

在尝试中止处于 service wait 或 service failed 状态的节点上的服务操作之前，用户必须检查机器的远程控制台作为预防措施，并确保节点上没有正在运行的固件更新。中止服务可能会导致电源循环操作，从而中断正在运行的更新，导致硬件不可逆转的损坏。确认没有正在运行的更新操作后，使用 abort 动词预计不会引起任何问题。