Open Stack

Hi everyone,

On Tuesday afternoon of the PTG week we had a track of discussions to
brainstorm how to better align our release cycle and stable branch
maintenance with the OpenStack downstream consumption models.

You can find the notes at:
https://etherpad.openstack.org/p/release-cycles-ptg-rocky

TL;DR: summary:
* No consensus on longer / shorter release cycles
* Focus on FFU to make upgrades less painful
* Longer stable branch maintenance time (18 months for Ocata)
* Bootstrap the "extended maintenance" concept with common policy
* Group most impacted by release cadence are packagers/distros/vendors
* Need for finer user survey questions on upgrade models
* Need more data and more discussion, next discussion at Vancouver forum
* Release Management team tracks it between events

Details:

We started the discussion by establishing a taxonomy of consumption
models and upgrade patterns. This exercise showed that we are lacking
good data on how many people follow which. The user survey asks what
people are using to deploy and what they are running, but the questions
are a bit too simple (some deploys have a mix of versions, what should
they answer) or incomplete (some deployment mechanisms combine
high-level and low-level packaging). It also misses the question of the
upgrade pattern completely. I took the action of circling back with the
user survey folks to see if we could enrich (or add to) those questions
in the future.

Another point of data, Swift seems to be the only component with an
established pattern of upgrading at every intermediary release (as
opposed to random points on master, or every final release). It is
probably due to it being consumed standalone more than others.

We continued by discussing upgrade motivation and upgrade issues. A lot
of participants reported on keeping current so that you don't put
yourself in a corner having an impossible upgrade in the future.
Otherwise not much surprise there.

The bulk of the discussion was around the impact of the release cadence.
The most obvious user impact (pressure to upgrade) would be mostly
covered by the work being done on fast-forward upgrades. Once that is a
proven model of upgrading OpenStack, the cadence of release stops being
a problem to become an asset (more choice has to where you fast-forward
to). The other big user impact (support ending too early) would be
mostly covered by the work being done to extend maintenance on stable
branches. Again, the cadence of release is actually not the real cause
of the pain felt there, and there is already work in progress to
directly address the issue.

That said, the release cadence definitely has cost for people working
downstream from the OpenStack software release. Release marketing, and
the community-generated roadmap are both examples of per-release work.
We need to work on ways to make releases more business as usual and less
of an exceptional event there.

At this point the groups the most impacted by the release cadence are
those working on packaging OpenStack releases, either as part of the
open source project (OpenStackAnsible, tripleO...) or as part of a
vendor product. It can be a lot of work to do the
packaging/integration/test/certification work and releasing more often
means that this work needs to be done more often. It is difficult for
those to "skip" a release since users are generally asking for the
latest features to be made available.

We have also traditionally tied a number of other things to the release
cadence: COA, events, elections. That said nothing forces us to really
tie those one-for-one, although to keep our sanity we'd likely want to
keep one a multiple of the other.

Overall, the discussion on cadence concluded that ongoing work on
fast-forward upgrades and longer stable branch maintenance would
alleviate 80% of the release cadence pain with none of the drawbacks of
releasing less often, and therefore we should focus our efforts on that
for the moment.

The topic of discussion then switched to discussing stable branch
maintenance and LTS in more detail. The work done on tracking
upper-constraints finally paid off, with stable branches now breaking
less often. The stable team is therefore comfortable extending the life
of Ocata for 6 more months (for a total of 18 months).

This should make Ocata the first candidate for "extended maintenance" (a
new name for "LTS" that does not imply anyone providing "support").
Extended maintenance, as discussed by the group, would be about letting
branches open for as long as there is someone caring for them (and close
them once they are broken or abandoned). This inverts the current
chicken and egg resource issue on stable maintenance: we should
establish the concept and once it exists hopefully interested parties
will come. We discussed the need for a common policy around those
branches (like "no feature backport") so that there is still some
consistency. mriedem volunteered to work on a TC resolution to define
what we exactly meant by that (the proposal is now being discussed at
https://review.openstack.org/#/c/548916/).

The afternoon concluded with the group agreeing on the need to continue
the discussion on this important topic. The next stop should be a forum
session at the Vancouver Summit. The release management team agreed to
track progress on this between events.

Thanks for reading until the end!

-- 
Thierry Carrez (ttx)