Open Stack

Excerpts from Dean Troyer's message of 2017-02-16 08:25:42 -0600:
> On Thu, Feb 16, 2017 at 7:54 AM, Ian Cordasco <sigmavirus24 at gmail.com> wrote:
> > It seems like a lot of people view "developing OpenStack" as more
> > attractive than "making it easy to deploy OpenStack" (via the
> > deployment tools in the tent). Doing both is really something project
> > teams should do, but I don't think shoving all of the deployment
> > tooling in repo makes that any better frankly. If we put our tooling
> > in repo, we'll likely then start collecting RPM/Debian/etc. packaging
> > in repo as well.
> 
> Part of it _is_ the "deployment isn't shiny/new/features", but there
> is also the historical view lingering that we ship tarballs (and
> realistically, git repo tags) so as not to pick favorites and to keep
> deployment and packaging out of the project repos directly.
> 
> We have >5 different tools that are "mainstream" to consider, not even
> the large project teams have enough expertise to maintain those.  I
> had a hard enough time myself keeping both rpm and apt up to date in
> previous projects, much less recipies, playbooks and the odd shell
> script.
> 
> It is also hard to come in to a community and demand that other
> projects suddenly have to support your project just because you showed
> up.  (This works both ways, when we add a "Big Tent" project, now all
> of the downstreams are expected to suddenly add it.)
> 
> The solution I see is to have a mechanism by which important things
> can be communicated from the project developers that can be consumed
> by the packager/deployer community.  Today, however sub-optimal it
> seems to be, that is release notes.  Maybe adding a specific section
> for packaging would be helpful, but in practice that adds one more
> thing to remember to write to a list that is already hard to get devs
> to do.
> 
> Ad Doug mentions elsewhere in this thread, the liaison approach has
> worked in other areas, it may be a useful approach here.  But I know
> as the PTL of a very small project I do not want 5 more hats to wear.
> Maybe one.
> 
> We have encouraged the packaging groups to work together in the past,
> with mixed results, but it seems to me that a lot of the things that
> need to be discovered and learned in new releases will be similar for
> all of the downstream consumers.  Maybe if that downstream community
> could reach a critical mass and suggest a single common way to
> communicate the deployment considerations in a release it would get
> more traction.  And a single project liaison for the collective rather
> than one for each deployment project.

I like the idea of at least standardizing the communication. I agree, we
don't want 5+ new liaison responsibilities, especially for small teams.

> > I think what would help improve willing bidirectional communication
> > between service and deployment/packaging teams would be an
> > understanding that without the deployment/packaging teams, the service
> > teams will likely be out of a job. People will/can not deploy
> > OpenStack without the tooling these other teams provide.
> 
> True in a literal sense.  This is also true for our users, without
> them nobody will deploy a cloud in the first place.  That has not
> changed anything unfortunately, we still regularly give our users
> miserable experiences because it is too much effort to participate
> with the (now comatose) UX team or prioritize making a common log
> format or reduce the number of knobs available to twiddle to make each
> cloud a unique snowflake.
> 
> We can not sustain being all things to all people.  Given the
> contraction of investment being considered and implemented by many of
> our foundation member companies, we will have to make some hard
> decisions about where to spend the resources we have left.  Some of
> those decision are made for us by those member companies promoting
> their own priorities (your example of Ansible contributions is one).
> But as a community we have an opportunity to express our desires and
> potentially influence those decisions.

When we signed off on the Big Tent changes we said competition
between projects was desirable, and that deployers and contributors
would make choices based on the work being done in those competing
projects. Basically, the market would decide on the "optimal"
solution. It's a hard message to hear, but that seems to be what
is happening.

We also said that that cross-project efforts needed to decide what
amount of work they could manage themselves and then empower project
teams to take on the responsibility for everything else. We need
to build tools and write documentation to make it as easy as possible
to contribute, and then be OK with the state of the world if we
don't have 100% coverage of all projects with all deployment tools
or install guides or whatever else falls into that cross-project
category.  We want to have perfect parity everywhere, but everything
is evolving continuously, so that hardly seems realistic. Our goal
should be to set things up so that if someone fills in a gap, there
is an obvious way for them to do that upstream to encourage them
to open the work instead of keeping it behind closed doors.

As far as the shift in contributor resources goes, we need to start
looking to users to become contributors more than we have in the
past.  Historically, most of our contributors have been sponsored
by vendors. That has allowed us to put into place policies and
practices that make it harder for regular users to become more
casual contributors. Whether that's a governance policy like the
CLA, the community culture of preferring "complete" patches with
docs and good test coverage all together over incremental improvement
and patch series, if we want to ensure the long-term health of the
entire community I think it's time to take a hard look at the
decisions we've made in the past and that we take for granted.

Doug