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 分支（对于具有 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 镜像的最新版本，指向消费它们的方式，并为每个次要或主要发布版本提供文档。
将更新 发布文档以遵循此模型。
