[openstack-dev] [Neutron] Evolving the stadium concept

Armando M. armamig at gmail.com
Tue Dec 1 00:56:39 UTC 2015

Hi folks,

The stadium concept was introduced more or less formally since April of
this year. At the time it was introduced (see [1]), the list of
deliverables included neutron, client, specs and *-aas services. As you may
be well aware, 6+ months is a long time in the OpenStack world, and lots of
things happened since then. The list has grown to [2].

When I think about what 'deliverables' are, I am inclined to think that all
of the projects that are part of the list will have to behave and follow
the same rules, provided that there is flexibility given by the tags. However,
reality has proven us that rules are somewhat difficult to follow and
enforce, and some boundaries may be too strict for some initiatives to
comply with. This is especially true if we go from a handful of projects
that we had when this had started to the nearly the two dozens we have now.

As a result, there is quite an effort imposed on the PTL, the various
liaisons (release, infra, docs, testing, etc) and the core team to help
manage the existing relationships and to ensure that the picture stays
coherent over time. Sometimes the decision of being part of this list is
even presented before one can see any code, and that defeats the whole
point of the deliverable association. I have experienced first hand that
this has become a burden, and I fear that the stadium might be an extra
layer of governance/complexity that could even interfere with the existing
responsibilities of the TC and of OpenStack infra.

So my question is: would revisiting/clarifying the concept be due after
some time we have seen it in action? I would like to think so. To be fair,
I am not sure what the right answer is, but I know for a fact that some
iterations are in order, and I like to make a proposal:

I would like to suggest that we evolve the structure of the Neutron
governance, so that most of the deliverables that are now part of the
Neutron stadium become standalone projects that are entirely self-governed
(they have their own core/release teams, etc). In order to denote the
initiatives that are related to Neutron I would like to present two new
tags that projects can choose to label themselves with:

   - 'is-neutron-subsystem': this means that the project provides
   networking services by implementing an integral part (or parts) of an
   end-to-end neutron system. Examples are: a service plugin, an ML2 mech
   driver, a monolithic plugin, an agent etc. It's something an admin has to
   use in order to deploy Neutron in a certain configuration.
   - 'use-neutron-system': this means that the project provides networking
   services by using a pre-deployed end-to-end neutron system as is. No
   modifications whatsoever.

As a result, there is no oversight by the Neutron core team, the PTL or
liasons, but that should not stop people from being involved if they choose
to. We would not lose the important piece of information which is the
association to Neutron, and at the same time that would relieve some of us
from the onus of dealing with initiatives for which we lack enough context
and ability of providing effective guidance.

In the process, the core team should stay focused on breaking the coupling
that still affects Neutron so that projects that depend on it can do so
more reliably, and yet innovate more independently. If that means
revisiting the Neutron's mission statement, we can discuss that too.

I am sure this hardly covers all the questions you may have at this point,
but I would like to take the opportunity to start the conversation to see
where people stand. Whichever the outcome, I think that we should strive
for decentralizing responsibilities as much as we can in order to be
scalable as a project and I think that the current arrangement prevents us
from doing that.

Thanks for reading.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151130/f84e9274/attachment.html>

More information about the OpenStack-dev mailing list