新讽刺状态机提案。¶

https://blueprints.launchpad.net/ironic/+spec/new-ironic-state-machine

该蓝图建议重构 Ironic 配置状态机，以修复当前的一些不足，并使其更容易让驱动程序和外部编排代理管理 Ironic 中的节点。

注意：此蓝图描述了我们希望新的状态机具有的功能。此规范的实际实现，包括详细的升级路径和技术细节，将由其他规范处理。

问题描述¶

当前的 Ironic 状态机存在一些不足

NOSTATE 是一种指示我们没有关于节点状态信息的状态。这对于讨论节点的电源状态可能很好，但我们应该始终知道节点处于哪个配置状态。
我们还需要一个状态来将节点置于执行配置任务的环境中，这些任务合理地预计需要数小时才能完成，例如 RAID 配置和老化测试。强制 Ironic 管理节点的上游消费者在请求节点和获取节点之间等待数小时是不合理的，因此将这些任务作为 DEPLOYING 或 DEPLOYWAIT 的一部分执行是不可行的。
我们还需要一个地方来处理节点退役任务。当前的退役蓝图通过添加“decommissioning”（退役中）和“decommissioned”（已退役）状态来处理此问题，但对新添加的节点执行退役任务也很有用。
我们还需要允许外部编排系统挂接到每个节点的某些状态机部分，以便它们可以管理节点生命周期的某些部分，而无需将该功能导入 Ironic。如何实现这一点的细节将在另一份规范中介绍。

提议的变更¶

