Open Stack

+1

I was in the middle of writing an email asking about the possibility of splitting out the reference implementation. you beat me to it. :)

I also like the idea of having the PTL on top to help pass up/down ideas where code can be shared, benefiting everyone.

Thanks,
Kevin
________________________________
From: Kyle Mestery [mestery at mestery.com]
Sent: Wednesday, April 22, 2015 12:30 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

On Wed, Apr 22, 2015 at 1:19 PM, Russell Bryant <rbryant at redhat.com<mailto:rbryant at redhat.com>> wrote:
Hello!

A couple of things I've been working on lately are project governance
issues as a TC member and also implementation of a new virtual
networking alternative with a Neutron driver.  So, naturally I started
thinking about how the Neutron driver code fits in to OpenStack governance.

Thanks for starting this conversation Russell.

There are basically two areas with a lot of movement related to this issue.

1) Project governance has moved to a "big tent" model [1].  The vast
majority of projects that used to be in Stackforge are being folded in
to a larger definition of the OpenStack project.  Projects making this
move meet the following criteria as being "one of us":

http://governance.openstack.org/reference/new-projects-requirements.html

Official project teams are tracked in this file along with the git repos
they are responsible for:

http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml

which is also reflected here:

http://governance.openstack.org/reference/projects/

The TC has also been working through defining a system to help
differentiate efforts by using a set of "tags" [4].  So far, we have
tags describing the release handling for a repository, as well as a tag
for team diversity.  We've also had a lot of discussion about tags to
help describe maturity, but that is still a work in progress.


2) In Neutron, some fairly significant good changes are being made to
help scale the development process.  Advanced services were split out
into their own repos [2].  Most of the plugin and driver code has also
been split out into repos [3].

In terms of project teams, the Neutron team is defined as owning the
following repos:

  http://governance.openstack.org/reference/projects/neutron.html

 - openstack/neutron
 - openstack/neutron-fwaas
 - openstack/neutron-lbaas
 - openstack/neutron-vpnaas
 - openstack/neutron-specs
 - openstack/python-neutronclient

The advanced services split is reflected by the fwaas, lbaas, and vpnaas
repos.

We also have a large set of repositories related to Neutron backend code:

  http://git.openstack.org/cgit/?q=stackforge%2Fnetworking

 - stackforge/networking-arista
 - stackforge/networking-bagpipe-l2
 - stackforge/networking-bgpvpn
 - stackforge/networking-bigswitch
 - stackforge/networking-brocade
 - stackforge/networking-cisco
 - stackforge/networking-edge-vpn
 - stackforge/networking-hyperv
 - stackforge/networking-ibm
 - stackforge/networking-l2gw
 - stackforge/networking-midonet
 - stackforge/networking-mlnx
 - stackforge/networking-nec
 - stackforge/networking-odl
 - stackforge/networking-ofagent
 - stackforge/networking-ovn
 - stackforge/networking-ovs-dpdk
 - stackforge/networking-plumgrid
 - stackforge/networking-portforwarding
 - stackforge/networking-vsphere

Note that not all of these are equivalent.  This is just a list of
stackforge/networking-*.

In some cases there is a split between code in the Neutron tree and in
this repo.  In those cases, a shim is in the Neutron tree, but most of
the code is in the external repo.  It's also possible to have all of the
code in the external repo.

There's also a big range of maturity.  Some are quite mature and are
already used in production.  networking-ovn as an example is quite new
and being developed in parallel with OVN in the Open vSwitch project.


So, my question is: Where should these repositories live in terms of
OpenStack governance and project teams?

Here are a few paths I think we could take, along with some of my
initial thoughts on pros/cons.

a) Adopt these as repositories under the Neutron project team.

In this case, I would see them operating with their own review teams as
they do today to avoid imposing additional load on the neutron-core or
neutron-specs-core teams.  However, by being a part of the Neutron team,
the backend team would submit to oversight by the Neutron PTL.

Out of your options proposed, this seems like the most logical one to me. I don't really see this imposing a ton of strain on the existing core reviewer team, because we'll keep whatever core reviewer teams are already in the networking-foo projects.

There are some other details to work out to ensure expectations are
clearly set for everyone involved.  If this is the path that makes
sense, we can work through those as a next step.

