Rocky 项目优先级¶
这是 Ironic 团队在 Rocky 开发周期内优先处理的开发优先级列表，按优先级排序。请注意，这不是我们本周期的完整待办事项列表，我们仍然希望审查和合并非优先事项。
列出的主要联系人负责跟踪工作状态并协调工作以帮助完成工作。他们不是这项工作的唯一贡献者，也不一定负责大部分编码！他们预计会通过 IRC 和邮件列表回答问题，并在 白板 上报告状态，以便进行每周 IRC 同步会议。主要联系人的数量通常限制为 2-3 人，以简化沟通。我们期望其中至少一人拥有核心权限，以便简化更改的提交。
优先级¶
优先级 |
主要联系人 |
|---|---|
rloo, mgoddard |
|
zshi, yolanda, moddard, hshiina |
|
jroll |
|
dtantsur, jroll |
|
mkrai, anup-d-navare, TheJulia |
|
vdrok |
目标¶
目标 |
主要联系人 |
|---|---|
TheJulia |
|
TheJulia, dtantsur |
|
etingof, dtantsur |
|
rloo, TheJulia |
|
jroll, TheJulia |
|
rloo |
Stretch Goals¶
注意
在完成 Storyboard 迁移 后，此处记录的 Stretch Goals 将被迁移到 Storyboard 并进行跟踪。
Stretch Goals |
主要联系人 |
|---|---|
dtantsur |
|
etingof, deray, stendulker |
|
sambetts, pas-ha |
详情¶
部署步骤¶
我们创建了具有组合有序操作列表功能的清理功能。但是，我们将部署保留为静态的操作集。
为了允许模板使用所选特性应用，我们希望对节点的部署应用与清理获得相同的功能和框架。
这将从将部署过程中写入镜像的操作与写入配置驱动器的操作拆分为两个不同的步骤开始。之后，我们将进一步迭代。
这最终可能有助于实现从 Queens 开发周期开始未完成的部署逻辑去重目标。
BIOS 配置框架¶
一些驱动程序支持设置 BIOS（UEFI 等）带外配置。我们希望引入一个框架（HTTP 和驱动程序 API），以便驱动程序将此功能暴露给用户。
Conductor 位置感知¶
运营商经常更改驱动程序名称，以便将 Conductor 映射到单个节点，以便 Conductor 位于节点本地，并且位于洛杉矶的 Conductor 不会尝试控制欧洲的机器。
这允许 ironic 保持一个统一的控制面板，并为 ironic 的部署提供更大的灵活性。目前，我们将专注于硬亲和性，并提供升级路径。
参考架构指南¶
为了帮助新的部署者做出正确的选择，我们需要一份描述 ironic 部署参考架构的文档，尤其是在多租户网络和与虚拟机共存方面。
图形化控制台¶
我们需要一种方法来从支持它的驱动程序向用户暴露图形化（例如 VNC）控制台。规范和补丁处于各种状态，需要重新拾取。我们希望在本周期内拥有支持图形化控制台使用的初始框架。
Neutron 事件处理¶
目前 ironic 没有办法确定某些异步事件在 neutron 中实际完成的时间以及结果。Nova 另一方面，使用一个特殊的 neutron 驱动程序，过滤掉通知并将其中一些发布到特殊的 nova API 端点。我们应该这样做。
更新 nova virt 以使用 REST API¶
周期性地，我们遇到升级序列和我们在支持 ironic 的 Nova virt 驱动程序中递增的 API 版本钉的问题。
是时候结束这一切，并更好地支持与我们 API 的版本化交互。在与 Nova 社区讨论后，我们达成共识，是时候将我们的 API 调用转换为直接的 REST 调用，而不是通过 python-ironicclient 库进行调用。
Storyboard 迁移¶
Ironic 多年来以多种不同的方式规划工作，我们已经了解到每种方法都有其优点。
随着我们的团队规模也越来越小，我们还必须通过集成不同的工具、系统和流程来提高关注度。
通过 Storyboard，我们将获得在一个系统中规划和跟踪工作的优势。
管理界面重构¶
随着时间的推移，我们发现需要一个地方来控制节点的启动模式。这项工作正在重构管理界面，以便我们将不同的启动模式相关操作移动到一个统一的界面中。
获取干净的步骤¶
人们对我们的清理模型最大的挫败感之一是缺乏对他们可以做什么的可见性。我们对此有一些想法，我们需要开始提供提高这种可见性的机制。
项目愿景¶
我们都有不同的想法，希望在两年、五年和十年后看到 ironic 的样子。作为团队的讨论帮助我们确定和构建了讨论范围，以便我们保持一致。
我们应该写下我们对未来的共同愿景，看看它将我们带向何方。
SIGHUP 支持¶
SIGHUP 是指示程序尝试重新加载配置并可能自行重启的信号机制。支持 SIGHUP 是 OpenStack 项目范围内的目标，对我们来说应该很容易。让我们做吧！
经典驱动程序移除¶
我们已经弃用了经典驱动程序，并且很快就到了移除这些驱动程序的时候，因为我们已经提供了一种将用户迁移到硬件类型的方法。弃用日期为 2018 年 2 月 1 日，因此可以在 2018 年 5 月 1 日之后删除此代码。
Redfish OOB 检查¶
Redfish 是我们树内“参考”硬件类型之一，但我们不支持带外检查。为了提供功能奇偶校验，我们应该继续推进，因为越来越多的供应商正在转向 Redfish。
Zuul v3 playbook 重构¶
Zuul v3 的强大功能之一是，我们执行 ansible playbook 而不是传统的 shell 脚本。迁移留下了大量的遗留 shell 脚本在测试过程中。
目前正在努力从我们的正常 devstack 作业中删除大部分启动脚本。我们预计我们的 grenade 作业将保持不变。
