Same question regarding QoS as a Service, once it will be approved. Should it belong to Advanced Services as well?
-----Original Message----- From: Sumit Naiksatam [mailto:[email protected]] Sent: Wednesday, November 19, 2014 9:15 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories On Tue, Nov 18, 2014 at 11:04 PM, henry hly <[email protected]> wrote: > Is FWaas L2/3 or L4/7? > Thats a good question, and what has been asked here in the context of VPNaaS as well. Hence the proposed definition below avoids characterizing the advanced services project purely as L4-7 because that would not be accurate (in the context of any of existing three services, or proposed new services). > On Wed, Nov 19, 2014 at 11:10 AM, Sumit Naiksatam > <[email protected]> wrote: >> On Tue, Nov 18, 2014 at 4:44 PM, Mohammad Hanif <[email protected]> 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)" <[email protected]> >>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" >>> <[email protected]> >>> Date: Tuesday, November 18, 2014 at 4:08 PM >>> To: "OpenStack Development Mailing List (not for usage questions)" >>> <[email protected]> >>> Subject: Re: [openstack-dev] [tc][neutron] Proposal to split Neutron >>> into separate repositories >>> >>> On Nov 18, 2014, at 6:36 PM, Armando M. <[email protected]> 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 …..…. [email protected] >>> 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 <[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 >>> >>> >>> >>> _______________________________________________ >>> 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 _______________________________________________ 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
