2024.2 项目工作项¶
在 4 月 8 日至 12 日举行的最新虚拟项目团队会议期间，Ironic 开发人员和运维人员讨论了多个主题，以规划下一个 2024.2 (Dalmatian) 版本的开发工作。我们在此文档中总结讨论结果，提供下一开发周期主要优先事项的列表。有关更多信息，请查看每个主题的链接或通过 IRC 联系 Ironic 团队。
Ironic 贡献者工作繁忙，他们的工作涉及多个开源项目，并承担不同的下游责任。我们无法保证任何或全部计划中的工作都能完成。
- 表格中的每个项目都包括
工作项名称，链接到描述
- 类别可以是…
维护：保持 Ironic 正常运行必须执行的工作
Bugfix：增强现有代码以覆盖更多边缘情况并解决 bug 的工作
Feature：一个以前不存在的新 Ironic 功能
Champions 是最熟悉相关技术的人员，如果您想实施工作项，他们是一个很好的资源。
跟踪链接是指通常跟踪工作的 bug 链接。
名称 |
类别 |
跟踪 |
Champions |
|---|---|---|---|
维护 |
N/A |
JayF |
|
Feature |
N/A |
stephenfin |
|
Feature |
masghar |
||
Feature |
N/A |
janders, dtantsur, TheJulia |
|
Feature |
N/A |
dtantsur |
|
维护 |
N/A |
团队协作 |
|
维护 |
N/A |
JayF, rpittau |
|
Feature |
JayF |
||
Feature |
JayF, TheJulia |
||
Feature |
N/A |
TheJulia |
|
Feature |
N/A |
JayF, cid |
目标详情¶
Ironic 文档改进¶
我们将利用专业文档编写人员的专业知识来审查所有 Ironic 文档，并提出一份可执行的工作列表，以改进文档。
我们在 PTG 期间完成了一个初稿，但我们旨在在 Dalmatian 周期内完成它并完成主要更改。
API 响应模式验证¶
SDK 团队希望为核心 OpenStack 服务生成 OpenAPI 模式，并将它们存储在树中，以确保完整性和最新性，避免将另一个大型交付物放在 SDK 团队身上，并允许服务团队修复他们自己的问题。
最终 API 文档将从 os-api-ref 切换到 SDK 团队开发和拥有的新工具，但这只是一个远期目标。当这种情况发生时，只有 Sphinx 扩展才会位于树外（就像今天的 os-api-ref 一样）。
优势列表包括
拥有避免意外引入 API 更改的机制。
API 文档将（自动）得到验证。
突出显示 API 中的错误和问题。
第一步是编写规范并为其中一个 API 展示框架示例。
将 Inspector 合并到 Ironic¶
Ironic Inspector 最初是作为 Ironic 外部的服务创建的。现在，它被全球大量的 Ironic 运维人员使用，应该与主要服务集成。这项工作进展顺利。我们将继续努力，直到完成为止。
Redfish 虚拟介质推送 / UpdateService¶
这实际上是两个独立的提案，但有很多共同之处，最终目标是找到一种方法，通过使用“推送”模型来促进虚拟介质启动和固件更新。
我们将监控 Virtual Media Image Push 提案在 DMTF 社区中的演进，并将考虑 Redfish 标准中已经存在的 UpdateService 作为未来替代方案，可能在下一个周期中进行评估。
虚拟介质 TLS 验证¶
富士通已经提出了从 Ironic 到 BMC 的 TLS 连接验证，但我们需要研究另一个方向，以验证从 BMC 到 Ironic 服务的虚拟介质 TLS 连接。
精简 CI¶
Ironic 是 CI 中资源消耗量最大的项目之一。
在 Caracal 周期中，我们能够减少 Ironic 项目运行的作业数量，但也增加了一些。我们得出结论，我们需要采取一种将更多测试堆叠在更少作业中的方法，尽可能地整合作业，并最大限度地减少启动界面变化测试。
在 Dalmatian 周期中，我们将首先尝试将 Redfish 和 ipmi 放在一个 ironic 作业中，并更新作业列表以了解我们可以在哪里避免重复。
Tinycore IPA ramdisk 的替代方案¶
Tinycore 长期以来一直是 Ironic Python Agent ramdisk (TinyIPA) 的基础，用于 Ironic CI 中的测试。不幸的是，多年来它变得越来越小，它缺乏镜像 https 支持，它使用了一个轻量级的 libc，多次导致问题，并且我们需要维护一个非常特定的脚本系列才能构建它。
我们希望探索它的替代方案，主要候选者是也支持 DiskImage-Builder 的基于 gentoo 的镜像。
Ironic 从 nova 获取客户元数据¶
我们希望统一发送到 Ironic 和 libvirt 的客户元数据。
Ironic 当前仅设置 instance_info/instance_uuid，我们希望将其扩展为包括 project_id、user_id 和 flavor 名称，以便与 Libvirt 客户元数据设置保持一致。
所有这些字段在节点取消部署时都会被删除，类似于今天的 instance_uuid。项目 ID 未来可能用于帮助 Ironic API RBAC。
服务步骤模板¶
我们在 10 月的 Caracal PTG 期间讨论了这一点，并因此编写了一个规范。
为了进一步推进，我们需要首先根据最近 PTG 的讨论结果修改规范。
网络：Project Mercury¶
网络代表着一个真正独立的 Ironic 的下一步，这意味着找到 OpenStack 集成场景的替代方案，因此也包括 Neutron。
为了在企业用例中完全使用，Ironic 需要一种网络控制手段，而今天除非在完全集成的 OpenStack 环境中，否则是手动操作。此外，集成的 OpenStack 环境存在一些已知问题，这使得采用起来更加困难，因此我们计划在本开发周期内寻找解决这个难题的方案。
Ironic ARM CI¶
OpenStack Ironic 使用大量的 CI 测试来验证一切正常。
虽然我们支持 ARM，并且有现场报告显示它正在工作，但我们在 CI 中没有 ARM 表示，除了单元测试之外。
我们旨在像对 x86 虚拟机一样使用 ARM 虚拟机，并在 Ironic CI 中运行一个或多个 tempest 场景作业。
发布计划¶
贡献者在选择要处理的项目时，请记住我们的计划发布。
以下日期仅供参考；请查看 https://releases.openstack.org/dalmatian/schedule.html 以获取与发布相关的完整时间表，以及 https://docs.openstack.org/ironic/latest/contributor/releasing.html 以获取 Ironic 特定的发布信息。
Bugfix Release 1¶
第一个错误修复版本计划于 2024 年 6 月的第一周发布。
Bugfix release 2¶
第二个错误修复版本计划于 2024 年 8 月的第一周发布。
Deadline Week¶
在最后一周有多个截止日期/冻结
必须执行客户端库的最终发布
需求冻结
软字符串冻结 - Ironic 服务被最小化翻译；这通常不适用于我们的服务，例如 API 和 Conductor，但可能会通过其他正在翻译的项目影响我们。
功能冻结 - Ironic 通常没有功能冻结，但我们可能会受到其他具有功能冻结的项目的影响。
最终 2024.2 (集成) 发布¶
Ironic 项目的最终发布必须在 9 月 27 日之前完成。
