无分支的Tempest¶
https://blueprints.launchpad.net/tempest/+spec/branchless-tempest
Tempest 历史上一直被视为核心服务，在 OpenStack 的每个发布周期都会切出一个 stable/foo 发布分支。然而，Tempest 主要是对 OpenStack API 的黑盒测试。API 由主要版本表示，而不是由发布标签表示，因此 Tempest 不需要分支。这种改变将产生许多有趣且级联的影响，所有这些都应该对项目的健康状况产生积极影响。
问题描述¶
Tempest 当前的发布方式是在 OpenStack 核心服务的每个发布周期创建一个 stable/foo 分支。这产生了一些副作用。
测试仅添加到 master 分支，很少回移植。完全有效的 stable/havana 测试已经丢失。
stable/havana 和 master 之间的行为可能会发生变化，因为它们之间运行的测试版本不同
持续集成/持续交付 (CD) 公有云应该针对 Tempest 的哪个版本进行测试？（即，发布对许多用户来说没有意义）
stable/havana 最终被用作 OpenStack 中支持的功能的全局标志。但这没有意义，因为大多数环境运行的是具有特定功能列表启用的配置，而不仅仅是我们 stable/havana 中发布的所有内容。
Tempest 有机地发展成为一种在我们的上游 gate 中工作非常好的工具，对于测试实际部署的人来说，效果中等。造成这种差异的原因之一是，我们使用 stable/foo Tempest 分支来对服务和 devstack 建立假设，而 devstack 设置 Tempest。打破这种便利关系将使我们更加严格地明确 Tempest 是一种旨在在任何设置环境中运行的工具。
提议的变更¶
在提议的无分支环境中，我们将执行以下操作
不设置 stable/icehouse Tempest 分支
stable/icehouse 集成服务将使用 Tempest master 进行测试
Tempest master 将基于以下内容上的成功运行进行 gate 限制
master 分支上的集成服务
stable/icehouse 分支上的集成服务
(注意：这将使 Tempest 提议的变更的作业数量翻倍)
发布后，devstack-gate 将更改为显式设置 Tempest 期望测试的服务，以及每个分支上期望测试的扩展。
这具有级联影响，最好描述为场景（我将使用 nova 作为示例服务，主要是因为我对扩展模型更熟悉，而不是因为 nova 被针对）
场景 1：用于新功能的新测试¶
如果在 Juno 中添加了 Nova 的新功能，并且为该功能添加了 Tempest 的新测试，则该测试需要位于功能标志之后（因为该功能在 Icehouse 中不可用）。
nova stable/icehouse - 测试已跳过，功能不可用
nova master - 运行测试
这具有额外的优势，可以确保新的 Nova 变更以某种可发现的方式添加，即它不存在（即，位于未加载的扩展中），并且 Tempest 具有配置或不配置它的旋钮。
场景 2：需要 Tempest 变更的核心项目中的错误修复¶
以前，nova master 中的行为变化需要 Tempest 变更，可以通过 tempest 的 2 步流程来更改
提出 nova 的变更，获得 nova +2
提出 Tempest 的跳过，在 nova +2 变更后 +Aed
将 nova 变更合并到 master 和 stable/icehouse（如果需要）
将更改后的测试合并到 Tempest
在这个新模型中，该变更也需要同时回移植到 stable/icehouse。或者，我们决定这是一种不应该进行测试的行为，并完全删除该测试。
场景 3：用于现有功能的新测试¶
在添加用于现有功能的新的测试时，新的测试需要同时通过针对 nova master 和 nova stable/icehouse 的测试。如果发现两者之间存在行为差异，我们需要在合并测试之前协调该行为。我们最终有 3 个选项
修复 nova master 以反映 nova stable/icehouse 行为（nova 回归）
修复 nova stable/icehouse 以反映 nova master 行为（缺少回移植）
决定不合并 Tempest 测试，因为它试图验证我们不认为稳定的行为
场景 4：过时的测试¶
例如，Nova XML v2 在 icehouse 中已弃用，并在 juno 中（假设）删除。然而，XML v2 测试在 Tempest 中，我们仍然需要测试 icehouse 发布。
这将通过缓慢弃用/功能标志来处理
添加 Tempest v2 XML 功能标志（默认值为 false）
修改 devstack-gate 以设置为 stable/icehouse 的 true
测试在 master 中跳过，在 stable/icehouse 中运行
一旦 stable/icehouse 不再受上游支持（2015 年 2 月），测试将完全从 Tempest 中删除。
这意味着 Tempest 将包含更多的遗留代码，但是这是我们接受的权衡，以获得它提供的优势。
其他影响¶
这将产生一些有趣的其他影响
stable/* 分支不会经常被破坏：由于大量的 tempest 补丁需要一个工作的 stable/* gate 才能合并，stable/* 将获得更定期的测试，并且更经常处于工作状态
API 保证将收紧。我们将不仅测试 Tempest 中 API 是否符合我们的预期，还将测试它在多个版本中是否表现相同。破坏这种行为的额外摩擦将减缓未来任何破坏。这意味着 API 兼容性要求的实际提高。
替代方案¶
另一种选择是继续使用当前的方法，该方法在 Tempest 中使用 stable/* 分支。然而，这导致了与 devstack 更多的不必要的耦合，我相信从长远来看，对于像 Tempest 这样的测试套件来说，这并不是正确的方法。
实现¶
负责人¶
- 主要负责人
Sean Dague <sean@dague.net>
如果他们打算在此蓝图上进行大量实现工作，可以选择性地列出其他 ID。
里程碑¶
完成目标里程碑
4 月 17 日用于主要基础设施
Juno 发布周期以处理各种回移植到 devstack stable/icehouse 以支持所有 tempest 功能标志
工作项¶
工作项目跨项目
devstack-gate 通用分支覆盖支持 (DONE)
基础设施作业以在 stable/icehouse 上 gate Tempest（可用时）
devstack-gate 更改以选择不仅服务，而且每个发布版本支持的功能
devstack 支持设置 stable/icehouse 功能
其他 Tempest 功能标志用于尚未解决的可选功能
依赖项¶
仅以上列出的
