Ironic 新发行模型¶
本规范描述了在 ironic 伞形下发布交付物的新的模型，包括 Bare Metal 服务本身。
问题描述¶
目前 ironic 遵循 OpenStack 发行模型 周期性带中间版本，这允许我们在每个 OpenStack 周期产生一个或多个发行版，其中周期中的最后一个版本用作 OpenStack 集成发行版（在本文档中称为命名发行版，因为它会收到代码名称）的一部分。会从这个最终发行版创建一个稳定分支，用于长期 bug 修复支持。
随着 ironic 社区探索越来越多的独立应用程序，包括那些在 OpenStack 之外的应用程序（例如 Metal3），一个问题变得明显：独立使用不仅需要频繁的功能发布，而且需要支持的频繁功能发布。确切地说，我们希望每 1-3 个月（本规范建议 2 个月）发布一次支持的发行版，其中支持包括
通过点版本解决至少关键问题。目前，我们要求用户切换到下一个发行版，即使它是主要版本。
支持发行版之间的升级路径。目前仅测试和支持 OpenStack 命名发行版之间的升级，我们需要支持中间版本之间的升级。
每个发行版的文档。目前仅发布命名发行版（和 master）的文档。
一种明显的消费这些发行版的方式。目前部署工具，包括甚至 Bifrost，都面向命名发行版或 git master。
提议的模型旨在实现这些要求，同时保持围绕集成发行版的现有承诺。
提议的变更¶
术语¶
本文档中使用了以下概念
- 命名发行版
是接收代码名称和命名稳定分支的集成 OpenStack 发行版。
- 中间发行版
是作为 master 开发的一部分（故意排除稳定发行版）发生的 ironic 交付版的发行版，它不对应于命名发行版。
注意
此定义与 OpenStack 官方的中间发行版定义不同。这样做是为了使本文档的措辞更清晰。
- 稳定分支
从命名发行版创建的分支，其中应用 bug 修复并定期发布为稳定发行版。
- 稳定发行版
是在命名发行版的稳定支持下创建的发行版。
- bugfix 分支
从没有导致稳定分支的中间发行版创建的分支。
发布¶
所有交付物的发行版都以松散的双月为基础进行评估，即大约每 2 个月。如果有重要的有价值的更改，并且有明确的用户对发布感兴趣，我们应该这样做。在大多数情况下，这意味着 Ironic 的下游分发者将消费该发行版。
这每年最多有 6 个发行版，每个 OpenStack 周期 3 个。
每年两个发行版对应于 OpenStack 命名发行版，其他发行版发生在命名发行版之间。前两个总是发生，后四个可以跳过，如果对于该发行版或交付物没有已知的消费者，或者交付物在 2 个月内没有看到显著的变化。
在每次发布前观察一周的软功能冻结。软意味着如果认为功能风险较低或对即将发布的范围至关重要，则功能仍然可以合并。
这为大多数功能留下了大约 7-9 周的合并窗口。应该在先前发行的功能冻结期间制定计划。
Ironic 交付物遵循 SemVer，并有一个澄清：补丁发行版始终从稳定或 bugfix 分支发布（参见 稳定分支和升级）。来自 master 的发行版总是会收到次要或主要版本更新。
注意
需要此限制才能找到分支发行版的合适版本。例如，假设我们从 master 切割 21.2.0，然后从 master 切割 21.2.1。如果然后我们需要从
stable/21.2（21.2.0 的支持分支）制作一个发行版，则没有可用的 SemVer 版本（21.2.0.1 仍然是一个选项，但可能会与 pbr 冲突）。中间（非命名）发行版将面向独立用户。建议 OpenStack 部署者使用命名发行版。
稳定分支和升级¶
服务项目和 bifrost¶
将对服务项目（ironic 和 ironic-inspector）、ironic-python-agent 和 bifrost 应用以下过程
从每个发行版创建稳定分支
一个传统的
stable/<code name>分支用于与命名发行版重合的发行版。一个
bugfix/<major.minor>分支用于其他发行版。
命名差异突出了意图的差异
稳定分支旨在由下游（如 RDO）长期消费，并供用户跟踪它们。
Bugfix分支是一种技术措施，可以在某个发行版之后允许补丁发行版。不期望用户和下游长期跟踪它们，建议在可用时尽快更新到下一个功能发行版。
在 CI 中为每个提交支持并测试三个升级路径
两个连续的命名发行版之间（例如，Train 到 Ussuri）。
两个连续的中间发行版之间。
注意
我们可能无法使用 Grenade 来实现这一点。我们可能会使用 Bifrost 代替。
从命名发行版到下一个发布周期中的任何中间发行版。
注意
支持此路径在技术上是实现其他两个路径的 CI 所必需的）。
注意
在非命名分支上运行 CI 可能会需要固定 devstack、tempest 和 ironic-tempest-plugin 版本以避免中断。将在具体情况下确定。
其他项目¶
库项目（metalsmith、sushy、python-ironicclient 和 python-ironic-inspector-client）和网络插件（networking-baremetal 和 networking-generic-switch）将像以前一样发布和分支
将根据有多少有用的更改而按需创建发行版。
仅创建命名稳定分支，中间发行版不会导致分支。
此过程与 Python 世界中通常发布库的方式相匹配。
CI 工具（virtualbmc 和 sushy-tools）和 ironic-tempest-plugin 将不会被分支。
支持阶段¶
命名稳定分支根据 OpenStack 策略得到支持，目前为 1.5 年的完全支持，然后是扩展维护。
由于此提案显著增加了支持中的分支数量，我们将收紧对命名分支的反向移植规则
前 12 个月，任何 bug 修复都可以接受。如果认为低风险功能可以实质性地改善操作员或用户体验，则可能接受它们。
最后 6 个月和在扩展维护期间，仅接受高危和关键 bug 修复。
如果在扩展维护期间没有更改合并到分支，则该分支被认为已放弃，并且不再接受进一步的反向移植。
注意
这也适用于当更改被提出但由于 CI 失败而无法合并时。
具有 bugfix 分支（对于具有分支的交付物）在 6 个月内得到支持。在整个支持时间内，仅接受高危和关键 bug 修复。
注意
这意味着较早创建的稳定分支可能会收到比后来创建的 bugfix 分支更多的修复。这反映了消费者不期望跟踪 bugfix 分支的事实。
与以前一样，高危和关键 bug 修复应该在合并到 master 后反向移植到所有受支持的分支。
依赖项¶
命名发行版和分支的依赖项处理没有改变。例如，我们继续消费相应分支的上限约束。
对于中间发行版，我们将消费来自未来命名分支的上限约束。例如，对于 Victoria，我们将消费 https://releases.openstack.org/constraints/upper/victoria。
命名和中间发行版的服务间依赖项必须分别通过微版本化或文档来表达。我们已经提供了与我们可以集成的项目的广泛版本支持。
弃用策略¶
弃用策略保持不变：任何弃用的功能只能在 6 个月后且完成命名发行版后才能删除。
备选方案¶
保持当前模型，要求中间发行版消费者始终升级到最新版本。
数据模型影响¶
无
状态机影响¶
无
REST API 影响¶
无
微版本化已被用作确保跨发行版 API 兼容性的一种方式。
客户端 (CLI) 影响¶
无
“openstack baremetal” CLI¶
无
“openstacksdk”¶
无
RPC API 影响¶
无
驱动程序 API 影响¶
无
Nova 驱动程序影响¶
无
我们期望作为某个 OpenStack 发行版系列的一部分发布的 Nova 驱动程序至少与来自同一系列的 Ironic 的所有发行版以及来自上一系列的最后一个发行版兼容。
Ramdisk 影响¶
在提议的模型下，ironic、ironic-inspector 和 ironic-python-agent 将大约在同一时间发布。兼容性规则将是
ironic/ironic-inspector 的每个发行版与
同时发生的 ironic-python-agent 的发行版
ironic-python-agent 的最后一个命名发行版
注意
支持这些之间的发行版非常有可能，但未在 CI 中正式保证或测试。
ironic-python-agent 的每个发行版与
同时发生的 ironic 和 ironic-inspector 的发行版
ironic 和 ironic-inspector 的最后一个命名发行版
注意
前三条规则已经在 CI 中强制执行，最后一条将在 ironic-python-agent 上需要一个新的作业，可能基于 Bifrost。
兼容性矩阵将作为预发布文档更新的一部分，并通过未来的网站提供。
我们将发布对应于所有稳定分支、命名和中间分支的 ironic-python-agent 镜像，并提供有关如何基于某个分支或发行版构建自定义镜像的说明。
安全影响¶
支持的中间发行版也将收到安全 bug 修复。
其他最终用户影响¶
参见 其他部署者影响。
可扩展性影响¶
无
性能影响¶
无
其他部署者影响¶
如果选择使用中间发行版，部署者将更快地访问新功能。
开发人员影响¶
没有直接影响。弃用策略没有改变。
实现¶
负责人¶
预计整个团队将负责执行此计划，主要负责人将协调它。
- 主要负责人
Dmitry Tantsur (@dtantsur, dtantsur@protonmail.com)
工作项¶
依赖项¶
无
测试¶
将引入两类新的 CI 作业
ironic 和 ironic-inspector 的中间升级作业，测试从最后一个中间发行版分支的升级。
ironic-python-agent 的反向兼容性作业，以测试每个提交与 ironic 和 ironic-inspector 的先前命名发行版的兼容性（例如，在 Victoria 周期期间，ironic-python-agent 会针对 ironic 和 ironic-inspector 的 stable/ussuri 进行测试）。
预计第三方 CI 作业将以与 master 相同的方式在中间分支上运行。一旦对特定分支的支持结束，就可以关闭针对它的第三方 CI 作业。由于我们只会接受对新分支的高危和关键 bug 修复，预计第三方 CI 系统上的负载只会略有增加。
升级和向后兼容性¶
文档影响¶
为了使中间发行版明显可消费，我们需要一个专注于独立 ironic 的新网站。它将显示组件和 ironic-python-agent 镜像的最新版本，指向消费它们的方式，并为每个次要或主要发行版提供文档。
将更新 发布文档以遵循此模型。
