将“enroll”状态添加到状态机¶
https://blueprints.launchpad.net/ironic/+spec/enroll-node-state
此蓝图引入了一个名为 enroll 的新状态，我们之前已经同意在 新的状态机 规范中引入它。
问题描述¶
目前，节点在创建时会被置于 available 状态，该状态旨在替代 NOSTATE。只要它们具有所有必需的属性，这些节点将立即可供 Nova 用于部署。
然而，新的状态机允许操作员对节点进行检查和擦除。状态机允许在节点达到 available 状态之前完成这些操作。
更糟糕的是，Kilo 周期中引入的清理功能也应该在节点变为 available 状态之前发生。
提议的变更¶
添加一个新的状态
enroll，节点可以从该状态通过一个名为manage的操作过渡到manageable状态。manage过渡将导致验证节点上的电源和管理接口。 还会尝试获取节点上的电源状态，以实际验证提供的电源凭据。如果成功，节点将进入
manageable状态。 如果失败，它将返回到enroll状态，并且将设置last_error。禁用
enroll状态下节点的 sync_power_state，因为预计该状态下的节点不应具有有效的电源凭据。引入一个新的 API 微版本，使新创建的节点出现在
enroll状态，而不是available状态。之后客户端-服务器交互将如下所示
新的客户端（使用新的 API 版本）+ 新的服务器：节点出现在
enroll状态。新的客户端 + 旧的服务器：客户端从服务器获得响应，表明节点处于
available（或none）状态。 客户端向用户发出警告。旧的客户端（或使用旧 API 版本的新的客户端）+ 新的服务器：由于版本控制，节点将出现在
available（或none）状态。
记录我们将默认移动到
enroll状态的重大变更。更新 DevStack gate 以显式请求新的微版本并修复测试。
发布一个新的
ironicclient版本，默认使用这个新的微版本。 在升级说明中清楚地记录这个重大变更。
备选方案¶
我们可以要求人们在检查或擦除之前手动将节点移动到 manageable 状态。 我们也不会验证电源和管理接口。
数据模型影响¶
无
状态机影响¶
enroll成为一个有效的节点状态，可以过渡到verifying通过manage操作
verifying成为一个有效的瞬态节点状态，可以过渡到manageable在doneenroll在fail并且将设置last_error。
REST API 影响¶
添加新的 API 微版本。 当客户端声明它时，节点创建 API 应该默认创建处于
enroll状态的节点。
客户端 (CLI) 影响¶
将发布一个新的客户端版本，默认使用新的微版本（并破坏许多流程）。
RPC API 影响¶
无
驱动程序 API 影响¶
无
Nova 驱动程序影响¶
双重检查 Nova 驱动程序是否会使用处于
enroll状态的节点为了保持一致性，同步
nova/virt/ironic/ironic_states.py
预计没有功能影响。
安全影响¶
预计没有
其他最终用户影响¶
使用新的微版本，节点将出现在 enroll 状态。 应该采取另外两个步骤才能使它们可用于部署：manage 和 provide。 如果启用，将进行清理。
可扩展性影响¶
无
性能影响¶
无
其他部署者影响¶
参见 升级和向后兼容性。
开发人员影响¶
无
实现¶
负责人¶
- 主要负责人
Dmitry Tantsur, IRC: dtantsur, LP: divius
- 其他贡献者
无
工作项¶
创建新的状态和转换
引入新的微版本，节点在创建时默认进入
enroll确保我们的测试不会中断（修复 devstack 等）
将 ironicclient 默认设置为新的微版本
依赖项¶
无
测试¶
应该修改 Tempest 测试以测试
enroll状态。
升级和向后兼容性¶
更改是向后兼容的，虽然它不是 ironicclient 中的默认设置。
一旦新的微版本成为 ironicclient 中的默认版本，当没有使用显式微版本时，它将破坏现有的流程。
文档影响¶
使用新的状态和转换应该记录下来
应该更新升级说明
