将 TripleO 仓库迁移到独立的发布模式¶
包含您的 Launchpad 蓝图的 URL
https://blueprints.launchpad.net/tripleo
本文档提出将所有 tripleo 仓库迁移到独立的发布模式。该提案最初在 tripleo irc 会议上提出 [1]，随后也在 openstack-discuss 邮件列表中讨论 [2]。
问题描述¶
TripleO 仓库 [3] 大部分遵循周期性发布模型，例如 tripleo-heat-templates 在 [4]。但也有部分 tripleo 仓库使用独立的发布模式，例如 tripleo-upgrade 在 [5]。不同发布模型的描述可以在 [6] 找到。
通过遵循周期性发布模型，TripleO 必须为每个 OpenStack 开发周期生成一个发布版本，并在 tripleo 仓库中创建一个对应的稳定/分支。然而，正如我们所见，这造成了持续的维护负担；目前 TripleO 支持 5 个活跃分支 - Train、Ussuri、Victoria、Wallaby 和 Xena（当前 master）。事实上，直到最近，该列表还包含 7 个分支，包括 Stein 和 Queens（目前正在迁移到生命周期结束 [7]）。
这造成了持续的维护和资源负担，对于每个分支，我们都需要回移植更改、实施、运行和维护上游 CI，并确保与 OpenStack 的其余部分以及第三方 CI 和组件及集成推广流水线的兼容性 [8]，并且需要持续进行。
此外，分支之间底层 OS 的变化意味着对于某些分支，我们需要维护两种“类型”的 CI 作业；对于 stable/train，我们需要同时支持 CentOS 7 和 CentOS 8。随着 stable/xena 的即将到来，如果 Stream-9 在 xena 发布时尚未完全可用，我们可能还需要支持 CentOS-Stream-8 以及 CentOS-Stream-9，这进一步加剧了资源负担。通过采纳本文档中提出的方案，我们可以选择跳过 Xena 分支，从而避免增加 CI 和维护成本。
提议的变更¶
概述¶
该提案是让所有当前使用周期性发布模型的 TripleO 仓库切换到独立发布模式。这将允许我们选择跳过特定的发布版本，更重要的是，跳过在这些仓库中创建给定的稳定/分支。
这将使 TripleO 社区能够将资源集中在对我们来说最“重要”的分支上，即“FFU 分支”。也就是说，参与 TripleO Fast Forward Upgrade 链的分支（目前这些分支是 Train -> Wallaby -> Z？）。例如，我们很可能不会创建 Xena 分支。
开发人员将不再需要跨稳定/分支回移植更改，这将对我们的上游 CI 资源消耗和维护负担产生巨大影响。
替代方案¶
我们可以继续创建所有稳定/分支，并使用我们当前相同的发布模型。这将意味着我们将继续面临增加的维护负担，并且需要通过增加资源来解决这个问题。
安全影响¶
无
升级影响¶
对于升级，这意味着 TripleO 将不再直接支持所有 OpenStack 稳定分支。因此，如果我们决定不创建 stable/xena，例如，则无法使用 TripleO 从 wallaby 升级到 xena。在某些方面，这更符合实际情况，因为活跃的 tripleo 开发社区的重点通常是确保 Fast Forward Upgrade（例如，train 到 wallaby），而不是确保两个分支之间的点对点升级。
其他最终用户影响¶
TripleO 将不再能够部署所有版本的 OpenStack。在关于此主题的讨论中提出的一种想法是，我们可以尝试通过将一系列 git 标签指定为与特定的 OpenStack 稳定分支兼容来解决这个问题。
例如，如果 TripleO 没有创建 stable/xena，但在 xena 周期内为各种 Tripleo 仓库发布版本，那么这些版本将与部署 OpenStack stable/xena 兼容。我们可以维护和公布每个受影响仓库的兼容标签集（例如，tripleo-heat-templates 版本 15.0.0 到 15.999.999 与 OpenStack stable/xena 兼容）。
一些关于标签的规则将帮助我们。通常，我们可以继续按照当前的方式进行标签处理；对于 major.minor.patch（例如 15.1.1），在发布标签中，我们将始终增加 major 以表示新的稳定分支。
这个解决方案的一个问题是，没有地方可以回移植修复。例如，如果您使用 tripleo-heat-templates 15.99.99 来部署 OpenStack Xena（并且没有 stable/xena），那么您必须将任何修复程序应用于 15.99.99 标签的顶部并使用它。无法将这些修复程序提交到代码仓库中。
性能影响¶
无
其他部署者影响¶
openstack-discuss 线程 [2] 中提出了一些关于 RDO 软件包以及该提案将如何影响它的担忧。正如讨论的那样，RDO 没有计划停止为任何分支构建软件包。对于构建 tripleo 仓库，我们将不得不依赖最新的兼容 git 标签，如上文 其他终端用户影响 中所述。
开发人员影响¶
将减少需要回移植修复的稳定/分支。但是，重要的是要注意，通过跳过某些分支，跨多个分支进行回移植会导致更大的代码差异，因此开发人员更难实施。也就是说，如果我们跳过中间分支，回移植的复杂性将会增加。
如上文 其他终端用户影响 部分所述，对于 tripleo 决定不创建的分支，开发人员将没有地方可以提交任何特定于分支的修复程序。他们可以使用与给定分支兼容的 TripleO 仓库的特定标记版本，但将无法将这些更改提交到上游仓库，因为该分支不存在。
实现¶
负责人¶
Wesley Hayutin <weshay@redhat.com> Marios Andreou <marios@redhat.com>
工作项¶
除了将评论发布到发布仓库 [9] 之外，我们需要更新文档以反映和告知此更改。
依赖项¶
无
测试¶
无
文档影响¶
是的，我们至少需要向文档添加一些部分来解释这一点。我们还可以添加一个登录页面来显示当前“活跃”或受支持的 TripleO 分支。
