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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
