Open Stack

On Tue, Nov 18, 2014 at 5: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?
>
We're in the process of writing a spec for this now, but we first
wanted community feedback. Also, it's on the TC agenda for next week I
believe, so once we get signoff from the TC, we'll propose the spec.

Thanks,
Kyle

> 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.
>
> 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
>