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

Armando M. armamig at gmail.com
Tue Dec 1 07:10:18 UTC 2015


On 30 November 2015 at 20:11, Russell Bryant <rbryant at redhat.com> wrote:

> Some additional context: there are a few proposals for additional git
> repositories for Neutron that have been put on hold while we sort this out.
>
> Add networking-bagpipe:
>   https://review.openstack.org/#/c/244736/
>
> Add the Astara driver:
>   https://review.openstack.org/#/c/230699/
>
> Add tap-as-a-service:
>   https://review.openstack.org/#/c/229869/
>
> On 11/30/2015 07:56 PM, Armando M. wrote:
> > 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.
>
> I just want to clarify the proposal.  IIUC, you propose splitting most
> of what is currently separately deliverables of the Neutron team and
> making them separate projects in terms of OpenStack governance.  When I
> originally proposed including networking-ovn under Neutron (and more
> generally, making room for all drivers to be included), making them
> separate projects was one of the options on the table, but it didn't
> seem best at the time.  For reference, that thread was here:
>
> http://lists.openstack.org/pipermail/openstack-dev/2015-April/062310.html
>
> When I was originally proposing this, I was only thinking about Neutron
> drivers, the stuff that connects Neutron to some other system to make
> Neutron do something.  The list has grown to include other things, as well.
>
> I'm not sure where you propose the line to be, but for the sake of
> discussion, let's assume every deliverable in the governance definition
> for Neutron is under consideration for being split out with the
> exception of neutron, neutron-specs, and python-neutronclient.  The
> remaining deliverables are:
>
>     dragonflow:
>     kuryr:
>     networking-ale-omniswitch:
>     networking-arista:
>     networking-bgpvpn:
>     networking-calico:
>     networking-cisco:
>     networking-fortinet:
>     networking-hpe:
>     networking-hyperv:
>     networking-infoblox:
>     networking-fujitsu:
>     networking-l2gw:
>     networking-lenovo:
>     networking-midonet:
>     networking-odl:
>     networking-ofagent:
>     networking-onos:
>     networking-ovn:
>     networking-plumgrid:
>     networking-powervm:
>     networking-sfc:
>     networking-vsphere:
>     octavia:
>     python-neutron-pd-driver:
>     vmware-nsx:
>
> I think it's helpful to break these into categories, because the answer
> may be different for each group.  Here's my attempt at breaking this
> list into some categories:
>
> 1) A consumer of Neutron
>
>     kuryr
>
> IIUC, kuryr is a consumer of Neutron.  Its interaction with Neutron is
> via using Neutron's REST APIs.  You could think of kuryr's use of
> Neutron as architecturally similar to how Nova uses Neutron.
>
> I think this project makes a ton of sense to become independent.
>
> 2) Implementation of a networking technology
>
>     dragonflow
>
> The dragonflow repo includes a couple of things.  It includes dragonflow
> itself, and the Neutron driver to connect to it.  Using Astara as an
> example to follow, dragonflow itself could be an independent project.
>
> Following that, the built-in ML2/ovs or ML2/lb control plane could be
> separate, too, though that's much more painful and complex in practice.
>
>     octavia
>
> Octavia also seems to fall into this category, just for LBaaS.  It's not
> just a driver, it's a LBaaS service VM orchestrator (which is in part
> what Astara is, too).
>
> It seems reasonable to propose these as independent projects.
>
> 3) New APIs
>
> There are some repos that are implementing new REST APIs for Neutron.
> They're independent enough to need their own driver layer, but coupled
> with Neutron enough to still need to run inside of Neutron as they can't
> do everything they need to do by only interfacing with Neutron REST APIs
> (today, at least).
>
>     networking-l2gw:
>     networking-sfc:
>
> Here things start to get less clear to me.  Unless the only interaction
> with Neutron is via its REST API, then it seems like it should be part
> of Neutron.  Put another way, if the API runs as a part of the
> neutron-server process, it should be considered part of Neutron if it
> exists at all.
>
> 4) Neutron plugins/drivers
>

Even plugins and drivers can implement their own API's, so I don't see
distinction between 3 and 4, and even 2. That's why I only see two
categories: consumers and implementers.


