允许 ramdisk 部署用户指定他们的启动 ISO¶
https://storyboard.openstack.org/#!/story/2007633
在支持虚拟媒体的情况下，有时操作员可能希望使用特定的虚拟媒体镜像启动机器，以便于机器部署，甚至只是完成固件升级等操作。
提供一个接口来指示“启动到这个”iso，似乎是合乎逻辑的。
问题描述¶
问题详细描述
ramdisk部署接口允许用户定义一个内核和 ramdisk，用于启动 ramdisk 实例，在初始部署之后，该实例被认为是一个处于活动状态的已部署机器。目前，由于
ramdisk部署接口的限制，用户无法为虚拟媒体指定 ISO。他们必须提供一个内核/ramdisk，并且在虚拟媒体的情况下，必须重新构建它。
提议的变更¶
允许利用
instance_info/boot_iso参数作为用于从显式 ISO 镜像启动的媒介，该镜像将被 conductor 支持下载、缓存和提供给裸机。教导与传递相关的代码提供相同的基础能力，通过分解 ISO、将参数附加到
grub2和isolinux配置中，并重新打包 ISO 文件以进行部署，来实现这一点。
备选方案¶
使用外部配置工具，并在适用时将节点
adopt到 Ironic 中。预先掌握的机器特定配置到 ISO 镜像中，最终将准备和执行工作负载推送到 API 用户。
数据模型影响¶
无，这利用了现有的数据模型。
状态机影响¶
无
REST API 影响¶
无，此更改利用了 Ironic 数据模型中现有的 JSON 数据字段。
客户端 (CLI) 影响¶
“openstack baremetal” CLI¶
无
“openstacksdk”¶
无
RPC API 影响¶
无
驱动程序 API 影响¶
无
Nova 驱动程序影响¶
无
Ramdisk 影响¶
无
安全影响¶
无
其他最终用户影响¶
无
可扩展性影响¶
如果用户请求多个并发部署，配置注入可能会消耗大量的磁盘空间，存在这种可能性。
此外，我们可能希望启用某种逻辑来防止 conductor 消耗过多的磁盘空间，出于清理的原因，但是 conductor 无法真正理解这是否是永久使用，或者不是。理想情况下，操作员文档应该更新，以帮助规划这种情况下的扩展。或者，我们可能希望引入一个“一次性”指示标志，这样我们就不会在活动机器上接管后尝试持久化 ISO。
性能影响¶
大量并发部署可能会由于整体系统性能限制而使 conductor 变慢，具体取决于使用的选项和设置。
其他部署者影响¶
无
开发人员影响¶
预计没有，但是我们可能会专注于在 redfish 虚拟媒体代码路径中实现这一点，并且应该尝试确保我们不要使这些更改 redfish 接口特定，因为 Ironic 中存在支持虚拟媒体的其他驱动程序。
实现¶
负责人¶
- 主要负责人
Julia Kreger <juliaashleykreger@gmail.com>
工作项¶
实现支持将显式启动 ISO 传递到 ramdisk 接口。
实现支持将配置注入到启动 ISO 中。
记录 ramdisk 接口的功能，包括如何利用此功能。
依赖项¶
无
测试¶
单元测试足以确保此功能没有损坏。
一个 tempest 测试也可能是可行的，但我们可能希望与 Metal3 社区合作进行集成测试，因为最终这本质上只是在利用虚拟媒体和 ramdisk 接口时的一个集成测试项目。
升级和向后兼容性¶
N/A
文档影响¶
我们将要更新 ramdisk 部署接口的文档，以详细说明此功能。
参考资料¶
无
