On Tue, Nov 18, 2014 at 5:36 PM, Armando M. <arma...@gmail.com> wrote: > Mark, Kyle, > > What is the strategy for tracking the progress and all the details about > this initiative? Blueprint spec, wiki page, or something else? > We're in the process of writing a spec for this now, but we first wanted community feedback. Also, it's on the TC agenda for next week I believe, so once we get signoff from the TC, we'll propose the spec.
Thanks, Kyle > 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 <do...@a10networks.com> 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 <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 >> >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
