openstack
/
governance
Code Issues Proposed changes

Changing new release cadence name 

With the outcome of the legal check, it is not clear to us
that tick tock words are ok to use for our new release
cadence arrangement and in what form.

In TC, we decided to use a different name and 'SLURP'
is the choice of the majority[1]

Let's update our resolution document to reflect the new name
and I am adding a "communication" section to explain that how
we will use "SLURP" in our documentation.

[1] https://meetings.opendev.org/meetings/tc/2022/tc.2022-05-12-15.00.log.html#l-191

Change-Id: If82240c1f62842314b48caa4694280c0be147919
This commit is contained in:
Ghanshyam Mann 2022-05-03 11:20:56 -05:00
parent 584e06b0c1
commit 340683abcb
1 changed files with 53 additions and 46 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

99
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
supported between adjacent coordinated releases. The TC will designate
major releases in a tick-tock arrangement, such that every other
release will be considered to be a "tick" release. Upgrades will be
supported between tick releases, in addition to between adjacent major
releases (as they are today). Deployments wishing to stay on the
six-month cycle will deploy every tick and tock release as they always
have. Deployments wishing to move to a one year upgrade cycle will
synchronize on a tick release, and then skip the following tock
release, upgrading when the subsequent tick is released.
major releases in a new arrangement, such that every other release will be
considered to be a "SLURP (Skip Level Upgrade Release Process)" release.
Upgrades will be supported between "SLURP" releases, in addition to between
adjacent major releases (as they are today). Deployments wishing to stay on
the six-month cycle will deploy every "SLURP" and "not-SLURP" release as they
always have. Deployments wishing to move to a one year upgrade cycle will
synchronize on a "SLURP" release, and then skip the following "not-SLURP"
release, upgrading when the subsequent "SLURP" is released.
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
@ -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
extended maintenance for longer. The expectation with this proposal is
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.
Details
@ -78,71 +78,78 @@ Details
#. **Testing**: Just as we test and guarantee that upgrades are
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
skip-level job will be maintained in the grenade repository that
tests a normal configuration between the last two tick
releases. The job will be updated on every new tick release, and
tests a normal configuration between the last two "SLURP"
releases. The job will be updated on every new "SLURP" release, and
there will always be a regular single-release grenade job testing
between the previous release and current one, as we have today.
#. **Tock upgrades**: Upgrades from tock to tock will not be tested
nor required. On a given tock release, the only upgrade path will
be to the following release (which would be a tick). This is
unchanged from today.
#. **Intervals**: Upgrades that span more than one tick cycle are not
tested or required. For example to move from tick A to tick E will
still require an FFU style arrangement, but where tick C is the
#. **Not-SLURP upgrades**: Upgrades from "not-SLURP" to "not-SLURP" will
not be tested nor required. On a given "not-SLURP" release, the only
upgrade path will be to the following release (which would be a "SLURP").
This is unchanged from today.
#. **Intervals**: Upgrades that span more than one "SLURP" cycle are not
tested or required. For example to move from "SLURP A" to "SLURP E" will
still require an FFU style arrangement, but where "SLURP C" is the
only intermediate step required.
#. **Deprecations**: Projects currently deprecate features and config
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
have today (both written and tribally-understood) apply to the new
arrangement, with the exception that "cycle" refers to a tick-tick
cycle and not a single pair of adjacent coordinated releases. Since
the deprecation, waiting, and removal can only happen in tick
arrangement, with the exception that "cycle" refers to a "SLURP to
SLURP" cycle and not a single pair of adjacent coordinated releases.
Since the deprecation, waiting, and removal can only happen in "SLURP"
releases, the result is also that the minimum *length* of time that
things may be deprecated before removal will increase as well.
#. **Support**: We will expect to support both the most recent tick
release as well as the one prior. During a tock release, that would
effectively be similar to what we support today, which is 18 months
#. **Support**: We will expect to support both the most recent "SLURP"
release as well as the one prior. During a "note-SLURP" release, that
would effectively be similar to what we support today, which is 18 months
of "maintained" releases. See the example sequence below.
#. **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
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
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
schema from tick-tick. This includes data migrations which need to
do work in tick releases, and while they may do work in tock
releases, the work done in tock releases cannot be
schema from "SLURP to SLURP". This includes data migrations which need to
do work in "SLURP" releases, and while they may do work in "not-SLURP"
releases, the work done in "not-SLURP" releases cannot be
*mandatory*. This can be solved (as it is today) by requiring
operators to (force-)complete data migrations on a supported
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
(automatically or manually) on the source tick before upgrading to
the target tick, for example.
(automatically or manually) on the source "SLURP" before upgrading to
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
----------------
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
expectation.
======= ==== ========= =======
Release Type Supported EM
A tick X,Y,Z W
B tock Y,Z,A W,X
C tick A,B,C W,X,Y,Z
D tock A,B,C,D X,Y,Z
E tick C,D,E Y,Z,A,B
F tock C,D,E,F Z,A,B
G tick E,F,G A,B,C
======= ==== ========= =======
======= ===== =========== ========
Release Type Supported 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 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