[openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

Doug Wiegley dougw at a10networks.com
Thu Nov 20 21:30:16 UTC 2014

On 11/19/14, 5:02 PM, "Kyle Mestery" <mestery at mestery.com> wrote:

>On Tue, Nov 18, 2014 at 5:32 PM, Doug Wiegley <dougw at a10networks.com>
>> Hi,
>>> so the specs repository would continue to be shared during the Kilo
>> One of the reasons to split is that these two teams have different
>> priorities and velocities.  Wouldn’t that be easier to track/manage as
>> separate launchpad projects and specs repos, irrespective of who is
>> approving them?
>My thinking here is that the specs repo is shared (at least initialy)
>because the projects are under one umbrella, and we want them to work
>closely together initially. This keeps everyone in the loop. Once
>things mature, we can look at reevaluating this. Does that make sense?

Good by me.


>> Thanks,
>> doug
>> On Nov 18, 2014, at 10:31 PM, Mark McClain <mark at mcclain.xyz> wrote:
>> All-
>> Over the last several months, the members of the Networking Program have
>> been discussing ways to improve the management of our program.  When the
>> Quantum project was initially launched, we envisioned a combined service
>> that included all things network related.  This vision served us well
>>in the
>> early days as the team mostly focused on building out layers 2 and 3;
>> however, we’ve run into growth challenges as the project started
>> out layers 4 through 7.  Initially, we thought that development would
>> across all layers of the networking stack, but the reality is that the
>> development concentrates around either layer 2 and 3 or layers 4
>>through 7.
>> In the last few cycles, we’ve also discovered that these concentrations
>> different velocities and a single core team forces one to match the
>>other to
>> the detriment of the one forced to slow down.
>> Going forward we want to divide the Neutron repository into two separate
>> repositories lead by a common Networking PTL.  The current mission of
>> program will remain unchanged [1].  The split would be as follows:
>> Neutron (Layer 2 and 3)
>> - Provides REST service and technology agnostic abstractions for layer
>>2 and
>> layer 3 services.
>> Neutron Advanced Services Library (Layers 4 through 7)
>> - A python library which is co-released with Neutron
>> - The advance service library provides controllers that can be
>>configured to
>> manage the abstractions for layer 4 through 7 services.
>> Mechanics of the split:
>> - Both repositories are members of the same program, so the specs
>> would continue to be shared during the Kilo cycle.  The PTL and the
>> team will retain approval responsibilities they now share.
>> - The split would occur around Kilo-1 (subject to coordination of the
>> and Networking teams). The timing is designed to enable the proposed
>> changes to land around the time of the December development sprint.
>> - The core team for each repository will be determined and proposed by
>> Mestery for approval by the current core team.
>> - The Neutron Server and the Neutron Adv Services Library would be
>> to ensure that incompatibilities are not introduced.
>> - The Advance Service Library would be an optional dependency of
>>Neutron, so
>> integrated cross-project checks would not be required to enable it
>> testing.
>> - The split should not adversely impact operators and the Networking
>> should maintain standard OpenStack compatibility and deprecation cycles.
>> This proposal to divide into two repositories achieved a strong
>>consensus at
>> the recent Paris Design Summit and it does not conflict with the current
>> governance model or any proposals circulating as part of the ‘Big Tent’
>> discussion.
>> Kyle and mark
>> [1]
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org

More information about the OpenStack-dev mailing list