Open Stack

I like the definition.


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




On Nov 18, 2014, at 10:10 PM, 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141119/2d24ac67/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141119/2d24ac67/attachment.pgp>