Xena 项目主题¶
“Alala” [1]
在 Wallaby 开发周期期间，我们有一个目标，即“历史偏爱勇敢者”。 在该开发周期的早期，很明显，贡献者面临的工作量实在太多，根本无法在周期内完成。 不幸的是，这种情况发生了，从整体上看，社区认识到它没有能力推动它前进，这是件好事。
这是一个艰难的教训。 但一个重要的教训。
这项工作的理念仍然成立。 历史确实偏爱勇敢者。 虽然我们不应该有战斗口号，更不要宣战。 我们应该在思考和执行方面具有策略性，以满足每个人的需求。 无论是操作员、贡献者，还是最终用户。
因此，似乎最好的方法是勇敢地前进！ 宣告我们的愿景，并传播我们成功的消息。 当然，需求会改变。 要求会改变。 但潜在的主题应该被铭记。
目的¶
每个部署者和开发人员都有不同的期望、愿望、需求和希望。 本文档的目的是阐明社区对发布哪些工作认为重要的共识。 在本文档中注明的项目将比新的或未优先的项目获得更多的审查和社区支持，但不能保证它们会在 Xena 周期内完成，或者根本无法完成。
这是 Ironic 团队在 Xena 开发周期内优先处理的目标列表，按相对大小排序，并结合我们的依赖关系，以及大致参考 Xena 开发周期的预期 sprint 和发布周期。
列出的主要联系人负责跟踪工作的状态并协调猫群以帮助完成工作。 他们不是这项工作的唯一贡献者，也不一定负责编写大部分代码！ 他们预计将在 IRC 和邮件列表中回答问题，并在 白板上报告每周 IRC 同步会议的状态。 主要联系人的数量通常限制为 2-3 人，以简化沟通。 我们期望其中至少有一人拥有核心权限，以简化更改的提交。
注意
为了保持我们的工作乐趣和享受，同时继续促进社区参与，本文档可能包含一些荒谬的内容。 没关系，我们还没有完全失去理智。
转向主题¶
Ironic 社区在 Xena PTG 期间达成共识，我们需要修改描述事物的词语。 具体来说，一个人的优先级不是另一个人的优先级，并且个人贡献者的优先级会根据其雇主当前的需要而迅速变化。
因此，我们似乎达成共识，这个词更像是 主题 而不是 优先级。 我们可以为发布或周期设置一个更高级别的总体主题，然后我们可以设置一些特定的较小的主题，这些主题可能进入发布，也可能不进入。 从外部来看，这可能似乎是一个巨大的变化，但它更符合现有的项目实践和我们所处的现实。
回到 目的，我们在这里记录的是我们的共识预测。 并且可能会发生变化。 共识可能会事后发生变化，但拥有一个双方都同意的起点至关重要，而本文档提供了这一点。
目标¶
优先级 |
主要联系人 |
目标 |
|---|---|---|
Ironic 开发人员，Baremetal SIG |
主题 |
|
zer0cool, rpittau |
Sprint 1 |
|
dtantsur |
Sprint 2 |
|
TheJulia |
Sprint 2 |
|
kaifeng, arne_wiebalck |
Sprint 2 |
|
janders |
Sprint 2 |
|
iurygregory, rpittau |
Sprint 2 |
|
iurygregory, dtantsur |
Sprint 2 |
|
TheJulia, TheJulia |
Sprint 3 |
|
TheJulia |
Sprint 3 |
|
kaifeng, TheJulia |
未来 |
|
kaifeng, ljmcgann, rpittau, sdanni |
未来 |
|
ljmcgann, sdanni |
未来 |
|
多位贡献者 |
未来 |
发布结构¶
此计划的指标是帮助审查本文档的人员了解功能合并和发布的大致时间。事情可能会提前或推迟合并。
Sprint 1¶
我们预计第一个 sprint 的发布将在 2021 年 5 月 31 日进行。 这比最初的规划周晚了六周。
Sprint 2¶
预计第二个 sprint 将于 2021 年 6 月 7 日开始，并持续到 2021 年 7 月 19 日。 第二个 sprint 大约持续 7 周。
Sprint 3¶
在第二个 sprint 发布之后，预计第三个 sprint 将于 9 月 6 日结束。 未“准备好审查”的功能和驱动程序增强功能将不会被视为阻止发布。 预计这将是一个为期七周的窗口。 从本质上讲，这可以看作是一个“冻结”，但更像是一个“列车必须准时出发”的模型。
预计发布日期为 9 月 9 日。
发布后 Sprint¶
在发布之后，似乎是一个很好的时机来确保我们已经处理了必要的任务和任何必要的反向移植，以及错误分类和解决任何“低垂的果实”错误，这些错误具有重大影响。 例如，文档无法渲染配置选项，或者在 Y 条件下部署失败。
这段时间也与社区在发布后的普遍转变相符，人们倾向于花一些时间来充电，然后再进行规划，以及规划步骤和讨论。
预计此 sprint 将于 2021 年 10 月 8 日结束。 在此窗口期间可能会进行额外的发布，以解决需要反向移植的错误修复。 下一周预计将是 项目团队会议 和下一个开发周期的开始。
主题¶
一般主题工作用于对某个领域进行一般改进，属于主题的范畴。这通常是在整个发布周期或更长时间内进行的小增量改进或相关工作。
未来¶
未来我们作为社区不确定何时会合并的项目。 包含在此列表中的内容表达了社区在此周期内推动这项工作的兴趣。
目标详情¶
不分先后…
勇敢地前进¶
与我们的总体主题 alala 一致，我们必须勇敢地承认我们是否有能力推动事情前进。 同时，我们需要广播出去。 我们需要谈论我们的成功。 我们的胜利……和失败。 以及介于两者之间的一切。
这种可见性，不幸的是，可能会让一些我们感到不舒服，但它有多种形式。 导师制、公开演讲以及超出日常主要任务范围的参与。 这也是我们成长的方式。 我们成长自己，以及社区。
所以要勇敢，思考 alala 并前进，跨越界限。 做那些让你感到不舒服的事情。 提出疯狂的想法。 并在允许的时候，登上当地会议的舞台，讲述这段经历。
因为历史偏爱勇敢者。
当然，我们也想保持理智，或者至少保持一部分理智。
数据库性能¶
在 Xena 开发周期期间，社区驱动的 Secure RBAC 工作增加了 API 中的额外数据库交互，这通常会增加数据库的负载，当 项目 范围的令牌请求项目时。 由于这是 OpenStack 中访问控制的新方向，我们需要确保我们不会给使用 API 访问活动的运营商带来负担。 由于某些配置模式可能会导致更多的活动，具体取决于最终运营商选择如何配置其部署。
在周期内，一位大型运营商遇到了雷群效应。 基本上，数据库无法跟上。 我们需要尝试聪明地防止这些情况发生，或者至少尽量减少影响，因为许多运营商现在也使用 Kubernetes 启动服务，这可能导致所有服务同时上线，这会加剧雷群效应。
应该注意的是，这并非全部是功能性工作，因为一些工作产品最终将被反向移植到 Wallaby 版本，这可能采用不同的方法。
这项工作也可能扩展到批量数据的 API，但这最终也需要更多信息，我们才能做出这样的决定。
完成安全的 RBAC¶
社区驱动的 Secure RBAC 工作，在社区范围内进行了多年，也进行了社区范围内的推动，要求项目实施和采用新的策略，同时弃用旧策略。
我们预计将在 Xena 周期内寻求删除旧策略，但是我们需要考虑 数据库性能 和运营商的需求。
Secure RBAC 也是一个相当新的配置，我们可能会发现跨服务错误或问题，这需要额外的工作。 这在某种程度上是可以预料的。
节点错误历史¶
为了勇敢地前进，我们必须提供有关节点错误历史的更多见解。 添加支持以记录重要事件并在人类可解析的方式中呈现它们的概念一直被讨论，并且一直是期望的功能。 现在是时候让它发生了。
这项工作是在 Wallaby 开发周期期间开始的，但我们没有能力在上一周期内推进它。 这个周期我们应该完成它。
完成 anaconda 部署¶
一些运营商投资于 Anaconda 配置，并使用 Anaconda kickstart 文件来促进部署。 更多信息可以在 anaconda 部署规范 中找到。
这项工作是在 Wallaby 开发周期期间开始的，并且持续进行。 它应该在第一个 sprint 的早期完成，因为在 Wallaby 开发周期中太晚才确定了一个依赖项，直到 Xena 才能解决。
快照¶
Nova Compute 与 VM 的交互中存在的一个主要兼容性差距是缺乏对 Ironic 裸机节点快照的支持。 这是一个有点复杂的问题，可能需要迭代开发过程。 目前正在讨论中，社区对该功能感兴趣。 关于此功能的更多信息可以在 快照规范文档 中找到。
迁移到 oslo.privsep¶
这项工作是从上一周期延续的，因为很明显，完成这些更改所需的时间比我们能够推进的时间要长。 更多信息可以在 迁移到 privsep 目标 文档中找到。
安全接口¶
最近对与 Keylime 集成的兴趣，促使人们重新提出 安全接口，该接口是之前提出的，旨在为 Ironic 提供一个集成点，以便理解和能够采取适当的措施，以应对机器被确定不再符合预期配置的情况。
Keylime¶
Keylime 项目 是一个开源系统安全和认证框架，最初由 麻省理工学院林肯实验室 开发，并在与 Ironic 社区密切合作后发展成为一个独立的开源项目。
Keylime 帮助确保部署的基础硬件未被篡改，并且最终系统正在运行预期的固件和软件。 它通过低级别的可信平台模块集成以及运营商可以选择部署的一组服务来实现这一点。
最终，支持集成有助于提高运营安全性，帮助运营商识别和隔离受到恶意操作的机器，并可能有助于提高部署过程的安全性，帮助识别恶意行为者是否尝试修改正在运行的 ramdisk 的内容。
这项工作需要实施 安全接口。
从 URL 启动¶
这是一个长期以来一直追求的功能，并且随着时间的推移可能会浮出水面。 部分难题在于可能的多种路线，以及对“从 URL 启动”的解释。 幸运的是，Redfish 已经定义了一个标准接口，可以通过 BMC 来断言配置。
至少在本周期内，我们希望在尝试支持此功能方面迈出一步，以便在供应商实施该功能，而无需使用供应商特定的 OEM 机制时，我们可以支持它。
关于此希望的基本信息可以在 HTTPClient 启动 中找到。 此外，在 ilo 硬件类型中也可以找到相关的先例，但希望能够以通用方式支持此功能，如果可能的话。
虚拟介质可见性¶
对于运营商和开发人员社区来说，虚拟介质的最大难题之一在于固件集成点。
此功能集涉及开源软件与通过 HTTP 连接的半专有或基于标准的 API 的复杂交互。 这种情况通常因固件开发团队通常位于组织内部完全独立的团队中而变得更加复杂，这些团队无法获得社区所拥有的洞察力。 最终结果有时会导致虚拟介质出现故障。
这个想法很简单。 识别机器是否已知良好，可以用于虚拟介质，并在适当的情况下以某种形式公开，以及历史上被视为部落知识的解决方法或潜在修复方案。 这可能会引起一些争议，因为认知很重要，但可用性也很重要，我们需要在不断演变的痛点之间找到某种平衡。
驱动程序结构和模型¶
我们的驱动程序模型具有以下优势：运营商可以非常具体，并最终对节点的行为具有一定程度的了解或信任。 然而，这种力量也伴随着混淆的来源，以及一些与某些重叠代码相关的痛点，可能会导致意外后果。
我们认识到需要尝试就一处或多处改进达成共识，以帮助缓解这些问题，并可能提供前进的道路，同时仍然提供一定程度的灵活性。
在本周期内，这主要预计只是一份规范文档，可能仅用于确定未来策略的共识。 这也可能会推动未来的代码增强，但我们只有在就此主题达成共识后才能知道。
这与 story 2008804 和 story 2005328 相关，它们提出了一些相关的想法。
增强存储清理¶
存储是裸机环境中的一个复杂问题。 从本质上讲，存在两种不同的思想流派来支持运营商。 第一种是，我们希望绝对确保机器上的任何地方都没有残留任何内容。 一些运营商需要这种级别的清洁度。 而另一些运营商只需要知道他们可以在不产生不良影响的情况下安全地重新部署到机器上即可。
此外，随着时间的推移，我们的立场和看法也在变化，因此我们希望元数据擦除更像是一种帮助，为“只想能够安全地重用我的机器”的运营商群体提供更大的保证。
这可能会导致对处理安全擦除/格式化操作的方式进行一些更改，以及删除磁盘上更多数据部分以帮助重用。 特别是对于使用 Ceph 的运营商。
iSCSI 部署移除¶
Ironic 中的第一个部署方法，也是最需要“我们只需要信任”底层机制并希望一切顺利的驱动程序之一。 事实证明，这些底层机制无法处理间歇性瞬态故障或端口状态在飞行中重置等问题。 由于此原因，部署很容易中断或中断，这在具有不同网络配置的各种基础设施中并不理想。 这些因素导致社区达成共识，认为现在是时候弃用此部署机制，并最终将其从 Ironic 中删除。
我们预计它将在 Xena 开发周期的最终版本之前消失，部分原因是它极难进行故障排除，并且依赖于导体 block-io 接口，这会产生天然的性能瓶颈，从而限制了部署的可扩展性。
