Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

[Angus Lees]

On Mon Dec 01 2014 at 2:06:18 PM henry hly  wrote:

> My suggestion is that starting with LB and VPN as a trial, which can
> never be distributed.
>

.. Sure they can!   Loadbalancing in particular _should_ be distributed if
both the clients and backends are in the same cluster...

(I agree with your suggestion to start with LB+VPN btw, just not your
reasoning ;)

 - Gus
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

[henry hly]

FWaas is typically classified to L4-L7. But if they are developed
standalone, it would be very difficult for implementing with a
distributed manner. For example, with W-E traffic control in DVR mode,
we can't rely on a external python client rest api call, the policy
execution module must be loaded as the L3 agent extension, or another
service-policy agent in the compute node.

My suggestion is that starting with LB and VPN as a trial, which can
never be distributed. FW is very tightly coupled with L3, so leaving
it for discuss some time later may be more smooth.

On Wed, Nov 19, 2014 at 6:31 AM, Mark McClain  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@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

[Robert Collins]

On 19 November 2014 at 11:31, Mark McClain  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.

Just wondering- have you considered a deeper decomposition? This has
turned up e.g. during discussions in the Ironic context where having
an API driven DHCP environment would be great, but all the virtual
network management of Neutron is irrelevant.

E.g - having a collection of minimal do-one-thing-well APIs with a
common model. More SOA than we are today, but easier to reason about
for individual deployments, and providing an arguably clearer place
for vendors that have entirely different backends for various services
to plug into.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

[Doug Wiegley]

On 11/19/14, 5:02 PM, "Kyle Mestery"  wrote:

>On Tue, Nov 18, 2014 at 5:32 PM, Doug Wiegley 
>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?
>>
>My thinking here is that the specs repo is shared (at least initialy)
>because the projects are under one umbrella, and we want them to work
>closely together initially. This keeps everyone in the loop. Once
>things mature, we can look at reevaluating this. Does that make sense?

Good by me.

Thanks,
Doug


>
>Thanks,
>Kyle
>
>> Thanks,
>> doug
>>
>>
>>
>> On Nov 18, 2014, at 10:31 PM, Mark McClain  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/progr
>>ams.yaml
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

[Kyle Mestery]

On Thu, Nov 20, 2014 at 6:42 AM, Russell Bryant  wrote:
> On 11/20/2014 05:43 AM, Thierry Carrez wrote:
>> Kyle Mestery wrote:
>>> 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.
>>
>> Frankly, I don't think the TC really has to sign-off on what seems to be
>> a reorganization of code within a single program. We might get involved
>> if this is raised as a cross-project issue, but otherwise I don't think
>> you need to wait for a formal TC sign-off.
>>
>
> As proposed, I agree.  I appreciate the opportunity to sanity check, though.
>
Cool, thanks for the sanity check here. We'll proceed with the spec
and move forward with the proposal.

Kyle

> --
> Russell Bryant
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

[Russell Bryant]

On 11/20/2014 05:43 AM, Thierry Carrez wrote:
> Kyle Mestery wrote:
>> 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.
> 
> Frankly, I don't think the TC really has to sign-off on what seems to be
> a reorganization of code within a single program. We might get involved
> if this is raised as a cross-project issue, but otherwise I don't think
> you need to wait for a formal TC sign-off.
> 

As proposed, I agree.  I appreciate the opportunity to sanity check, though.

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

[Thierry Carrez]

Kyle Mestery wrote:
> 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.

Frankly, I don't think the TC really has to sign-off on what seems to be
a reorganization of code within a single program. We might get involved
if this is raised as a cross-project issue, but otherwise I don't think
you need to wait for a formal TC sign-off.

-- 
Thierry Carrez (ttx)

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

[Ivar Lazzaro]

While I agree that a unified endpoint could be a good solution for now, I
think that the easiest way of doing this would be by implementing it as an
external Neutron service.

Using python entry_points, the advanced service extensions can be loaded in
Neutron just like we do today (using neutron.conf).

We will basically have a new project for which Neutron will be a dependency
(not the other way around!) so that any module of Neutron can be
imported/used just like the new code was living within Neutron itself.

As far as UTs are concerned, Neutron will also be in the test-requirements
for the new project, which means that any existing UT framework in Neutron
today can be easily reused by the new services.

This is compliant with the requirement that Neutron stays the only
endpoint, giving the ability to the user to load the new services when she
wants by configuring Neutron alone, while separating the concerns more
easily and clearly.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

[Kyle Mestery]

On Tue, Nov 18, 2014 at 5:32 PM, Doug Wiegley  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?
>
My thinking here is that the specs repo is shared (at least initialy)
because the projects are under one umbrella, and we want them to work
closely together initially. This keeps everyone in the loop. Once
things mature, we can look at reevaluating this. Does that make sense?

Thanks,
Kyle

> Thanks,
> doug
>
>
>
> On Nov 18, 2014, at 10:31 PM, Mark McClain  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@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

[Kyle Mestery]

On Tue, Nov 18, 2014 at 5:36 PM, Armando M.  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  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  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@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> ___
> OpenStack-dev m

Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

[Paul Michali (pcm)]

I like the definition.


PCM (Paul Michali)

MAIL …..…. p...@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  wrote:

> On Tue, Nov 18, 2014 at 4:44 PM, Mohammad Hanif  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)" 
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Date: Tuesday, November 18, 2014 at 4:08 PM
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Subject: Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into
>> separate repositories
>> 
>> On Nov 18, 2014, at 6:36 PM, Armando M.  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 …..…. p...@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  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  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

Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

[Irena Berezovsky]

Same question regarding QoS as a Service, once it will be approved.
Should it belong to Advanced Services as well?

