Open Stack

On Thu, Apr 23, 2015 at 3:30 AM, 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
>> 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].
>

Could you please also pay some attention on Cons of this ultimate
splitting Kyle? I'm afraid it would hurt the user experiences.

On the position of Dev, A naked Neutron without "official" built-in
reference implementation probably has a more clear architecture. On
the other side, users would be forced to make choice between a long
list of backend implementations, which is very difficult for
non-professionals.

In most of the time, users need a off-the-shelf solution without
paying much extra integration effort, and they have less interest to
study which SDN controller is powerful and is better than others. Can
we imagine Nova without KVM/Qemu virt driver, Cinder without Ceph/VKM
volume driver [See Deployment Profiles section in 1a] ? Shall we
really decide to make Neutron the only Openstack project which has not
any in tree official implementation?

[1a] http://superuser.openstack.org/articles/openstack-user-survey-insights-november-2014

Here is my personal suggestion: decomposition decision needs some
trade-off, remaining 2-3 mainstream opensource backends  in tree [ML2
with OVS&LB, based on the survey result of 1a above]. While we are
progressing radically with architecture re-factoring, smooth
experience and easy to adoption should also be cared.

>
> 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://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
>