> This is the biggest category.  It's all the glue code for connecting
> Neutron to other pieces of software/hardware that implement some piece
> of networking.
>
>     networking-ale-omniswitch:
>     networking-arista:
>     networking-bgpvpn:
>     networking-calico:
>     networking-cisco:
>     networking-fortinet:
>     networking-hpe:
>     networking-hyperv:
>     networking-infoblox:
>     networking-fujitsu:
>     networking-lenovo:
>     networking-midonet:
>     networking-odl:
>     networking-ofagent:
>     networking-onos:
>     networking-ovn:
>     networking-plumgrid:
>     networking-powervm:
>     networking-vsphere:
>     python-neutron-pd-driver:
>     vmware-nsx:'
>
> I haven't gone and looked at every one of these in detail, so maybe
> there's another category here.  In any case, for those that fit this
> category, it seems most natural to consider these part of Neutron.  They
> are completely useless without Neutron, and Neutron is useless without
> code from this category.
>

Nova is useless without Glance or Swift, or Keystone and yet these are all
separate projects aren't they? I guess the definition of useful vs useless
can really vary by how you look at it.


>
>
> My alternate, modified proposal would be to:
>
> a) Clarify the line of what should be included in Neutron and what
> shouldn't be.  The categorization above is a straw man start.  In that,
> categories 1 and 2 could be split, but 3 and 4 would stay.
>

Why do you think inclusion is something to keep at all cost? What is
actually giving you that you couldn't live without? Isn't being part of
OpenStack not enough?


>
> b) Break down what's actually causing pain and address it point by point.
>
> > 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.
>
> For example, you mention "release" here, though IIUC, Kyle is handling
> releases for all of these sub-projects, right?  If so, Kyle, what do you
> think?  What's causing pain and how can we improve?
>

Having to manage release and backports of every subproject in the stadium
is something that currently is in the hands of a single individual (kudos
to Kyle). This can be revised, and we can go back to delegating...but then
this means that everyone can and will behave differently, so I wonder:
what's the point of 'belonging'? Why having an inner circle within the
outer circle? I can't seem to justify why it's necessary. If you can
explain that to me in plain English, I would appreciate it very much.


>
> "infra" - I take it this is about the Neutron infra liaisons having to
> ack every infra patch for all of these repos.  That does sound annoying.
>  It'd be nice if the lead for each driver or whatever could act as the
> infra liaison for jobs that only affect that repo.
>

If infra changes relates to a neutron stadium project, infra folks expect
those to behave/look consistently, but reality is...they don't: every
project has its own needs. No single individual has the ability to oversee
the consistency of dozens of projects. If we arrange ourselves to being
loose then the consistency doesn't have to be preserved, but if it must,
then it becomes a lot of work, because there is no single pattern to be
followed, and the more patterns arise the more likely it is that pitfalls
show up.


>
> > 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.
>
> It makes sense to reject something if there's no code.  That's in line
> with how the TC has been evaluating new projects.
>
> > I have experienced first hand that this has become a burden,
>
> How about delegating this to the neutron-drivers team?  You already have
> a meeting with this group reviewing RFEs.  You could spread the load
> some more by letting others take a look and make a recommendation.
>

Delegating a broken process is hardly a good answer, is it? The burden
doesn't go away just by throwing more resources at the problem, but the
drivers team is already oversubscribed as it is, and we barely manage to
review a good enough number of RFEs per week.


>
> > 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.
>
> I'm not sure what this means.  Can you elaborate?
>
> For the TC, do you mean that Neutron is making in/out decisions that the
> TC should make?  That's probably true for certain categories (#1 above,
> especially, and maybe #2), but not for individual drivers, IMO at least.


My point in this particular regard is: I fail to understand why Neutron
(team, PTL, drivers, Lt's etc) have to make the in/out decision, be an
arbiter of taste and ruler of the whole. Let the individual projects make
their own decisions by expressing how they relate to Neutron, and how they
want to integrate with it, across the entire SDLC. They are the ones in the
best position to do so.




> At the end of the day, it's mostly a governance technicality.  I'm less
> concerned about what projects.yaml looks like and more concerned about
> what it implies about how our projects are operating.  I think projects
> should take more ownership and responsibility for their associated
> drivers.  No matter how limited the criteria and coordination is, it's
> better than none.  Let's tackle the pain points instead of just blowing
> the whole thing up.
>

I am not advocating of blowing anything thing up. I am proposing to tackle
the pain points by evolving the structure in a way that I think it better
reflects the current status and needs of the individual projects.

The governance technicality may have an impact on how the project operate
(that's the whole point of this discussion). Projects are made of people
and technology, but mostly people. Currently there's an imbalance to
sustain the relationship between Neutron and its subprojects. The more
effort Neutron has to put into dealing with process and governance, the
less focussed it can be on working on its core capabilities, and that's a
concern.

What are your concerns about this proposal that you have as Neutron core
developer, networking-ovn core developer, and TC member? Surely they can't
all be the same.

Thanks,
Armando


>
> --
> Russell Bryant
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151130/0d2960b5/attachment.html>


More information about the OpenStack-dev mailing list