Stein 项目优先级¶
这是 Ironic 团队在 Stein 开发周期中优先处理的开发优先级列表，按相对大小和依赖关系解决顺序排列。请注意，这不是我们本周期的完整积压，我们仍然希望审查和合并非优先事项。
列出的主要联系人负责跟踪工作状态并协调工作以帮助完成工作。他们不是这项工作的唯一贡献者，也不一定负责大部分编码！预计他们将在 IRC 和邮件列表中回答问题，并在 白板 上报告每周 IRC 同步会议的状态。主要联系人的数量通常限制为 2-3 人，以简化沟通。我们期望其中至少一人拥有核心权限，以简化更改的提交。
由于 Stein 周期剩余时间约为项目团队会议后的 30 周，因此优先级列表已根据相对大小的估计分为两个主要部分。总体目标是在周期的前几个月专注于 较小目标，而较大的 史诗级目标可能会在周期早期进行一些工作，但将在后期进行重点处理。
较小目标¶
优先级 |
主要联系人 |
|---|---|
TheJulia, rloo |
|
derek, TheJulia |
|
TheJulia, stendulker |
|
hshiina |
|
TheJulia |
|
jroll, TheJulia |
|
jroll, kaifeng |
|
shekar, stendulker |
史诗级目标¶
目标 |
主要联系人 |
|---|---|
mgoddard, dtantsur, rloo |
|
mkrai, etingof |
|
TheJulia, dtantsur |
|
etingof, TheJulia, mgoddard |
|
jroll, rloo |
|
TheJulia, dtantsur |
|
jroll, dtantsur |
|
vdrok, mgoddard, hjensas |
跨项目目标¶
TheJulia, jroll |
|
TheJulia, mkrai, moshele |
详情¶
升级检查器¶
这是 Stein 周期 OpenStack 社区的目标。对于 ironic，这意味着一个新的命令，名为 ironic-status upgrade check。此命令旨在为升级致命的事情（例如缺少新的必需配置或尚未执行的模式/数据升级）返回错误。该故事可以在 故事 2003657 中找到。
Python3 优先¶
这是 Stein 周期 OpenStack 社区的目标。大部分工作已经在 ironic 中完成。我们主要需要更改我们的测试，以便明确地在 Python3 上进行测试。目前我们无法对每个测试都这样做，但我们应该能够更改大部分测试，并确保大部分代码路径都通过标记为 python2 的测试覆盖。
我们还希望第三方 CI 开始利用 Python3，目标是大约 50% 的第三方 CI 作业，直到我们停止支持 Python2。该故事可以在 故事 2003230 中找到。
iPXE/PXE 接口拆分¶
这是一项较早的努力，已重新启动，目的是支持在同一部署中多种架构（例如 AArch64、Power 和 x86_64）。
事实证明，Power 的架构期望我们的 PXE 启动接口编写的较旧的 PXELinux 风格模板。此外，虽然 AArch64 可以使用 iPXE 启动，但没有可用的预构建二进制文件。
因此，我们需要不再使这对于 conductor 来说是全局的，而是特定于节点，并将接口拆分开来开始更有意义。原始规范可以在 ipxe-boot 接口 中找到。该故事可以在 故事 1628069 中找到。
UEFI 优先¶
2020 年对于裸机运营商来说是一个重要的年份，因为预计较新的处理器发货时将删除对传统启动模式的支持。
为了确保我们的成功，我们需要改进我们的测试并为 UEFI 是唯一可用的启动模式的未来做好准备。因此，这将成为一个多周期重点，以便在未来的周期中将默认启动模式更改为 uefi。该故事可以在 故事 2003936 中找到。
HTTPClient 启动¶
虽然社区对支持基于 HTTPClient 的启动感兴趣，但我们目前需要先克服几个步骤。即 iPXE/PXE 接口拆分和改进的 UEFI 测试。
这项工作的性质是启用显式的 HTTP 启动场景，其中启动节点不利用 PXE。该故事可以在 故事 2003934 中找到。
Nova conductor_group 感知¶
这项工作完全在 openstack/nova 仓库中的 ironic virt 驱动程序中。这将使我们能够定义一个 conductor_group，nova-compute 进程利用该组来查看它负责的裸机节点。该故事可以在 故事 2003942 中找到。
增强校验和支持¶
Ironic 目前默认使用 MD5 校验和进行 image_checksum，这远非理想。在 Rocky 周期中，Glance 增强了其对校验和存储的支持，这意味着我们也应该增强我们的支持。该故事可以在 故事 2003938 中找到。
无 DHCP/L3 虚拟介质启动¶
一些运营商和供应商希望启用 ironic 以管理在部署过程中不使用或利用 DHCP 的部署。为了做到这一点，我们需要在部署 ramdisk 中附加一些其他功能。规范可以在 基于 L3 的部署规范 中找到。该故事可以在 故事 1749193 中找到。
部署模板¶
在未来，我们希望根据从 Nova 提交到 ironic 的特性采取具体行动，描述实例的预期状态或行为。
这将使我们能够采取行动并影响部署步骤，因此是 Rocky 周期中 Deploy Steps 工作的一个延续。该故事可以在 故事 1722275 中找到。
图形控制台¶
我们需要一种方法来从支持它的驱动程序向用户公开图形（例如 VNC）控制台。我们在 Rocky 周期中就规范达成了一致，并开始处理补丁以启用此功能。我们的目标是拥有一个框架，并最好至少有一个供应商驱动程序来支持图形控制台连接。规范可以在 vnc 图形控制台规范 中找到。该故事可以在 故事 1567629 中找到。
联邦能力¶
边缘计算正在带来各种支持 ironic 部署联邦的用例，这些用例可能非常强大。
为了更好地支持这个新兴用例，我们希望尝试达成一个可行的前进道路，以满足几个不同的用例和要求。这项工作的目标是达成一致的规范。该故事可以在 故事 2001821 中找到。
任务执行改进¶
我们意识到我们的任务执行和锁定模型存在问题，虽然它在某些方面可以扩展，但在其他方面却不能扩展。这项工作将包括 worker 执行改进、对不同 worker 线程执行模型的评估和可能的实施，以及对锁定的仔细改进。该故事可以在 故事 2003943 中找到。
无 IPA 到 conductor 通信¶
大型运营商需要对其部署进行更严格的安全控制，他们希望防止所有传出网络连接到控制平面。目前，设计模型要求节点能够访问 ironic 的 API 以执行心跳和查找操作。
这个概念是可选地启用 conductor 通过轮询 IPA 使用已知 IP 地址来驱动部署。也就是说，这实际上需要 任务执行改进 完成，以帮助确保运营商能够拥有性能良好的部署。规范可以在 更改 212206 中找到。该故事可以在 故事 1526486 中找到。
获取步骤¶
人们对我们的清理模型最大的挫败感之一是缺乏对他们可以执行的步骤的可见性。这进一步加剧了 deploy steps 的问题。我们对此有想法，我们需要开始提供提高可见性的机制。
这可能还涉及状态机状态，以使代理能够处于等待操作者操作的保持状态。
目标最终是为用户提供一个 CLI，以便他们能够了解可用的步骤。该故事可以在 故事 1715419 中找到。
Neutron 事件处理¶
目前 ironic 无法确定 neutron 中某些异步事件何时完成以及结果如何。Nova 相反，使用特殊的 neutron 驱动程序，该驱动程序过滤掉通知并将其中一些发布到特殊的 nova API 端点。我们应该这样做。该故事可以在 故事 1304673 中找到。
Conductor 角色拆分¶
Conductor 目前完成所有工作……但它需要这样做吗？
这是我们应该问自己的问题，当我们发展时，如果我们可以选择性地将 conductor 拆分为许多部分，以启用边缘 conductor 或边缘本地引导管理，该怎么办。这里的目标是获得一个不同的操作矩阵，希望随着时间的推移进一步指导我们。该故事可以在 故事 2003940 中找到。
Smartnic 支持¶
Smartnic 使 ironic 复杂化，因为需要以一种能够更改 NIC 上的配置的状态来编程 NIC 的电源。
虽然这项工作最终可能会导致 neutron 形式的 Super-Agents 进行配置增强，但我们仍然需要了解对我们工作流程的影响，并确保仍然存在足够的安全性。主要目标是在柏林峰会之前制定联合规范，以与 Neutron 团队达成共识，确定机制、信息传递和设置存储。该故事可以在 故事 2003346 中找到。
部署状态回调到 nova¶
Ironic 的 nova 虚拟驱动程序的一个问题是缺乏回调机制。 因此，该虚拟驱动程序会重复轮询 ironic API 端点，这会增加整个系统的负载。 在理想情况下，ironic 应该利用一种机制来指示部署状态，类似于 neutron 通知 nova 网络已配置完成的方式。 相关故事可以在 故事 2003939 中找到。
