活动节点创建¶
https://bugs.launchpad.net/ironic/+bug/1526315
本规范旨在允许与 ironic API 的交互更加宽松,以便操作员可以将硬件集群迁移到 ironic 进行管理。
问题描述¶
目前,ironic API 会显式地将新节点的 state 设置为 ironic 工作流中的起始步骤。
作为硬件集群生命周期管理的一部分,操作员期望能够利用其现有的库存数据和分配记录来迁移库存和控制系统,用于其硬件集群。最终这意味着导入的主机可能已经分配并且无法立即分配。
对于多个不同的 OpenStack 基础设施的操作员来说,允许操作员将正在运行的裸机主机从一个“系统”迁移到另一个“系统”是合理的,而这些“系统”最终是更大基础设施的组成部分,而无需立即重新配置硬件。
提议的变更¶
允许 API 客户端直接从 MANAGEABLE 状态过渡到 ACTIVE 状态,绕过节点的实际部署。
创建新的 API provision_state 动词
adopt,该动词调用ADOPTING状态转换。创建新的机器状态转换
ADOPTING,该状态仅在MANAGEABLE状态下有效,并允许操作员直接将节点移动到active状态。此转换将取决于成功的接口验证。如果此转换失败,节点将移动到ADOPTFAIL,这将允许用户识别采用失败的节点。创建新的机器状态
ADOPTFAIL,当ADOPTING转换失败时,机器将设置为此状态。此状态将允许用户通过adopt重新尝试ADOPTING,或通过manage将节点过渡到MANAGEABLE状态。此外,ADOPTFAIL状态将列在允许从 ironic 数据库删除节点的 state 列表中。API 客户端更新,以提供 CLI 接口来调用此功能。
创建明确的文档,涵盖
- Use cases of the feature while explicitly predicating that proper operation requires node validation to succeed. - Explicitly detail that it is the operator's responsibility to define the node with all relevant appropriate configuration else the node could fail node state provision operations of ``rebuild`` and ``delete``. Which would result in manual intervention being necessary. - Explain the basic mechanics of the use of the adoption feature to users in order to help convey the importance of the correct information being populated.
备选方案¶
逻辑替代方案是删除对 API 客户端发布内容的限制,以允许调用者显式地声明或调用节点以在 ACTIVE 状态下创建。由于社区希望节点在导入时具有完整的功能,并进行驱动程序接口验证,因此实现似乎更适合作为状态转换而不是纯 API 逻辑来实现。
或者,我们可以编写操作员文档来帮助操作员直接将节点加载到 ironic 数据库中,并附带这样做带来的注意事项,并要求在任何数据库模式更改时更新文档。
数据模型影响¶
无
状态机影响¶
使用中间状态 ADOPTING 实现从 MANAGEABLE 状态到 ACTIVE 状态的新状态转换,该状态执行以下操作。
触发 conductor 节点接管逻辑。
完成时,节点状态设置为
ACTIVE。
如果在 ADOPTING 状态下接管逻辑失败,节点将返回到 ADOPTFAIL 状态,用户将能够重试采用操作或删除节点。
将 ADOPTFAIL 添加到 DELETE_ALLOWED_STATES 列表中。
REST API 影响¶
添加新的 state 动词 adopt,该动词触发到 ADOPTING 状态的转换。对于调用 API 版本不足的客户端,此动词将不可用。
由于此更改,需要增加 API 微版本。
客户端 (CLI) 影响¶
更新 ironicclient CLI,以详细说明 adopt 是可能的 provision state 选项。
更新 ironicclient 微版本。
RPC API 影响¶
无
驱动程序 API 影响¶
无
Nova 驱动程序影响¶
无
Ramdisk 影响¶
N/A
安全影响¶
无
其他最终用户影响¶
无
可扩展性影响¶
无
性能影响¶
对于使用此功能的用户来说,API 影响最小,因为在 ACTIVE 状态下创建节点需要使用 API 进行多次调用,任何尝试利用此功能的用户都需要这样做。
执行批量主机加载的用户可能会发现多次 API 调用在创建、验证和采用节点以及轮询节点当前状态后再进行下一步操作方面存在一些问题。批量加载器还应注意其配置,因为如果需要为节点的正常操作在 conductor 上暂存项目,则可能会导致 conductor 消耗磁盘空间和网络带宽。
其他部署者影响¶
允许更轻松地采用预先存在的硬件集群的管理器。
操作员有可能定义配置最少的硬件集群,以最初将节点添加到 ironic。其结果是,操作员可能会在定义了不足信息的情况下对节点采取行动。此风险将在生成的文档中记录,以帮助突出显示风险并提供指导,以防止这种情况发生,如果用户尝试采用已经“混乱”的库存。
开发人员影响¶
无
实现¶
负责人¶
- 主要负责人
juliaashleykreger
- 其他贡献者
无
工作项¶
Conductor 状态机更改
API 微版本和更新以及适当的逻辑
CLI 节点设置 provision state 选项添加
文档更新
依赖项¶
无
测试¶
添加单元测试以及 tempest 测试,以显式测试接口。
升级和向后兼容性¶
此功能将无法通过 API 微版本接口由较旧的 API 客户端使用。
文档影响¶
需要更新文档以表示此新功能。
参考资料¶
无