Open Stack

On Mon, 2015-11-30 at 23:11 -0500, Russell Bryant 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).

Actually I would put Octavia in #1 as it only interacts with neutron
through its REST API.  There is a neutron-lbaas octavia driver that
simply just calls the Octavia REST API, but it lives in the
neutron-lbaas tree.  Octavia is standalone and consumes all openstack
services through their REST APIs.

> 
> 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
> 
> 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.
> 
> 
> 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.
> 
> 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?
> 
> "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.
> 
> > 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.
> 
> > 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.
> 
> 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.
> 


Russell, what category would the neutron-*aas repos be under?  Seems to
me to be under #4 as well but I could see a case for #3.

As for the overall goal of all of this, I think its a very valid goal.
One PTL overseeing all of these obviously does not scale.  I'm sure most
have been governing independently anyway and only getting PTL
involvement on a limited basis.

Thanks,
Brandon