Open Stack

On Wed, Apr 22, 2015 at 12:30 PM, Kyle Mestery <mestery at mestery.com> wrote:

> On Wed, Apr 22, 2015 at 1:19 PM, Russell Bryant <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
>>
>
I think the phrase 'vast majority' is misleading, there are still a lot of
projects on stackforge.


> 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
>>
>
Saying something is your first choice isn't a real benefit.  It is implying
some sort of benefit but I cannot define what the benefit actually is.


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

So you are adding what sounds like a fairly non-trivial amount of work to
the role of Neutron PTL. Can the role of Neutron PTL take on more work?
Making the life of the PTL harder doesn't sound like a step in the right
direction.



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

What is the limiting factor here? Doesn't each backend need its own team
anyway? How does this scaling bottle neck go away under a)?


>
>
>> 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.
>>
>>
While I am a big fan of reducing duplicated work, I am not sure what we
gain from 'consistency' here. What problem does it solve?


If I had a vote on this (which I don't think I do) I would choose b.



> 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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150429/dc83af91/attachment.html>