On Tue, Nov 18, 2014 at 4:44 PM, Mohammad Hanif <mha...@brocade.com> wrote: > I agree with Paul as advanced services go beyond just L4-L7. Today, VPNaaS > deals with L3 connectivity but belongs in advanced services. Where does > Edge-VPN work belong? We need a broader definition for advanced services > area. >
So the following definition is being proposed to capture the broader context and complement Neutron's current mission statement: To implement services and associated libraries that provide abstractions for advanced network functions beyond basic L2/L3 connectivity and forwarding. What do people think? > Thanks, > —Hanif. > > From: "Paul Michali (pcm)" <p...@cisco.com> > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Date: Tuesday, November 18, 2014 at 4:08 PM > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into > separate repositories > > On Nov 18, 2014, at 6: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? > > 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. > > > Would it make sense to define the advanced services repo as being for > services that are beyond basic connectivity and routing? For example, VPN > can be L2 and L3. Seems like restricting to L4-L7 may cause some confusion > as to what’s in and what’s out. > > > Regards, > > PCM (Paul Michali) > > MAIL …..…. p...@cisco.com > IRC ……..… pc_m (irc.freenode.com) > TW ………... @pmichali > GPG Key … 4525ECC253E31A83 > Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83 > > > > 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 > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev