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