TripleO 发布分支提案

迄今为止，大多数使用 TripleO 的用户都是通过所需各种仓库的主分支来使用，以便 TripleO 能够部署 OpenStack 云。本文档提出了一种替代的“发布分支”方法，该方法应使使用稳定 OpenStack 版本的用户更容易使用 TripleO 进行部署。

问题描述

历史上，我们从未对部署当前稳定的 OpenStack 版本做出强有力的保证，并且我们也没有在上游 CI 中进行测试。从开发人员的角度来看，这很好，但对于希望基于稳定的 OpenStack 版本/分支部署生产云的用户来说，这是一个主要障碍。

提议的变更

我建议我们考虑支持额外的“发布”分支，用于需要特定版本更改的选定 TripleO 仓库。

该模型将基于许多/大多数 OpenStack 项目使用的稳定分支模型[1]，但有一个区别，“功能”回移植将被允许，前提是它们与当前发布的 OpenStack 服务 100% 兼容。

概述

允许功能的原因是，大多数 TripleO 功能实际上是启用对 OpenStack 服务功能的访问，这些功能将存在于正在部署的服务的稳定分支中。因此，此分支的目标受众可能希望使用这些“功能”来更好地访问适合他们正在使用的 OpenStack 版本的特性和配置。

另一个方面的理由是，项目正在不断添加功能，因此 TripleO 很难在 Liberty 发布的第一天就与所有可能的新功能保持一致。认识到我们将“迎头赶上”，并采用合适的分支策略，应该意味着在服务本身发布后，仍然可以继续保持一致性，这对我们的用户将是有益的。

着陆在主分支上的更改可以被认为是回移植的有效候选对象，除非

  • 补丁需要 OpenStack 服务的（在稳定分支上不存在的）新功能才能运行。例如，如果 tripleo-heat-templates 更改需要 Liberty 的新 Heat 功能，则不允许将其回移植到 release/kilo。

  • 补丁启用了 OpenStack 服务的 Overcloud 功能，这些功能不存在于受支持的 Overcloud 版本的稳定分支上（例如，对于 release/kilo，我们仅支持 kilo overcloud 功能）。

  • 用户可见的接口被修改、重命名或删除 - 删除已弃用的接口在主分支上可能是允许的（在适当的弃用期之后），但这些更改不适用于回移植，因为它们可能会在没有警告的情况下影响现有用户。 允许添加新的接口，例如提供程序资源或参数，前提是默认行为不会影响发布分支的现有用户。

  • 补丁引入了新的依赖项或更改了当前的 requirements.txt。

为了更容易地识别不适用于回移植的更改，建议采用审查流程，即提出补丁到主分支的开发人员如果补丁不满足上述标准，或者有其他原因导致补丁不适合回移植，则标记提交。

例如

No-Backport: 此补丁需要 Mitaka 的新 Heat 功能

替代方案

另一种选择是让上游 TripleO 成为主要针对开发人员/跟踪主干用户的项目，并将维护各种组件的稳定分支留给 TripleO 的下游用户，例如 rdo-manager。

这种方法的缺点是它阻碍了采用和参与上游项目，因此我认为在 upstream 中进行这项工作，并改善那些希望通过 TripleO 使用上游工具和版本进行部署的用户体验会更好。

安全影响

我们需要确保着陆在主分支中的安全相关的补丁被适当地应用到发布分支（与所有其他项目的稳定分支相同）。

其他最终用户影响

这将使最终用户更容易地使用 OpenStack 服务的稳定发布版本来启动 TripleO 部署的云。

其他部署者影响

这可能会减少多个 TripleO 的下游用户重复工作的情况。

开发人员影响

理想情况下，提出补丁到主分支的开发人员将提出有效的回移植建议，但为了避免为新贡献者设置不必要的进入壁垒，这将不是强制性的，但将在代码审查评论中推荐和鼓励。

将遵守标准的 stable-maint 流程[1] 来提出回移植。

我们需要考虑是否需要一个单独的 stable-maint 核心（就像大多数其他项目一样），或者所有 tripleo-core 成员都可以批准回移植。 最初预计允许所有 tripleo-core 成员，可能还会增加一些对分支维护有特殊兴趣的人员（例如下游软件包维护人员）。

实现

最初，以下仓库将获得发布分支

  • openstack/tripleo-common

  • openstack/tripleo-docs

  • openstack/tripleo-heat-templates

  • openstack/tripleo-puppet-elements

  • openstack/python-tripleoclient

  • openstack/instack-undercloud

所有这些都将创建一个新的分支，理想情况下在即将发布的 liberty 版本附近，并且为了避免对现有的基础设施工具（例如 zuul）进行不必要的修改，它们将使用标准的稳定分支命名，例如：

  • stable/liberty

如果任何其他仓库需要稳定分支，我们可以在需要时稍后添加它们。

预计任何没有稳定/发布分支的仓库都必须保持兼容性，以免破坏部署稳定的 OpenStack 版本（如果这在任何情况下都不可行，我们将根据需要创建分支）。

此外，在创建发布分支后，我们将明确不要求这些仓库的主分支遵守向后兼容性，关于使用新的 OpenStack 功能。 例如，在为该仓库创建 stable/liberty 分支后，tripleo-heat-templates 主分支上可以消耗新的 Mitaka Heat 功能。

负责人

主要负责人

shardy

其他贡献者

待定

工作项

  1. 确定需要发布分支的仓库

  2. 创建分支

  3. 向开发人员传达回移植的需求，考虑自动化选项

  4. CI 作业以确保发布分支保持正常工作

  5. 文档说明用户如何使用发布分支

测试

我们需要配置 CI 作业来使用 TripleO 发布分支，部署其他 OpenStack 项目的稳定分支。 希望我们可以利用例如 RDO 包来获取大部分项目稳定分支的内容，然后为 tripleo 发布分支的内容构建 delorean 包。

理想情况下，将来我们还应该测试从一个发布分支到另一个发布分支的升级（例如，从之前的当前版本，和/或从发布分支到主分支）。

作为起点，derekh 建议我们创建一个单一的 centos 作业，仅测试 HA，并且我们避免拥有一个 tripleo-ci 发布分支，理想情况下使用正在开发中的[2] tripleo.sh 开发人员脚本来抽象分支之间部署步骤的任何差异。

文档影响

我们需要更新文档以显示

1. 如何使用稳定版本的 OpenStack 服务从发布分支部署 undercloud 节点 2. 如何构建包含来自发布分支内容的镜像 3. 如何仅使用发布分支版本部署 overcloud

参考资料

我们在此线程中开始讨论这个想法

http://lists.openstack.org/pipermail/openstack-dev/2015-August/072217.html

[1] https://wiki.openstack.org/wiki/StableBranch [2] https://review.openstack.org/#/c/225096/