I like the definition.
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 On Nov 18, 2014, at 10:10 PM, Sumit Naiksatam <sumitnaiksa...@gmail.com> wrote: > 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev