Open Stack

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
>