[Openstack-operators] [openstack-dev] Upstream LTS Releases
doug at doughellmann.com
Fri Nov 10 18:11:45 UTC 2017
Excerpts from Clint Byrum's message of 2017-11-08 23:15:15 -0800:
> Excerpts from Samuel Cassiba's message of 2017-11-08 08:27:12 -0800:
> > On Tue, Nov 7, 2017 at 3:28 PM, Erik McCormick
> > <emccormick at cirrusseven.com> 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 Development Mailing List (not for usage questions)
> > > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > In advance, pardon the defensive tone. I was not in a position to
> > attend, or even be in Sydney. However, as this comes across the ML, I
> > can't help but get the impression this effort would be forcing more
> > work on already stretched teams, ie. deployment-focused development
> > teams already under a crunch as contributor count continues to decline
> > in favor of other projects inside and out of OpenStack.
> I suspect if LTS's become a normal part of OpenStack, most deployment
> projects will decline to support the interim releases. We can infer this
> from the way Ubuntu is used. This might actually be a good thing for the
> chef OpenStack community. 3 out of 3.5 of you can focus on the LTS bits,
> and the 0.5 person can do some best effort to cover the weird corner
> case of "previous stable release to master".
> The biggest challenge will be ensuring that the skip-level upgrades
> work. The current grenade based upgrade jobs are already quite a bear to
> keep working IIRC. I've not seen if chef or any of the deployment projects
> test upgrades like that.
> However, if people can stop caring much about the interim releases and
> just keep "previous LTS to master" upgrades working, then that might be
> good for casual adoption.
> Personally I'd rather we make it easier to run "rolling release"
> OpenStack. Maybe we can do that if we stop cutting stable releases every
> 6 months.
We should stop calling what we're talking about "LTS". It isn't
going to match the expectations of anyone receiving LTS releases
for other products, at least at first. Perhaps "Deployer Supported"
or "User Supported" are better terms for what we're talking about.
In the "LTS" room we did not agree to stop cutting stable releases
or to start supporting upgrades directly from N-2 (or older) to N.
Both of those changes would require modifying the support the
existing contributor base has committed to provide.
Fast-forward upgrades will still need to run the migration steps
of each release in order, one at a time. The team working on that
is going to produce a document describing what works today so we
can analyze it for ways to improve the upgrade experience, for both
fast-forward and "regular" upgrades. That was all discussed in a
More information about the OpenStack-operators