Open Stack

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.

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141118/b033e040/attachment.html>