openstack/governance
Code Issues Proposed changes

Merge "Changing new release cadence name"

Browse Source
This commit is contained in:
Zuul
2022-05-20 17:56:56 +00:00
committed by Gerrit Code Review
parent 353dfb7b62 340683abcb
commit de73458a6b
1 changed files with 53 additions and 46 deletions
Download Patch File Download Diff File Expand all files Collapse all files

97
resolutions/20220210-release-cadence-adjustment.rst
View File

@@ -50,14 +50,14 @@ without sacrificing the release-early-release-often goal.
The fundamental change comes to the expectation that upgrades are only The fundamental change comes to the expectation that upgrades are only
supported between adjacent coordinated releases. The TC will designate supported between adjacent coordinated releases. The TC will designate
major releases in a tick-tock arrangement, such that every other major releases in a new arrangement, such that every other release will be
release will be considered to be a "tick" release. Upgrades will be considered to be a "SLURP (Skip Level Upgrade Release Process)" release.
supported between tick releases, in addition to between adjacent major Upgrades will be supported between "SLURP" releases, in addition to between
releases (as they are today). Deployments wishing to stay on the adjacent major releases (as they are today). Deployments wishing to stay on
six-month cycle will deploy every tick and tock release as they always the six-month cycle will deploy every "SLURP" and "not-SLURP" release as they
have. Deployments wishing to move to a one year upgrade cycle will always have. Deployments wishing to move to a one year upgrade cycle will
synchronize on a tick release, and then skip the following tock synchronize on a "SLURP" release, and then skip the following "not-SLURP"
release, upgrading when the subsequent tick is released. release, upgrading when the subsequent "SLURP" is released.
Our letter-based release naming scheme is about to wrap back around to Our letter-based release naming scheme is about to wrap back around to
A, so the proposal is that the "new A" release be the first one where A, so the proposal is that the "new A" release be the first one where
@@ -70,7 +70,7 @@ deployers and distributors by chance, which results in a larger than
normal community of maintainers that keep the release "alive" in normal community of maintainers that keep the release "alive" in
extended maintenance for longer. The expectation with this proposal is extended maintenance for longer. The expectation with this proposal is
that this will amplify that effect by increasing the likelihood that that this will amplify that effect by increasing the likelihood that
"tick" releases will be chosen in this way and thus end up with more "SLURP" releases will be chosen in this way and thus end up with more
focus on those releases for long-term community support. focus on those releases for long-term community support.
Details Details
@@ -78,71 +78,78 @@ Details
#. **Testing**: Just as we test and guarantee that upgrades are #. **Testing**: Just as we test and guarantee that upgrades are
supported between adjacent releases today, we will *also* test and supported between adjacent releases today, we will *also* test and
guarantee that upgrades between two tick releases are supported. guarantee that upgrades between two "SLURP" releases are supported.
Upgrades are tested for most projects today with grenade. A Upgrades are tested for most projects today with grenade. A
skip-level job will be maintained in the grenade repository that skip-level job will be maintained in the grenade repository that
tests a normal configuration between the last two tick tests a normal configuration between the last two "SLURP"
releases. The job will be updated on every new tick release, and releases. The job will be updated on every new "SLURP" release, and
there will always be a regular single-release grenade job testing there will always be a regular single-release grenade job testing
between the previous release and current one, as we have today. between the previous release and current one, as we have today.
#. **Tock upgrades**: Upgrades from tock to tock will not be tested #. **Not-SLURP upgrades**: Upgrades from "not-SLURP" to "not-SLURP" will
nor required. On a given tock release, the only upgrade path will not be tested nor required. On a given "not-SLURP" release, the only
be to the following release (which would be a tick). This is upgrade path will be to the following release (which would be a "SLURP").
unchanged from today. This is unchanged from today.
#. **Intervals**: Upgrades that span more than one tick cycle are not #. **Intervals**: Upgrades that span more than one "SLURP" cycle are not
tested or required. For example to move from tick A to tick E will tested or required. For example to move from "SLURP A" to "SLURP E" will
still require an FFU style arrangement, but where tick C is the still require an FFU style arrangement, but where "SLURP C" is the
only intermediate step required. only intermediate step required.
#. **Deprecations**: Projects currently deprecate features and config #. **Deprecations**: Projects currently deprecate features and config
for at least one cycle before removal. This change affects *when* for at least one cycle before removal. This change affects *when*
that can happen, so that no required changes occur in a tock that can happen, so that no required changes occur in a "not-SLURP"
release which may be skipped. Effectively the same rules that we release which may be skipped. Effectively the same rules that we
have today (both written and tribally-understood) apply to the new have today (both written and tribally-understood) apply to the new
arrangement, with the exception that "cycle" refers to a tick-tick arrangement, with the exception that "cycle" refers to a "SLURP to
cycle and not a single pair of adjacent coordinated releases. Since SLURP" cycle and not a single pair of adjacent coordinated releases.
the deprecation, waiting, and removal can only happen in tick Since the deprecation, waiting, and removal can only happen in "SLURP"
releases, the result is also that the minimum *length* of time that releases, the result is also that the minimum *length* of time that
things may be deprecated before removal will increase as well. things may be deprecated before removal will increase as well.
#. **Support**: We will expect to support both the most recent tick #. **Support**: We will expect to support both the most recent "SLURP"
release as well as the one prior. During a tock release, that would release as well as the one prior. During a "note-SLURP" release, that
effectively be similar to what we support today, which is 18 months would effectively be similar to what we support today, which is 18 months
of "maintained" releases. See the example sequence below. of "maintained" releases. See the example sequence below.
#. **Rolling Upgrades**: This scheme does not necessarily dictate that #. **Rolling Upgrades**: This scheme does not necessarily dictate that
live or rolling upgrades need to be supported between tick live or rolling upgrades need to be supported between "SLURP"
releases. Meaning RPC compatibility between N to N-1 guarantees can releases. Meaning RPC compatibility between N to N-1 guarantees can
remain, resulting in deployments that are on a tick-tick release remain, resulting in deployments that are on a "SLURP to SLURP" release
schedule requiring some downtime during an upgrade because schedule requiring some downtime during an upgrade because
components will be spanning more than two actual releases. components will be spanning more than two actual releases.
#. **Data migrations**: Part of supporting tick-tick upgrades involves #. **Data migrations**: Part of supporting "SLURP to SLURP" upgrades involves
keeping a stable (read "compatible" not "unchanging") database keeping a stable (read "compatible" not "unchanging") database
schema from tick-tick. This includes data migrations which need to schema from "SLURP to SLURP". This includes data migrations which need to
do work in tick releases, and while they may do work in tock do work in "SLURP" releases, and while they may do work in "not-SLURP"
releases, the work done in tock releases cannot be releases, the work done in "not-SLURP" releases cannot be
*mandatory*. This can be solved (as it is today) by requiring *mandatory*. This can be solved (as it is today) by requiring
operators to (force-)complete data migrations on a supported operators to (force-)complete data migrations on a supported
release before moving to one that drops compatibility. The release before moving to one that drops compatibility. The
tick-tock arrangement described in this resolution would require "SLURP", "not-SLURP" arrangement described in this resolution would require
attention to those migrations to make sure they happen attention to those migrations to make sure they happen
(automatically or manually) on the source tick before upgrading to (automatically or manually) on the source "SLURP" before upgrading to
the target tick, for example. the target "SLURP", for example.
#. **Communication**: We will use "SLURP" word to designate a SLURP release
in release page, release notes page or any other place we want to communicate
it. We can also use its full form "Skip Level Upgrade Release Process"
if needed. A "not-SLURP" release will not be designated with anything and
not having "SLURP" word is enough to communicate that this is not "SLURP"
release. Also, the number schema in the release naming process will help all
of us to relate which release is "SLURP".
Example sequence Example sequence
---------------- ----------------
Assuming that A is the first release of this tick-tock arrangement, Assuming that A is the first release of this new arrangement,
the following examples help demonstrate the support lifecycle the following examples help demonstrate the support lifecycle
expectation. expectation.
======= ==== ========= ======= ======= ===== =========== ========
Release Type Supported EM Release Type Supported EM
A tick X,Y,Z W A SLURP X,Y,Z W
B tock Y,Z,A W,X B Y,Z,A W,X
C tick A,B,C W,X,Y,Z C SLURP A,B,C W,X,Y,Z
D tock A,B,C,D X,Y,Z D A,B,C,D X,Y,Z
E tick C,D,E Y,Z,A,B E SLURP C,D,E Y,Z,A,B
F tock C,D,E,F Z,A,B F C,D,E,F Z,A,B
G tick E,F,G A,B,C G SLURP E,F,G A,B,C
======= ==== ========= ======= ======= ===== =========== ========
(EM releases are arbitrarily pruned in the above example for brevity, (EM releases are arbitrarily pruned in the above example for brevity,
but no such change in how long they may be supported is made in this but no such change in how long they may be supported is made in this