Victoria 项目优先级¶
这是 Ironic 团队在 Victoria 开发周期内优先处理的目标列表，按相对大小和依赖关系解决的顺序排列。
请注意，这不是我们本周期的完整待办事项列表，我们仍然希望审查和合并非优先事项。
列出的主要联系人负责跟踪工作状态并协调工作以帮助完成工作。他们不是这项工作的唯一贡献者，也不一定负责大部分编码！预计他们将在 IRC 和邮件列表中回答问题，并在 白板 上报告每周 IRC 同步会议的状态。主要联系人的数量通常限制为 2-3 人，以简化沟通。我们期望其中至少一人拥有核心权限，以简化更改的提交。
目标¶
优先级 |
主要联系人 |
目标 |
|---|---|---|
Ironic 开发人员 |
Sprint 1 |
|
iurygregory |
Sprint 1 |
|
stevebaker |
Sprint 1 |
|
TheJulia |
Sprint 1 |
|
TheJulia |
Sprint 1 |
|
stevebaker |
Sprint 2 |
|
dtantsur |
Sprint 2 |
|
Ironic 开发人员 |
Sprint 2 |
|
iurygregory |
Sprint 2 |
|
iurygregory |
Sprint 2 |
|
dtantsur, mgoddard |
Sprint 3 |
|
arne_wiebalck, rpioso, rpittau |
Sprint 3 |
|
TheJulia, arne_wiebalck |
主题 |
计划结构¶
此计划的指标是帮助审查本文档的人员了解功能合并和发布的大致时间。事情可能会提前或推迟合并。
Sprint 1¶
目标在 2020 年 6 月 29 日左右发布。
Sprint 2¶
在 Sprint 1 发布后开始。
预计在 2020 年 8 月 10 日左右发布。大约在 Sprint 1 之后两个月。
Sprint 3¶
在 Sprint 2 发布后开始，预计持续两个月。预计在 2020 年 9 月 28 日左右。重要的是要注意 OpenStack 周期最终发布候选版本的截止日期。Ironic 的“最新”版本将在此时被 OpenStack 消耗用于 Victoria 版本。
主题¶
一般主题工作用于对某个领域进行一般改进，属于主题的范畴。这通常是在整个发布周期或更长时间内进行的小增量改进或相关工作。
目标详情¶
不分先后…
打破周期¶
Ironic 是一个被其他项目消耗并最终通过这些渠道进入多个产品的项目。在许多方面，它是运营商的瑞士军刀。同时，它也成为像 TripleO Metal3 这样的项目的半隐藏实现细节，甚至在某种程度上，对于 OpenStack Compute API 的用户来说，它可能是一个隐藏的细节。
有了这种用途，并最终为了支持他们的用例，我们需要在尽早和频繁发布方面做得更好。
有时没有理由对 Ironic 或其任何组件进行全新发布，除非我们需要采取行动来修复它或添加了新功能。这主要是因为我们依赖于稳定的 API 和接口，至少在大多数情况下是这样。
虽然我们都希望看到所有功能，但我们应该采用符合 Sem-Ver 的模式进行交付，而不是为了匹配周期边界而强制进行人为的主版本更改，从而创建一个分支点。
话虽如此，现在是时候采用 独立发布模型 了。
这有缺点，并且需要不同的规划方法。然而，并非 Ironic 的所有资产都应该以这种方式发布。有些项目落入我们的项目治理范围，具有相互依赖性，最终需要继续使用 OpenStack 发布周期模型。这是否会使这些项目在 Ironic 中变得不那么重要？绝对不是！但它们是特定的集成点，我们始终需要注意维护这些集成点。
使 CI 可管理¶
CI 是一个永无止境的痛点。这是任何软件开发过程中的 CI 系统的存在真理。然而，我们面临的困境是，我们拥有驱动程序爆炸式增长、我们关心的特定用例，以及最终我们不想破坏任何人。自然的结果是我们拥有大量的 CI 作业。
有了大量的不同作业，人们可能会认为它很容易维护。
在某种程度上，他们是对的。但丢失的是我们的测试模型强制 重试 重新运行所有作业。在那种情况下，这实际上是一件好事，但任何单个瞬态故障都可能强制重新执行所有测试，再次。一次又一次。有时，甚至再次。
最终，为了使 CI 可管理，我们需要改进我们的并发性，并大大减少我们的总体作业数量。我们通过尝试使用相同的作业来测试多个场景来做到这一点。如果无法做到，我们可能有一个应该探索修复的缺陷。如果我们能做任何事情来改善作业执行时间，最终我们将改善我们自己以及所有人的结果时间。
迁移到所有原生 Zuulv3 作业¶
Victoria 周期的 OpenStack 社区目标是确保所有作业都是 Zuulv3 原生的。您可以在 此处 了解这项工作。
迁移到 oslo.privsep¶
提出的但未被 OpenStack TC 选择的更改之一是采用 Oslo.Privsep。我们认为这是一个好主意，并将继续进行这项 工作。
兼容性矩阵¶
Ironic 文档的一个弱点是缺乏清晰度，即在比较驱动程序时，驱动程序内部功能的兼容性。主要是因为我们希望鼓励但不强制驱动程序维护者对他们的驱动程序代码进行特定的改进。
因此，我们希望通过清晰度来修复文档中的这个弱点。总体用户体验应该得到改善，而这最终是我们所有人都追求的。
带内部署步骤¶
虽然这是一个在我们的过去几个周期中一直存在的主题，但我们继续致力于改进部署步骤的功能，并且在这种情况下，重点是带内使用。
裸机程序/SIG¶
Ironic 社区本周期内可以做的最有力的工作实际上不在代码中，而在于文档。最近创建的 Bare Metal SIG 正在作为 Bare Metal 标志计划 的一部分创建白皮书，并且需要我们帮助提供独立用例。
Ramdisk TLS¶
ironic-conductor 到 ironic-python-agent 安全性中的一个结构性弱点是，默认情况下，它未加密。
很大程度上是因为这是一个难以保护的表面。它是短暂的、临时的，并且通常是短期的。签署证书的机制也更难以实施。TLS 客户端是否检查证书的“common name”或“alias”字段。这对于这种用法是否重要。我们如何处理虚拟媒体与使用提供的 ramdisk 进行 PXE 启动。
这些是我们必须回答的所有问题和疑虑，最终目标是确保代理可以自动提供 TLS 加密的 Restful API 端点，供 ironic-conductor 连接。
替换 WSME¶
大多数长期贡献者都知道 WSME 给社区带来的头痛，以及许多项目已经迁移离开它这一事实。
为了将我们迁移到受更广泛社区支持的东西，Train 项目团队会议的共识是让 Ironic 朝着使用 Flask 的方向发展。我们将从重做单个端点开始，并希望以快速的方式完成其余 API。
独立的基本身份验证¶
为了使独立用例蓬勃发展，我们必须支持另一种身份验证机制。最简单的方法就是简单的 HTTP 基本身份验证。
也许我们不会就此止步，但“noauth”对于边缘基础设施管理来说是不可接受的。
无 DHCP 部署¶
边缘机器的部署需要我们无法控制 DHCP 的情况。但也有可能根本没有 DHCP 服务器，在这种情况下，我们必须在附加到正在部署的物理机器的虚拟媒体中提供网络配置。
这项工作延续自 Ussuri 开发周期，如果幸运的话，将在 Victoria 开发周期的早期合并。
ISO 启动介质直通¶
一个最近的想法是更好地支持 ramdisk 用例，供希望通过预先掌握的 ISO 触发机器启动操作的运营商使用，就像现有的 ramdisk 接口一样，但是，在这种情况下，他们拥有他们需要的一切。
有关此信息的更多信息可以在 规范 文档中找到。
Redfish 互操作性规范¶
Redfish 论坛有一个 互操作性规范 机制，允许反馈过程传达哪些内容受支持，哪些内容不受支持。
硬件供应商/制造商可以使用这种规范来评估/宣传 Ironic 可以与他们的硬件交互的程度。同样，此类硬件的消费者/客户可以使用该规范来确保他们打算购买的硬件与 Ironic 协同工作，甚至将其作为他们的招标/采购过程的一部分。
