Mark, Kyle, What is the strategy for tracking the progress and all the details about this initiative? Blueprint spec, wiki page, or something else?
One thing I personally found useful about the spec approach adopted in [1], was that we could quickly and effectively incorporate community feedback; having said that I am not sure that the same approach makes sense here, hence the question. Also, what happens for experimental efforts that are neither L2-3 nor L4-7 (e.g. TaaS or NFV related ones?), but they may still benefit from this decomposition (as it promotes better separation of responsibilities)? Where would they live? I am not sure we made any particular progress of the incubator project idea that was floated a while back. Cheers, Armando [1] https://review.openstack.org/#/c/134680/ On 18 November 2014 15:32, Doug Wiegley <[email protected]> wrote: > Hi, > > > 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? > > Thanks, > doug > > > > On Nov 18, 2014, at 10:31 PM, Mark McClain <[email protected]> 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