-Original Message-
From: Sumit Naiksatam [mailto:sumitnaiksa...@gmail.com] 
Sent: Wednesday, November 19, 2014 9:15 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into 
separate repositories

On Tue, Nov 18, 2014 at 11:04 PM, henry hly  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 
>  wrote:
>> On Tue, Nov 18, 2014 at 4:44 PM, Mohammad Hanif  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)" 
>>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>>> 
>>> Date: Tuesday, November 18, 2014 at 4:08 PM
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>> 
>>> Subject: Re: [openstack-dev] [tc][neutron] Proposal to split Neutron 
>>> into separate repositories
>>>
>>> On Nov 18, 2014, at 6:36 PM, Armando M.  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 …..…. p...@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  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  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 Qu

Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

[Sumit Naiksatam]

On Tue, Nov 18, 2014 at 11:04 PM, henry hly  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
>  wrote:
>> On Tue, Nov 18, 2014 at 4:44 PM, Mohammad Hanif  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)" 
>>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>>> 
>>> Date: Tuesday, November 18, 2014 at 4:08 PM
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>> 
>>> Subject: Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into
>>> separate repositories
>>>
>>> On Nov 18, 2014, at 6:36 PM, Armando M.  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 …..…. p...@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  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  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 f

Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

[henry hly]

Is FWaas L2/3 or L4/7?

On Wed, Nov 19, 2014 at 11:10 AM, Sumit Naiksatam
 wrote:
> On Tue, Nov 18, 2014 at 4:44 PM, Mohammad Hanif  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)" 
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Date: Tuesday, November 18, 2014 at 4:08 PM
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Subject: Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into
>> separate repositories
>>
>> On Nov 18, 2014, at 6:36 PM, Armando M.  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 …..…. p...@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  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  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 a

Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

[Sumit Naiksatam]

On Tue, Nov 18, 2014 at 4:44 PM, Mohammad Hanif  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)" 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: Tuesday, November 18, 2014 at 4:08 PM
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Subject: Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into
> separate repositories
>
> On Nov 18, 2014, at 6:36 PM, Armando M.  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 …..…. p...@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  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  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 

Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

[Mohammad Hanif]

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.

Thanks,
—Hanif.

From: "Paul Michali (pcm)" mailto:p...@cisco.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, November 18, 2014 at 4:08 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@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. 
mailto:arma...@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 …..…. p...@cisco.com<mailto:p...@cisco.com>
IRC ……..… pc_m (irc.freenode.com<http://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 
mailto:do...@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 
mailto:m...@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 adversel

Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

[Ian Wells]

On 18 November 2014 15:33, Mark McClain  wrote:

>
> > On Nov 18, 2014, at 5:45 PM, Doug Hellmann 
> wrote:
> >
> > There would not be a service or REST API associated with the Advanced
> Services code base? Would the REST API to talk to those services be part of
> the Neutron repository?
> >
> > Doug
>
> We had considered having a standalone REST service, but the Advance
> Services need a level of integration with Neutron that is more than REST
> and RPC can provide.


Actually, I don't agree with this.  I'm fairly sure that a combination of
REST and notifications *could* provide advanced services with the
information they require, so they could be a standalone, and optional,
service with its own API endpoint.  But the issue is that the interface
Neutron has today is clearly not sufficient for the needs of the advanced
services we have, and we would need to add APIs to facilitate that split
when we wanted to take this further.

-- 
Ian.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

[Paul Michali (pcm)]

On Nov 18, 2014, at 6:36 PM, Armando M.  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 …..…. p...@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  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  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@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

[Armando M.]

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  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  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@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

[Mark McClain]

> On Nov 18, 2014, at 5:45 PM, Doug Hellmann  wrote:
> 
> There would not be a service or REST API associated with the Advanced 
> Services code base? Would the REST API to talk to those services be part of 
> the Neutron repository?
> 
> Doug

We had considered having a standalone REST service, but the Advance Services 
need a level of integration with Neutron that is more than REST and RPC can 
provide.  So the initial plan is to have the operator configure the Neutron 
REST service to load the appropriate Advance Service controller modules.  This 
would enable the operators to continue to deploy a single endpoint and preserve 
existing user tools.

The integration interface would be formalized as part of the current 
refactoring work being completed during the Kilo cycle.

mark
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

[Doug Wiegley]

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 
mailto:m...@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

[Ivar Lazzaro]

>
> There would not be a service or REST API associated with the Advanced
> Services code base? Would the REST API to talk to those services be part of
> the Neutron repository?


This is a good question.

Also, I would love to have more details about the following point:

- The Advance Service Library would be an optional dependency of Neutron


If I understand correctly, the Advanced Services implementation will
probably use Neutron's resources for L2/L3 connectivity (eg. create a
port). So why are we planning on having this library as a Neutron's
dependency and not the way around?
Wouldn't this require extra changes in Neutron to happen before the split
can happen? Also, shouldn't the AS APIs exist in the AS project?

Imho, having this project act as an external Neutron extension makes more
sense. Have you considered this option? It requires less cross-project
changes and provides a very clear separation of concerns.

Thanks for your heads up,
Ivar.

On Tue, Nov 18, 2014 at 2:45 PM, Doug Hellmann 
wrote:

>
> On Nov 18, 2014, at 5:31 PM, Mark McClain  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@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> There would not be a service or REST API associated with the Advanced
> Services code base? Would the REST API to talk to those services be part of
> the Neutron repository?
>
> Doug
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

[Doug Hellmann]

On Nov 18, 2014, at 5:31 PM, Mark McClain  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@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

There would not be a service or REST API associated with the Advanced Services 
code base? Would the REST API to talk to those services be part of the Neutron 
repository?

Doug___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

[Mark McClain]

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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev