Open Stack

Excerpts from John Dickinson's message of 2017-11-10 14:51:08 -0800:
> On 7 Nov 2017, at 15:28, Erik McCormick wrote:
> 
> > Hello Ops folks,
> >
> > This morning at the Sydney Summit we had a very well attended and very
> > productive session about how to go about keeping a selection of past
> > releases available and maintained for a longer period of time (LTS).
> >
> > There was agreement in the room that this could be accomplished by
> > moving the responsibility for those releases from the Stable Branch
> > team down to those who are already creating and testing patches for
> > old releases: The distros, deployers, and operators.
> >
> > The concept, in general, is to create a new set of cores from these
> > groups, and use 3rd party CI to validate patches. There are lots of
> > details to be worked out yet, but our amazing UC (User Committee) will
> > be begin working out the details.
> >
> > Please take a look at the Etherpad from the session if you'd like to
> > see the details. More importantly, if you would like to contribute to
> > this effort, please add your name to the list starting on line 133.
> >
> > https://etherpad.openstack.org/p/SYD-forum-upstream-lts-releases
> >
> > Thanks to everyone who participated!
> >
> > Cheers,
> > Erik
> >
> > _______________________________________________
> > OpenStack-operators mailing list
> > OpenStack-operators at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 
> I'm not a fan of the current proposal. I feel like the discussion jumped into a policy/procedure solution without getting much more feedback from operators. The room heard "ops want LTS" and we now have a new governance model to work out.
> 
> What I heard from ops in the room is that they want (to start) one release a year who's branch isn't deleted after a year. What if that's exactly what we did? I propose that OpenStack only do one release a year instead of two. We still keep N-2 stable releases around. We still do backports to all open stable branches. We still do all the things we're doing now, we just do it once a year instead of twice.

We have so far only been able to find people to maintain stable
branches for 12-18 months. Keeping N-2 branches for annual releases
open would mean extending that support period to 2+ years. So, if
we're going to do that, we need to address the fact that we haven't
been able to retain anyone's attention that long up to this point.
Do you think keeping the branches open longer will be sufficient
to attract contributors to actually work on them?

> 
> Looking at current deliverables in the openstack releases repo, most (by nearly a factor of 2x) are using "cycle-with-intermediary".
> 
>     john at europa:~/Documents/openstack_releases/deliverables/pike(master)$ grep release-model * | cut -d ':' -f 2- | sort | uniq -c
>       44 release-model: cycle-trailing
>      147 release-model: cycle-with-intermediary
>       37 release-model: cycle-with-milestones
>        2 release-model: untagged
> 
> Any deliverable that using this model is already successfully dealing with skip-level upgrades. Skip-level upgrades are already identified as needed and prioritized functionality in projects that don't yet support them. Let's keep working on getting that functionality supported across all OpenStack deliverables. Let's move to one LTS release a year. And let's get all project deliverables to start using cycle-with-intermediary releases.

Most of those deliverables are libraries. I see 16 services released
under pike as cycle-with-intermediary (there are 20 using
cycle-with-milestones).

$ cd openstack/releases
$ tox -e venv -- list-deliverables -v --series pike --type service --model cycle-with-intermediary
aodh                           Telemetry            5.0.0
ceilometer                     Telemetry            9.0.1
cloudkitty                     cloudkitty           6.0.0
ironic                         ironic               9.1.2
karbor                         karbor               0.5.1
magnum                         magnum               5.0.1
monasca-api                    monasca              2.2.0
monasca-log-api                monasca              2.3.0
panko                          Telemetry            3.0.0
solum                          solum                5.4.0
swift                          swift                2.15.1
tacker                         tacker               0.8.0
tricircle                      tricircle            4.0.0
vitrage                        vitrage              1.8.2
watcher                        watcher              1.4.1
zun                            zun                  0.2.1

Of the cycle-with-intermediary deliverables, only 3 (ceilometer,
ironic, and swift) even claim the assert:supports-upgrade tag [1]
(our simplest upgrade tag, which indicates support for "cold" offline
upgrades).  I would be interested to hear from the other project
teams about why they aren't claiming to support upgrades at all.

It will take a little more analysis to tell whether any of those
deliverables released multiple feature releases within the pike
cycle. Most have at least 2 releases, but at first glance it looks
like they are bug fixes from after the final release date, and my
recollection is that no one prepared multiple feature releases --
to the point that we have been actively encouraging projects to
change their release model to reflect what they actually do.

It would also be interesting to hear from someone about whether
skip-level or fast-forward upgrades are actually supported by any
of the projects listed above. I don't think it's safe to assume
anything about upgrade support based solely on the release model,
since those deliverables still only maintain a single stable branch
per cycle.

Doug

[1] https://governance.openstack.org/tc/reference/tags/assert_supports-upgrade.html