Open Stack

> On Nov 30, 2015, at 9:11 PM, 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).

From the perspective of our users, I tend to consider neutron-lbaas and octavia as a unit, technical distinctions aside.

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

Part of the issue is that in a year, we added all the repos above. And all of said repos were all  heading over to infra with the same newbie questions/mistakes. Not a bad thing in and of itself, but the sheer volume was causing a lot of infra load. So the infra liasions are meant to buffer that; exactly the opposite of splitting again. Now add that many repos again this year, and the problem doubles.

The review overhead for centralizing this is quite small. The mentor overhead to avoid the repeated mistakes hitting infra is quite a bit higher, but that has to land somewhere, and still isn’t huge.

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

I believe this is where the lieutenant system is supposed to help?

> 
>> 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
> 
> __________________________________________________________________________
> 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