Pros:
 + Seems to be the most natural first choice

Cons:
 - A lot of changes have been made precisely because Neutron has gotten
so big.  A single project team/PTL may not be able to effectively
coordinate all of the additional work.  Maybe the core Neutron project
would be better off focusing on being a platform, and other project
teams organize work on backends.

It's interesting you mention neutron "being a platform", because that's exactly where I want it to go in Liberty as well. To that end, I expect to propose a spec splitting out the reference implementation into a separate git repository under the neutron namespace. This will make Neutron an API/DB layer, which is what it should be. It also means the existing reference implementation is on equal footing with things like OVN, ofagent, midonet, OpenDaylight, OpenContrail, and OpenCarrierPigeon [1].

One thing which is worth bringing up in this context is the potential overlap between this implementations. I think having them all under the Neutron project would allow me as PTL and the rest of the team work to combine things when it makes sense.

Kyle

[1] http://www.faqs.org/rfcs/rfc1149.html

b) Let each interested group define a new project team for their backend
code.

To be honest, I don't this is a scalable option. I'm involved with 2 of these networking-foo projects, and there is not enough participation so far to warrant an entirely new project, PTL and infra around it. This is just my opinion, but it's an opinion I've taken after having contributed to networking-odl and networking-ovn for the past 5 months.

So, as an example, the group of people working on Neutron integration
with OpenDaylight could propose a new project team that would be a
projects.yaml entry that looks something like:

Neutron-OpenDaylight:
  ptl: Some Person (ircnick)
  service: OpenDaylight Networking
  mission: >
    To implement Neutron support for the OpenDaylight project.
  url: ...
  projects:
    - repo: openstack/networking-odl

Pros:
 + There's no additional load on the Neutron project team and PTL.

Cons:
 - Having all of these efforts organized under a single project team and
PTL might be better for ensuring some level of collaboration and
consistency.

c) A single new project team could be created that is led by a single
person to coordinate the sub-teams working on each repo.  In this
scenario, I could see the overall collaboration being around ensuring
consistent approaches to development process, testing, documentation,
and releases.

That would be something like this (note that the project list would be
limited to those who actually want to be included in the official
project team and meet some set of inclusion criteria).

Neutron-Backends:
  ptl: Some Person (ircnick)
  service: Networking Backends
  mission: >
    To implement Neutron backend support for various networking
    technologies.
  url: ...
  projects:
    - openstack/networking-arista
    - openstack/networking-bagpipe-l2
    - openstack/networking-bgpvpn
    - openstack/networking-bigswitch
    - openstack/networking-brocade
    - openstack/networking-cisco
    - openstack/networking-edge-vpn
    - openstack/networking-hyperv
    - openstack/networking-ibm
    - openstack/networking-l2gw
    - openstack/networking-midonet
    - openstack/networking-mlnx
    - openstack/networking-nec
    - openstack/networking-odl
    - openstack/networking-ofagent
    - openstack/networking-ovn
    - openstack/networking-ovs-dpdk
    - openstack/networking-plumgrid
    - openstack/networking-portforwarding
    - openstack/networking-vsphere

Pros:
 + There's no additional load on the Neutron project team and PTL.
 + Avoids a proliferation of new project teams for each Neutron backend.
 + Puts efforts under a single team and PTL to help facilitate
collaboration and consistency.

Cons:
 - Some might see this as an unnatural split from Neutron.
 - The same sort of oversight and coordination could potentially happen
with a delegate of the Neutron PTL in the Neutron project team without
making it separate.

d) I suppose the last option is to declare that none of these repos make
sense as an OpenStack project.  It's hard for me to imagine this making
sense except for cases where the teams don't want their work to be
officially included in OpenStack, or they fail to meet our base set of
project guidelines.


What option do you think makes sense?  Or is there another option that
should be considered?


[1] http://www.openstack.org/blog/2015/02/tc-update-project-reform-progress/
[2]
http://specs.openstack.org/openstack/neutron-specs/specs/kilo/services-split.html
[3]
http://specs.openstack.org/openstack/neutron-specs/specs/kilo/core-vendor-decomposition.html
[4] http://governance.openstack.org/reference/tags/

--
Russell Bryant

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150422/05d8470c/attachment.html>