发布节奏调整：SLURP 模型¶
注意
本文档最初复制自 TC 决议 2022-02-10 发布节奏调整
历史¶
OpenStack 历史上一直使用六个月的发布周期，适用于参与协调发布的项目。此外，升级仅在两个相邻的协调发布之间进行测试和支持，要求部署者和发行版要么每六个月升级一次以保持最新，要么执行快速前进升级 (FFU) 以在运行时在非相邻发布之间移动。后者是通过测试单个升级步骤来实现的活动，我们不会专门测试它。
挑战¶
一些部署者和发行版表明，六个月的升级很困难、不可行或不受欢迎，尤其是在大型环境中，升级过程本身需要足够长的时间，以至于升级会不断发生。FFU 过程可能很繁琐，并且还需要运行在给定环境中可能从未部署、产品化或测试过的发布的部分 - 仅仅因为每个发布都必须在操作过程中逐步使用。
已经表达了许多关于将发布周期更改为较慢（一年）或更慢（18 个月）的节奏以解决这些问题的观点。缺乏关于较慢节奏应该是什么的共识使得很难选择一个有益的节奏，因为一个周期长度可能会导致在较慢周期上的人需要等待更长时间才能进行升级。此外，在流失、人员流动、合同义务和志愿者现实的情况下，放慢速度在许多情况下是不可取的，因此社区参与非常长的发布可能很困难。社区已经难以找到六个月（PTL）和一年（TC）职责的候选人。此外，对于确实需要快速移动、采用新功能和部署新技术的环境，功能着陆到可在生产环境中测试和使用之间数位数的月份太长。
拟议的解决方案¶
很难确定对发布节奏的任何一项更改来解决上述所有问题和疑虑。因此，TC 建议对发布升级期望进行增量更改，以帮助改善缓慢部署者的体验，同时不牺牲尽早发布、经常发布的目標。
根本性的变化在于升级仅在相邻协调发布之间得到支持的期望。TC 将以新的安排指定主要发布版本，以便每隔一个发布版本都被视为“SLURP（跳级升级发布流程）”发布版本。升级将得到“SLURP”发布版本之间的支持，以及在相邻主要发布版本之间（就像今天一样）。希望保持六个月周期的部署将像往常一样部署每个“SLURP”和“非 SLURP”发布版本。希望转为一年升级周期的部署将同步到“SLURP”发布版本，然后跳过下一个“非 SLURP”发布版本，并在随后的“SLURP”发布版本发布时进行升级。
我们的基于字母的发布命名方案即将回到 A，因此该提案是让“新 A”发布版本成为我们执行此方案的第一个版本。Y->A 应该是一个“预演”，我们启用作业来帮助发现任何问题，但尚未做出硬性保证。
偶尔，大型部署者和发行商会偶然选择单个发布版本，这导致比正常情况下更多的维护人员社区，他们会延长维护时间来保持发布版本的“活跃”。我们对该提案的期望是，这将通过增加“SLURP”发布版本以这种方式被选择的可能性，从而放大这种效应，并最终使这些发布版本获得更多关注，以获得长期的社区支持。
详细信息¶
测试：就像我们今天测试并保证升级在相邻发布版本之间得到支持一样，我们也将测试并保证升级在两个“SLURP”发布版本之间得到支持。今天，大多数项目的升级都使用 grenade 进行测试。将在 grenade 存储库中维护一个跳级作业，以测试最后两个“SLURP”发布版本之间的正常配置。该作业将在每个新的“SLURP”发布版本上更新，并且始终会有一个常规的单发布 grenade 作业来测试前一个版本和当前版本之间的关系，就像我们今天一样。
非 SLURP 升级：从“非 SLURP”到“非 SLURP”的升级不会被测试或要求。在给定的“非 SLURP”发布版本上，唯一的升级路径将是下一个发布版本（这将是“SLURP”）。这与今天没有变化。
间隔：跨越一个“SLURP”周期的升级不会被测试或要求。例如，从“SLURP A”到“SLURP E”仍然需要 FFU 风格的安排，但“SLURP C”是唯一需要的中间步骤。
弃用：项目当前至少在一个周期内弃用功能和配置，然后再将其删除。此更改会影响何时可以发生这种情况，以便在“非 SLURP”发布版本中不会发生任何必需的更改，该版本可能会被跳过。实际上，我们今天拥有的规则（书面和部落理解）适用于新的安排，唯一的例外是“周期”指的是“SLURP 到 SLURP”周期，而不是一对相邻的协调发布版本。由于弃用、等待和删除只能在“SLURP”发布版本中发生，因此结果也是弃用之前的时间长度也会增加。
支持：我们预计将支持最新的“SLURP”发布版本以及前一个版本。在“非 SLURP”发布版本期间，这实际上与我们今天支持的内容类似，即 18 个月的“维护”发布版本。请参阅下面的示例序列。
滚动升级：“SLURP”发布版本之间的滚动升级并不一定需要支持此方案。这意味着 N 到 N-1 之间的 RPC 兼容性可以保持不变，从而导致在“SLURP 到 SLURP”发布计划上的部署在升级期间需要一些停机时间，因为组件将跨越两个实际发布版本。
数据迁移：支持“SLURP 到 SLURP”升级的一部分是保持稳定的（读作“兼容的”，而不是“不变的”）数据库模式，从“SLURP”到“SLURP”。这包括需要在“SLURP”发布版本中进行工作的数据迁移，虽然它们可能在“非 SLURP”发布版本中进行工作，但“非 SLURP”发布版本中完成的工作不能是强制性的。这可以通过（就像今天一样）要求操作员在移动到放弃兼容性的版本之前，在受支持的发布版本上（强制）完成数据迁移来解决。本文档中描述的“SLURP”、“非 SLURP”安排需要关注这些迁移，以确保它们在源“SLURP”上发生（自动或手动）后再升级到目标“SLURP”，例如。
沟通：我们将使用“SLURP”一词在发布页面、发布说明页面或我们想要沟通它的任何其他地方来指定 SLURP 发布版本。如果需要，我们也可以使用其全称“跳级升级发布流程”。“非 SLURP”发布版本将不会被指定任何内容，并且没有“SLURP”一词足以传达这不是“SLURP”发布版本。此外，发布命名过程中的数字模式将帮助我们所有人了解哪个发布版本是“SLURP”。
示例序列¶
假设 A 是此新安排的第一个发布版本，以下示例有助于演示支持生命周期期望。
发布版本 |
类型 |
受支持 |
EM |
A |
SLURP |
X,Y,Z |
W |
B |
Y,Z,A |
W,X |
|
C |
SLURP |
A,B,C |
W,X,Y,Z |
D |
A,B,C,D |
X,Y,Z |
|
E |
SLURP |
C,D,E |
Y,Z,A,B |
F |
C,D,E,F |
Z,A,B |
|
G |
SLURP |
E,F,G |
A,B,C |
(EM 发布版本在上面的示例中被任意删除以简化内容，但本文档中没有对它们可以被支持的时间长度进行任何更改)
