Open Stack

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

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 Bryant