Open Stack

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