> so the specs repository would continue to be shared during the Kilo cycle.

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?


On Nov 18, 2014, at 10:31 PM, Mark McClain 
<m...@mcclain.xyz<mailto:m...@mcclain.xyz>> wrote:


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

Kyle and mark

OpenStack-dev mailing list

OpenStack-dev mailing list

Reply via email to