On Nov 18, 2014, at 5:31 PM, Mark McClain <m...@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 building out layers 4 
> through 7.  Initially, we thought that development would float 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 have 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 the 
> 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 repository 
> would continue to be shared during the Kilo cycle.  The PTL and the drivers 
> team will retain approval responsibilities they now share. 
> - The split would occur around Kilo-1 (subject to coordination of the Infra 
> and Networking teams). The timing is designed to enable the proposed REST 
> changes to land around the time of the December development sprint.
> - The core team for each repository will be determined and proposed by Kyle 
> Mestery for approval by the current core team.
> - The Neutron Server and the Neutron Adv Services Library would be co-gated 
> 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 during 
> testing.
> - The split should not adversely impact operators and the Networking program 
> 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] 
> https://git.openstack.org/cgit/openstack/governance/plain/reference/programs.yaml
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

There would not be a service or REST API associated with the Advanced Services 
code base? Would the REST API to talk to those services be part of the Neutron 

OpenStack-dev mailing list

Reply via email to