当前状态机

       NOSTATE//NONE +----------+------+\     [DEPLOYWAIT//DEPLOYDONE]
            ^             R:active      +         ^
            |                           |         |
            +                           v         v
     [DELETING//DELETED]        +--->[DEPLOYING//DEPLOYDONE]
       +    ^                   |       +               +
       |    |          R:rebuild|       |               |
       v    |                   |       |               v
ERROR//NONE |                   |       |          DEPLOYFAIL//NONE
            |                   |       v
            |                   +---+ACTIVE//NONE
            |    R:deleted              +
            +---------------------------+

当前状态机的图例

[STATE] 表示一个活动状态。Ironic 正在对节点执行某些操作。
STATE 表示一个稳定（或被动）状态。除非通过 API 接收到请求，否则 Ironic 不会转换状态。
R:request 表示必须传递给 API 的请求，以启动从稳定状态转换。

Ironic 的 API 呈现了节点配置状态的两个字段：current（当前）和 target（目标）。因此，在此图中，所有状态都表示为“CURRENT-slash-slash-TARGET”状态。

当前状态机的状态描述可以在这里 <https://github.com/openstack/ironic/blob/stable/icehouse/ironic/common/states.py> 找到。

新的状态机

ENROLL -----------> [VERIFY*/MANAGEABLE]
        R:manage            |
                            v
                +------>MANAGEABLE<--------+
                |        +  + ^ |          |
                | R:clean|  | | |R:inspect |
                +        |  | | |          +
   [CLEAN*/MANAGEABLE]<----+  | | +---->[INSPECT*/MANAGEABLE]
                            | |
                   R:provide| +----------+
                    +-------+   R:manage |
                    v                    +
           [CLEAN*/AVAILABLE]+------->AVAILABLE
                    ^                   +
                    |                   |R:active
                    +                   v
          [DELETE*/AVAILABLE]         [DEPLOY*/ACTIVE]
                    ^                   +  ^
                    |R:delete           |  |R:rebuild
                    |                   v  +
                    +------------------+ACTIVE+-----------+
                    |                      ^              |R:rescue
                    |                      |              v
                    |                      +        [RESCU*/RESCUE]
                    |                [UNRESCU*/ACTIVE]    +
                    |                      ^              |
                    |                      |R:unrescue    |
                    |                      |              v
                    +----------------------+----------+RESCUE

新的状态机的图例

[STATE*/TARGET]

STATE* 表示一个活动状态、一个瞬间状态和一个失败状态。活动状态具有 -ING 后缀，瞬间状态具有 -ED 后缀，失败状态具有 -FAIL 后缀。在活动状态下，Ironic 正在对节点执行某些操作。

如果在活动（-ING）状态期间执行的步骤成功，Ironic 将自动转换为瞬间（-ED）状态，然后转换为图表上指示的下一个状态。除非对瞬间状态有特殊规则，否则不会单独描述它们。
如果失败，Ironic 将转换为失败（-FAIL）状态。除非对失败状态有特殊规则，否则不会单独描述它。

TARGET 表示 Ironic 将尝试从活动状态转换为的目标状态。TARGET 必须是一个稳定状态。

STATE

一个稳定（或被动）状态，通常是特定状态转换的目标。除非有 API 请求执行，否则 Ironic 不会从该状态转换。

R:request

表示标记的转换是由于此特定 API 调用而发生的。

新状态的描述

ENROLL（注册）

所有节点都从该状态开始。当节点处于 ENROLL 状态时，Ironic 唯一知道的是它存在，并且 Ironic 自身无法采取任何进一步的操作。一旦节点在其节点属性中具有驱动程序和每个驱动程序所需的的信息，就可以通过 manage API 调用将其转换为 VERIFYING。

VERIFYING（验证中）

Ironic 将验证它是否可以使用分配的驱动程序和凭据来管理节点。对于管理节点电源状态的驱动程序，这必须涉及实际访问并确认凭据可以访问它们所通信的任何节点控制机制。

MANAGEABLE（可管理）

一旦 Ironic 验证了可以使用在节点创建时传递的驱动程序和凭据来管理节点，该节点将转换为 MANAGEABLE 状态并（可选）关机。从 MANAGEABLE，节点可以转换为

MANAGEABLE（通过 CLEANING API 调用），
MANAGEABLE（通过 INSPECTING API 调用），以及
AVAILABLE（通过 PROVIDE API 调用）。

INSPECTING（检查中）

INSPECTING 将利用节点内省来更新硬件派生的节点属性，以反映硬件的当前状态。我们预计该状态将通过驱动程序内省接口获取其数据（参考规范即将发布）。如果内省失败，节点将转换为 INSPECTFAIL。

CLEANING（清理中）

处于 CLEANING 状态的节点正在被擦除，以准备变为 AVAILABLE。CLEANING 任务的良好候选者包括

擦除驱动器。
验证固件完整性。
验证实际硬件配置是否与 node.properties 中描述的内容匹配。
引导到长期运行的部署 ramdisk，如果您希望机器在 AVAILABLE 状态下保持开启状态。

无论执行 CLEANING 期间执行什么任务，系统的明显配置都不得改变。例如，如果您拆解一组 RAID 卷以单独安全擦除每个物理磁盘，则必须重建您拆解的 RAID 卷。

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

CLEANWAIT（清理等待中）

就像 CLEANING 状态一样，CLEANWAIT 中的节点正在准备变为 AVAILABLE。区别在于，在 CLEANWAIT 中，conductor 正在等待 ramdisk 启动或正在进行的清理步骤完成（同步）。

可以通过 abort API 调用中断 CLEANWAIT 节点中的清理过程。

AVAILABLE（可用）

处于 AVAILABLE 状态的节点已清理、预配置并准备好进行配置。从 AVAILABLE，节点可以转换为

ACTIVE（通过 DEPLOYING API 调用）。
MANAGEABLE（通过 manage API 调用）

DEPLOYING（部署中）

处于 DEPLOYING 状态的节点正在积极准备在其上运行工作负载。这主要应包括运行一系列短时间任务，例如

设置适当的 BIOS 配置
分区驱动器并铺设文件系统。
创建任何其他资源（节点特定的网络配置等），这些资源可能由其他子系统需要。

DEPLOYING 的任务应以类似于 CLEANING 处理的方式处理（细节将在另一份规范中介绍）。

DEPLOYWAIT（部署等待中）

就像 DEPLOYING 状态一样，DEPLOYWAIT 中的节点正在被部署。区别在于，在 DEPLOYWAIT 中，conductor 正在等待 ramdisk 启动或执行需要在节点上同步运行的部署部分（例如，安装引导加载程序，在不使用 iSCSI 时将镜像写入磁盘等）。

可以通过 deleted API 调用中断 DEPLOYWAIT 配置状态下的节点的部署。

ACTIVE（活动）

ACTIVE 节点在其上运行着工作负载。Ironic 可能会定期收集带外传感器信息（包括电源状态），但否则会将其置之不理。ACTIVE 节点可以转换为

RESCUE（通过 RESCUING API 调用），
AVAILABLE（通过 DELETING 和 CLEANING API 调用），或
ACTIVE（通过 DEPLOYING API 调用）。

RESCUING（救援中）

处于 RESCUING 状态的节点正在引导到临时操作系统环境，用于故障排除或维护相关原因。

RESCUE

RESCUE 旨在允许 Ironic 意识到一个节点，该节点原本正在运行工作负载，但现在已引导到不同的操作系统环境，用于维护或故障排除原因。从 RESCUE，节点可以转换为

ACTIVE（通过 UNRESCUING API 调用），或
AVAILABLE（通过 DELETING 和 CLEANING API 调用）。

UNRESCUING（取消救援中）

处于 UNRESCUING 状态的节点正在从 RESCUE 转换为 ACTIVE。Ironic 将撤消它需要执行的任何操作才能使节点进入 RESCUE

DELETING（删除中）

处于 DELETING 状态的节点正在被拆解，以停止运行活动工作负载。在 DELETING 中，Ironic 应拆解或删除它在 DEPLOYING 中添加的任何配置或资源。

备选方案¶

我们在峰会上没有想到任何合理的。

数据模型影响¶

在当前状态机下，NOSTATE 在数据库中表示为 NULL。这将需要数据库迁移才能将所有 NULL 更改为“AVAILABLE”，并进行特殊情况的 API 处理。额外的状态不应需要更改数据模型。

REST API 影响¶

我们将提供以下动词来管理状态机中的节点生命周期

动词	初始状态	中间状态	结束状态
manage	ENROLL（注册）	VERIFYING -> VERIFIED	MANAGEABLE（可管理）
clean	MANAGEABLE（可管理）	CLEANING -> CLEANED	MANAGEABLE（可管理）
inspect	MANAGEABLE（可管理）	INSPECTING -> INSPECTED	MANAGEABLE（可管理）
provide	MANAGEABLE（可管理）	CLEANING -> CLEANED	AVAILABLE（可用）
manage	AVAILABLE（可用）	(none)	MANAGEABLE（可管理）
active	AVAILABLE（可用）	DEPLOYING -> DEPLOYED	ACTIVE（活动）
rebuild	ACTIVE（活动）	DEPLOYING -> DEPLOYED	ACTIVE（活动）
rescue	ACTIVE（活动）	RESCUING -> RESCUED	RESCUE
unrescue	RESCUE	UNRESCUING -> UNRESCUED	ACTIVE（活动）
deleted	ACTIVE（活动）	DELETING -> DELETED -> CLEANING -> CLEANED	AVAILABLE（可用）
deleted	RESCUE	DELETING -> DELETED -> CLEANING -> CLEANED	AVAILABLE（可用）
deleted	DEPLOYWAIT（部署等待中）	DELETING -> DELETED -> CLEANING -> CLEANED	AVAILABLE（可用）
abort	CLEANWAIT（清理等待中）	(none)	CLEANFAIL

API 将与 active、rebuild 和 delete 动词保持向后兼容。

除非为了向后兼容性需要，否则必须在节点处于初始状态时调用动词，并且 Ironic 将执行所有操作和转换，以通过中间状态移动到结束状态。

由于我们正在添加新的状态，较旧的 API 客户端在遇到它们不理解的状态的节点时可能会表现出意外行为。

RPC API 影响¶

并非此规范的直接影响（超出 REST API 影响部分中提到的内容），但将实际实现新状态的所有待编写规范都将对 RPC 和 REST api 产生重大影响。

驱动程序 API 影响¶

是的。大量的驱动程序代码需要进行重构才能与新的每节点状态机配合使用。

Nova 驱动程序影响¶

NOSTATE 已重命名为 AVAILABLE。这将需要一些胶水代码并创建一个升级路径。

安全影响¶

可能不会，假设编码完美。

其他最终用户影响¶

是的。

可扩展性影响¶

可能没有什么重要的事情。

性能影响¶

同上。

其他部署者影响¶

节点不会自动从 ENROLL 转换为 MANAGEABLE。部署者必须分配驱动程序并将凭据添加到节点，然后调用 manage API，Ironic 才能管理节点。

节点不会自动从 MANAGEABLE 转换为 AVAILABLE，部署者需要通过 API 执行此操作，然后才能安排节点。

开发人员影响¶

当前和新的 Ironic 驱动程序需要进行重构以符合新的状态机。

实现¶

负责人¶

目前还没有。

工作项¶

需要编写规范来阐述新状态机所暗示的实施细节。

依赖项¶

大多数涉及 Ironic 驱动程序的蓝图都会受到影响，但此蓝图是供应商无关的。

测试¶

此规范没有，但实施规范需要解决更改的测试影响。

升级和向后兼容性¶

此规范没有，但实施规范需要解决升级和向后兼容性。

文档影响¶

应将此规范用作新状态机的初始文档。

参考资料¶

有人有开发者会话笔记的链接吗？我有点忙于当白板猴子：https://i.imgur.com/tCxUCYk.jpg

关于新的 Ironic 状态机的一个提案。