Open Stack

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:sumitnaiksatam at gmail.com] 
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 <henry4hly at gmail.com> 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 
> <sumitnaiksatam at gmail.com> wrote:
>> On Tue, Nov 18, 2014 at 4:44 PM, Mohammad Hanif <mhanif at 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)" <pcm at cisco.com>
>>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>>> <openstack-dev at lists.openstack.org>
>>> Date: Tuesday, November 18, 2014 at 4:08 PM
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>> <openstack-dev at 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. <armamig at 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 …..…. pcm at 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 <dougw at 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 <mark at 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 at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev