Open Stack

Excerpts from Drew Fisher's message of 2017-05-03 14:00:53 -0600:
> This email is meant to be the ML discussion of a question I brought up
> during the TC meeting on April 25th.; [1]

Thanks for starting this thread, Drew. I'll try to respond, but I
know a lot of folks are preparing for the summit next week, so it
may be a little quiet around here until after everyone is home.

> 
> The TL;DR version is:
> 
> 
> Reading the user survey [2], I see the same issues time and time again.
> Pages 18-19 of the survey are especially common points.

I was also interested in those comments and noticed that, as you
say, some are recurring themes. That reinforces in my mind that we
haven't adequately communicated the background behind some decisions
we've made in the past, or what we would need to do to make progress
on stalled initiatives.  I've started trying to address some of
those issues [1], and I'll be continuing that work after the summit.

[1] https://doughellmann.com/blog/2017/04/20/lessons-learned-from-working-on-large-scale-cross-project-initiatives-in-openstack/

> Things move too fast,

I have to say, after so many years of hearing that we weren't moving
fast enough this one was a big surprise. :-) I'm not sure if that's
good or bad, or if it just means we now have a completely different
set of people responding to the user survey.

> no LTS release,

Over the past couple of years we have shifted the majority of the
backport review work off of a centralized team so that the individual
project teams are responsible for establishing their own stable
review groups. We've also changed the way we handle stable releases,
so that we now encourage projects to tag a release when they need
it instead of waiting and trying to tag all of the projects together
at the same time. As a result of these changes, we've been seeing
more stable releases for the branches we do maintain, giving users
more actual bug fix releases for those series.

That said, there are two main reasons we are unlikely to add more
stable releases or maintain any releases for longer: we need more
people to do the work, and we need to find a way to do that work
that doesn't hurt our ability to work on master.

We do still have a stable team responsible for ensuring that projects
are following the policies for stable releases, and that team needs
more participation. I'm sure the project teams would appreciate
having more help with backports and reviews on their stable branches,
too. Getting contributors to work on those tasks has been difficult
since the very beginning of the project.

It has been difficult to attract contributors to this area in part
due to the scope of work that is necessary to say that the community
supports those releases. We need the older versions of the deployment
platforms available in our CI systems to run the automated tests.
We need supported versions of the development tools (setuptools and
pip are especially problemmatic).  We need supported versions of
the various libraries and system-level dependencies like libvirt.
I'm sure the stable maintenance team could add to that list, but
the point is that it's not just a matter of saying we want to do
it, or even that we *will* do it.

> upgrades are terrifying for anything that isn't N-1 -> N.

The OpenStack community has a strong culture of testing.  We have
reasonable testing in place to balance our ability to ensure that
N-1 -> N upgrades work and as a result upgrades are easier than
ever. It seems quite a few users are still on the older versions
of the software that don't have some of those improvements.  It's
not the ideal answer, but their experience will continue to improve
as they move forward onto newer releases.

Meanwhile, adding more combinations of upgrades to handle N-M -> N
changes our ability to simplify the applications by removing technical
debt and by deprecating configuration options (reducing complexity
by cutting the number of configuration options has also been a
long-standing request from users). It also means more people are
needed to keep those older releases running in CI, so that the
upgrade jobs are reliable (see the discussion above about why that
is an issue).

> These come up time and time again
> How is the TC working with the dev teams to address these critical issues?
> 
> I asked this because on page 18 is this comment:
> 
> "Most large customers move slowly and thus are running older versions,
> which are EOL upstream sometimes before they even deploy them."
> 
> This is exactly what we're seeing with some of our customers and I
> wanted to ask the TC about it.

The contributors to OpenStack are not a free labor pool for the
consumers of the project. Just like with any other open source
project, the work is done by the people who show up, and we're all
motivated to work on different things.  Many (most?) of us are paid
by companies selling products or services based on OpenStack. Those
companies apply resources, in the form of contributor time and
attention, based on their users' needs.  The TC and other community
leaders have tried to respond to that particular source of contributor
motivation while still honoring contributions of all forms by
organizing the project to enable *all* contributors to achieve their
goals, regardless of whether they are working for a "vendor" of
some sort, or are a user building their own packages and relying
on the community for support.  Having done both while I've been
active with OpenStack, I can honestly say that the best way to get
what you want is to participate in creating it.  If there were
people trying to do this work, I expect that we would find a way
to make it possible.

For anyone interested in contributing to stable release maintenance,
the best course of action is to get involved with the team responsible
for organizing that work to learn our current processes and policies.
When that team grows large enough that it's clear we can sustain
more stable releases or upgrade combinations, the people involved
will have a clear enough understanding of the problem space that
they will be able to design the necessary policy and process changes.

Doug

> 
> Thanks,
> 
> -Drew
> 
> 
> 
> 
> [1]
> http://eavesdrop.openstack.org/meetings/tc/2017/tc.2017-04-25-20.00.log.html#l-177
> [2] https://www.openstack.org/assets/survey/April2017SurveyReport.pdf
>