[openstack-dev] [Neutron] Evolving the stadium concept
brandon.logan at RACKSPACE.COM
Tue Dec 1 05:02:32 UTC 2015
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:
> Add the Astara driver:
> Add tap-as-a-service:
> 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:
> 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:
> 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
> 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
> 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 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).
> 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.
> 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.
More information about the OpenStack-dev