On 11/19/14, 5:02 PM, "Kyle Mestery" <mest...@mestery.com> wrote:
>On Tue, Nov 18, 2014 at 5:32 PM, 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? >> >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 > >Thanks, >Kyle > >> 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/progr >>ams.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