Pike 项目优先级¶
这是 Ironic 团队在 Pike 开发期间优先处理的开发优先级列表，按优先级顺序排列。列出的主要联系人负责跟踪工作状态并协调工作以完成该工作。他们不是这项工作的唯一贡献者！主要联系人的数量限制为最多 2 人，以简化沟通。我们期望其中至少有一人拥有核心权限，以简化更改的提交。
核心优先级¶
优先级 |
主要联系人 |
|---|---|
vsaienk0 |
|
TheJulia, dtantsur |
|
rloo, jlvillal |
|
jroll, dtantsur |
|
Python 3.5 兼容性 |
Nisha |
使用 Apache 和 WSGI 进行 CI 部署 |
vsaienk0 |
jroll, dtantsur |
|
rloo, dtantsur |
|
dtantsur |
|
完成节点标签 |
zhenguo, dtantsur |
高优先级¶
优先级 |
主要联系人 |
|---|---|
stendulker, aparnav |
|
sambetts, vsaienk0 |
|
sambetts, vsaienk0 |
|
sambetts, vsaienk0 |
|
vdrok, vsaienk0 |
|
sambetts |
可选优先级¶
优先级 |
主要联系人 |
|---|---|
soliosg, jlvillal |
|
yolanda, rloo |
|
Redfish 驱动程序 |
lucasagomes, jroll |
dtantsur |
|
rloo |
|
galyna, vdrok |
详情¶
独立的 CI 测试¶
我们正在开发一套可以在没有 nova 的情况下运行的测试。我们预计这项工作将提高 CI 时间、覆盖率并帮助测试某些功能（例如采用），这些功能与 nova 不完全兼容。
通用的从卷启动¶
这项工作允许通用硬件从远程存储启动，从而使无盘节点可以由 ironic 管理。它还为硬件特定的实现奠定了基础。
滚动升级¶
许多 OpenStack 项目开始支持滚动升级 - 我们也应该这样做。让我们尽一份努力，让停机成为过去式。这涉及代码更改、新的多节点 grenade CI 作业以及审查者/开发人员文档。现在的目标是 Ocata -> Pike 滚动升级。
参考架构指南¶
为了帮助新的部署者做出正确的选择，我们需要一份描述 ironic 部署参考架构的文档，尤其是在多租户网络和与虚拟机共存方面。
驱动程序组合¶
我们已经完成了大部分编码。让我们集中精力稳定该功能，编写新的硬件类型，完善文档并帮助供应商进行集成。
两个 CLI 之间的功能对等性¶
让我们确保在旧的 ironic CLI 中实现的所有功能都可以在新的基于 OSC 的 openstack baremetal CLI 中使用。
OSC 默认 API 版本更改¶
目前 OSC 发送到 ironic 的默认 API 版本是一个旧的 Kilo 时代的版本。我们需要找到将最新版本设为默认版本的路径。
救援模式¶
这对于定期无法访问其机器的用户（例如，丢失密码）是必要的。该规范在 Newton 中被合并，代码部分完成，让我们在 Pike 中投入精力来取得进展。
部署后 VIF 附加/分离¶
我们已经支持在部署过程中将 VIF 附加和分离到节点。现在我们需要支持对活动节点执行相同的操作。
物理网络感知¶
我们需要确保实例不会被调度到无法物理访问其连接的网络上的节点。这可能需要围绕端口的数据模型更改。这是 路由网络支持 的要求。
路由网络支持¶
Ironic 应该了解连接网络可用的 L2 段，以及哪些 L2 网络实际上可供节点使用，以便在进行配置/清理时正确选择子网（IP 地址）。
Neutron 事件处理¶
目前 ironic 没有办法确定某些异步事件在 neutron 中实际完成的时间以及结果。Nova 另一方面，使用一个特殊的 neutron 驱动程序，过滤掉通知并将其中一些发布到特殊的 nova API 端点。我们应该这样做。
IPA REST API 版本控制¶
IPA API 当前未进行版本控制，这会在 ironic 开始依赖新功能时导致问题。类似于 ironic API 的版本控制预计可以解决此问题并简化升级。
拆分 tempest 插件¶
目前，我们依赖某些技巧来使我们的 CI 在所有分支上使用 tempest 插件的主版本。QA 团队建议将我们的 tempest 插件移动到单独的分支，让我们这样做。我们还应该合并 ironic 和 ironic-inspector 插件，以便更轻松地维护和使用。
部署步骤¶
这是一项努力，旨在将我们单片部署过程的某些部分拆分为步骤，类似于清理。这将为驱动程序作者提供更多自定义部署过程的自由度，并简化潜在的添加（例如 RAID）。
支持的电源状态 API¶
软电源/NMI 规范 建议在 API 中公开可用的电源状态。我们没有在 Ocata 中实现这部分内容，让我们现在完成它。
可用的清理步骤 API¶
我们需要在 API 中公开可用的清理步骤，以便用户知道在手动清理期间可以运行哪些操作。这是 手动清理规范 的一部分，尽管该规范已被标记为完成，但从未实现。
