Re: [openstack-dev] [Neutron][QoS] Request to be considered for neutron-incubator

2014-08-20 Thread Luke Gorrie 
On 19 August 2014 23:15, Alan Kavanagh  wrote:

> +1, I am hoping this is just a short term holding point and this will
> eventually be merged into main branch as this is a feature a lot of
> companies, us included would definitely benefit from having supported and
> many thanks to Sean for sticking with this and continue to push this.
>

Agreed. Thank you Sean for the great work on QoS. We are looking forward to
seeing this merged to master one day and meanwhile maintaining it on our
NFV branch for our own use.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][QoS] Request to be considered for neutron-incubator

2014-08-20 Thread Mathieu Rohon 
Hi

On Wed, Aug 20, 2014 at 12:12 AM, Salvatore Orlando  wrote:
> In the current approach QoS support is being "hardwired" into ML2.
>
> Maybe this is not the best way of doing that, as perhaps it will end up
> requiring every mech driver which enforces VIF configuration should support
> it.
> I see two routes. One is a mechanism driver similar to l2-pop, and then you
> might have a look at the proposed extension framework (and partecipate into
> the discussion).
> The other is doing a service plugin. Still, we'll have to solve how to
> implement the "binding" between a port/network and the QoS entity.

We have exactly the same issue while implementing the BGPVPN service plugin [1].
As for the Qos extension, the BGPVPN extension can extend network by
adding route target infos.
the BGPVPN data model has a foreign key to the extended network.

If Qos is implemented as a service plugin, I assume that the
architecture would be similar, with Qos datamodel
having  foreign keys to ports and/or Networks.

When a port is created, and it has Qos enforcement thanks to the service plugin,
let's assume that a ML2 Qos Mech Driver can fetch Qos info and send
them back to the L2 agent.
We would probably need a Qos Agent which communicates with the plugin
through a dedicated topic.

But when a Qos info is updated through the Qos extension, backed with
the service plugin,
the driver that implements the Qos plugin should send the new Qos
enforcment to the Qos agent through the Qos topic.

So I feel like implementing a core resource extension with a service
plugin needs :
1 : a MD to interact with the service plugin
2 : an agent and a mixin used by the the L2 agent.
3 : a dedicated topic used by the MD and the driver of the service
plugin to communicate with the new agent

Am I wrong?


[1]https://review.openstack.org/#/c/93329/


> If we go
> for the approach we've chosen so far the resource extension model you still
> have to deal with ML2 extensions. But I like orthogonality in services, and
> QoS is a service to me.
> Another arguable point is that we might want to reconsider our
> abuse^H^H^H^H^H use of resource attribute extension, but this is a story for
> a different thread.
>
> Regarding the incubator request, I think we need to wait for the process to
> be "blessed". But you have my support and I would happy to help to assist
> with this work item through its process towards graduation.
>
> This obviously provided the QoS team wants me to do that!
>
> Salvatore
>
>
> On 19 August 2014 23:15, Alan Kavanagh  wrote:
>>
>> +1, I am hoping this is just a short term holding point and this will
>> eventually be merged into main branch as this is a feature a lot of
>> companies, us included would definitely benefit from having supported and
>> many thanks to Sean for sticking with this and continue to push this.
>> /Alan
>>
>> -Original Message-
>> From: Collins, Sean [mailto:sean_colli...@cable.comcast.com]
>> Sent: August-19-14 8:33 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: [openstack-dev] [Neutron][QoS] Request to be considered for
>> neutron-incubator
>>
>> Hi,
>>
>> The QoS API extension has lived in Gerrit/been in review for about a year.
>> It's gone through revisions, summit design sessions, and for a little while,
>> a subteam.
>>
>> I would like to request incubation in the upcoming incubator, so that the
>> code will have a more permanent "home" where we can collaborate and improve.
>> --
>> Sean M. Collins
>> ___
>> 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] [Neutron][QoS] Request to be considered for neutron-incubator

2014-08-20 Thread Wuhongning 
Absolutely it's not a good idea to encourage vendor implementing their own 
attributes in vif-detail, and I just mean it is *possible* to do this, which 
make sense when some feature is wanted temporarily before it is approved by 
community. As for the conflicts, restriction can be made that certain prefix 
must be attached: _private_vendorA_xxx.

For the vif-detail dumping ground, I'm not sure if API compatibility needs it. 
For example now the security group uuid is applied on the PORT object, and this 
api call is sent to ML2 plugin for association. If we change the api style, let 
PORT uuid be applied on SG object then indeed no foreign key is needed.


From: Kevin Benton [blak...@gmail.com]
Sent: Wednesday, August 20, 2014 2:14 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][QoS] Request to be considered for 
neutron-incubator

>Vendors can even implement their own private extension without any change to 
>ML2 by defining their customized vif-detail fields.

I'm not sure this is a good thing. What happens when 3 different vendors all 
implement the same attribute with the same name with different behavior? Since 
the API is no longer standard even with the reference core plugin, it fragments 
the clients. Each vendor will need to write it's own neutron client changes, 
GUIs, etc.

If the ML2 vif-details structure is going to become a dumping ground for 
anything, why even store things there in the first place? Since everything will 
require custom clients, the port ID can just be used as a foreign key to 
another API instead and the ML2 objects don't need to change at all.


On Tue, Aug 19, 2014 at 6:11 PM, Wuhongning 
mailto:wuhongn...@huawei.com>> wrote:
+1 to service plugin

It's better to strip service related extensions from ML2 core plugin as 
possible as we can, and put them in separate service plugin. Not only QOS, but 
also SG or possible other extensions. For the "binding" issue, vif-detail dict 
might be used for foreign key association.

Whenever service is added, new key type could be defined in vif-detail dict to 
associate with service object uuid from this new plugin. Vendors can even 
implement their own private extension without any change to ML2 by defining 
their customized vif-detail fields. Not only port, but network/subnet should 
also add such meta dict fields in their attribute, flexible foreign key support 
has been in absence for a long time on these ML2 core resource.

In the previous GBP discussion, I've also suggested similar idea. If we have 
clean boundary between ML2 core plugin and service plugin, the argumentative 
EP/EPG or renamed PT/PG resource object could be eliminated even if GBP is in 
the Neutron, because we can apply service contract group objects directly onto 
existing port/network/subnet resource by foreign key association binding, 
without reinvent these overlapped concept.


From: Salvatore Orlando [sorla...@nicira.com<mailto:sorla...@nicira.com>]
Sent: Wednesday, August 20, 2014 6:12 AM

To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][QoS] Request to be considered for 
neutron-incubator

In the current approach QoS support is being "hardwired" into ML2.

Maybe this is not the best way of doing that, as perhaps it will end up 
requiring every mech driver which enforces VIF configuration should support it.
I see two routes. One is a mechanism driver similar to l2-pop, and then you 
might have a look at the proposed extension framework (and partecipate into the 
discussion).
The other is doing a service plugin. Still, we'll have to solve how to 
implement the "binding" between a port/network and the QoS entity. If we go for 
the approach we've chosen so far the resource extension model you still have to 
deal with ML2 extensions. But I like orthogonality in services, and QoS is a 
service to me.
Another arguable point is that we might want to reconsider our abuse^H^H^H^H^H 
use of resource attribute extension, but this is a story for a different thread.

Regarding the incubator request, I think we need to wait for the process to be 
"blessed". But you have my support and I would happy to help to assist with 
this work item through its process towards graduation.

This obviously provided the QoS team wants me to do that!

Salvatore


On 19 August 2014 23:15, Alan Kavanagh 
mailto:alan.kavan...@ericsson.com>> wrote:
+1, I am hoping this is just a short term holding point and this will 
eventually be merged into main branch as this is a feature a lot of companies, 
us included would definitely benefit from having supported and many thanks to 
Sean for sticking with this and continue to push this.
/Alan

-Original Message-
From: Collins, Sean 
[mailto:sean_colli...@ca

Re: [openstack-dev] [Neutron][QoS] Request to be considered for neutron-incubator

2014-08-19 Thread Kevin Benton 
>Vendors can even implement their own private extension without any change
to ML2 by defining their customized vif-detail fields.

I'm not sure this is a good thing. What happens when 3 different vendors
all implement the same attribute with the same name with different
behavior? Since the API is no longer standard even with the reference core
plugin, it fragments the clients. Each vendor will need to write it's own
neutron client changes, GUIs, etc.

If the ML2 vif-details structure is going to become a dumping ground for
anything, why even store things there in the first place? Since everything
will require custom clients, the port ID can just be used as a foreign key
to another API instead and the ML2 objects don't need to change at all.


On Tue, Aug 19, 2014 at 6:11 PM, Wuhongning  wrote:

>  +1 to service plugin
>
>  It's better to strip service related extensions from ML2 core plugin as
> possible as we can, and put them in separate service plugin. Not only QOS,
> but also SG or possible other extensions. For the "binding" issue,
> vif-detail dict might be used for foreign key association.
>
>  Whenever service is added, new key type could be defined in vif-detail
> dict to associate with service object uuid from this new plugin. Vendors
> can even implement their own private extension without any change to ML2 by
> defining their customized vif-detail fields. Not only port, but
> network/subnet should also add such meta dict fields in their attribute,
> flexible foreign key support has been in absence for a long time on these
> ML2 core resource.
>
>  In the previous GBP discussion, I've also suggested similar idea. If we
> have clean boundary between ML2 core plugin and service plugin, the 
> argumentative
> EP/EPG or renamed PT/PG resource object could be eliminated even if GBP
> is in the Neutron, because we can apply service contract group objects
> directly onto existing port/network/subnet resource by foreign key
> association binding, without reinvent these overlapped concept.
>
>  --
> *From:* Salvatore Orlando [sorla...@nicira.com]
> *Sent:* Wednesday, August 20, 2014 6:12 AM
>
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Neutron][QoS] Request to be considered
> for neutron-incubator
>
>   In the current approach QoS support is being "hardwired" into ML2.
>
>  Maybe this is not the best way of doing that, as perhaps it will end up
> requiring every mech driver which enforces VIF configuration should support
> it.
> I see two routes. One is a mechanism driver similar to l2-pop, and then
> you might have a look at the proposed extension framework (and partecipate
> into the discussion).
> The other is doing a service plugin. Still, we'll have to solve how to
> implement the "binding" between a port/network and the QoS entity. If we go
> for the approach we've chosen so far the resource extension model you still
> have to deal with ML2 extensions. But I like orthogonality in services, and
> QoS is a service to me.
> Another arguable point is that we might want to reconsider our
> abuse^H^H^H^H^H use of resource attribute extension, but this is a story
> for a different thread.
>
>  Regarding the incubator request, I think we need to wait for the process
> to be "blessed". But you have my support and I would happy to help to
> assist with this work item through its process towards graduation.
>
>  This obviously provided the QoS team wants me to do that!
>
>  Salvatore
>
>
> On 19 August 2014 23:15, Alan Kavanagh  wrote:
>
>> +1, I am hoping this is just a short term holding point and this will
>> eventually be merged into main branch as this is a feature a lot of
>> companies, us included would definitely benefit from having supported and
>> many thanks to Sean for sticking with this and continue to push this.
>> /Alan
>>
>> -Original Message-
>> From: Collins, Sean [mailto:sean_colli...@cable.comcast.com]
>> Sent: August-19-14 8:33 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: [openstack-dev] [Neutron][QoS] Request to be considered for
>> neutron-incubator
>>
>> Hi,
>>
>> The QoS API extension has lived in Gerrit/been in review for about a
>> year. It's gone through revisions, summit design sessions, and for a little
>> while, a subteam.
>>
>> I would like to request incubation in the upcoming incubator, so that the
>> code will have a more permanent "home" where we can collaborate and improve.
>> --
>> Sean M. Collins
>>

Re: [openstack-dev] [Neutron][QoS] Request to be considered for neutron-incubator

2014-08-19 Thread Wuhongning 
+1 to service plugin

It's better to strip service related extensions from ML2 core plugin as 
possible as we can, and put them in separate service plugin. Not only QOS, but 
also SG or possible other extensions. For the "binding" issue, vif-detail dict 
might be used for foreign key association.

Whenever service is added, new key type could be defined in vif-detail dict to 
associate with service object uuid from this new plugin. Vendors can even 
implement their own private extension without any change to ML2 by defining 
their customized vif-detail fields. Not only port, but network/subnet should 
also add such meta dict fields in their attribute, flexible foreign key support 
has been in absence for a long time on these ML2 core resource.

In the previous GBP discussion, I've also suggested similar idea. If we have 
clean boundary between ML2 core plugin and service plugin, the argumentative 
EP/EPG or renamed PT/PG resource object could be eliminated even if GBP is in 
the Neutron, because we can apply service contract group objects directly onto 
existing port/network/subnet resource by foreign key association binding, 
without reinvent these overlapped concept.


From: Salvatore Orlando [sorla...@nicira.com]
Sent: Wednesday, August 20, 2014 6:12 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][QoS] Request to be considered for 
neutron-incubator

In the current approach QoS support is being "hardwired" into ML2.

Maybe this is not the best way of doing that, as perhaps it will end up 
requiring every mech driver which enforces VIF configuration should support it.
I see two routes. One is a mechanism driver similar to l2-pop, and then you 
might have a look at the proposed extension framework (and partecipate into the 
discussion).
The other is doing a service plugin. Still, we'll have to solve how to 
implement the "binding" between a port/network and the QoS entity. If we go for 
the approach we've chosen so far the resource extension model you still have to 
deal with ML2 extensions. But I like orthogonality in services, and QoS is a 
service to me.
Another arguable point is that we might want to reconsider our abuse^H^H^H^H^H 
use of resource attribute extension, but this is a story for a different thread.

Regarding the incubator request, I think we need to wait for the process to be 
"blessed". But you have my support and I would happy to help to assist with 
this work item through its process towards graduation.

This obviously provided the QoS team wants me to do that!

Salvatore


On 19 August 2014 23:15, Alan Kavanagh 
mailto:alan.kavan...@ericsson.com>> wrote:
+1, I am hoping this is just a short term holding point and this will 
eventually be merged into main branch as this is a feature a lot of companies, 
us included would definitely benefit from having supported and many thanks to 
Sean for sticking with this and continue to push this.
/Alan

-Original Message-
From: Collins, Sean 
[mailto:sean_colli...@cable.comcast.com<mailto:sean_colli...@cable.comcast.com>]
Sent: August-19-14 8:33 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron][QoS] Request to be considered for 
neutron-incubator

Hi,

The QoS API extension has lived in Gerrit/been in review for about a year. It's 
gone through revisions, summit design sessions, and for a little while, a 
subteam.

I would like to request incubation in the upcoming incubator, so that the code 
will have a more permanent "home" where we can collaborate and improve.
--
Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto: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] [Neutron][QoS] Request to be considered for neutron-incubator

2014-08-19 Thread Salvatore Orlando 
In the current approach QoS support is being "hardwired" into ML2.

Maybe this is not the best way of doing that, as perhaps it will end up
requiring every mech driver which enforces VIF configuration should support
it.
I see two routes. One is a mechanism driver similar to l2-pop, and then you
might have a look at the proposed extension framework (and partecipate into
the discussion).
The other is doing a service plugin. Still, we'll have to solve how to
implement the "binding" between a port/network and the QoS entity. If we go
for the approach we've chosen so far the resource extension model you still
have to deal with ML2 extensions. But I like orthogonality in services, and
QoS is a service to me.
Another arguable point is that we might want to reconsider our
abuse^H^H^H^H^H use of resource attribute extension, but this is a story
for a different thread.

Regarding the incubator request, I think we need to wait for the process to
be "blessed". But you have my support and I would happy to help to assist
with this work item through its process towards graduation.

This obviously provided the QoS team wants me to do that!

Salvatore


On 19 August 2014 23:15, Alan Kavanagh  wrote:

> +1, I am hoping this is just a short term holding point and this will
> eventually be merged into main branch as this is a feature a lot of
> companies, us included would definitely benefit from having supported and
> many thanks to Sean for sticking with this and continue to push this.
> /Alan
>
> -Original Message-
> From: Collins, Sean [mailto:sean_colli...@cable.comcast.com]
> Sent: August-19-14 8:33 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [Neutron][QoS] Request to be considered for
> neutron-incubator
>
> Hi,
>
> The QoS API extension has lived in Gerrit/been in review for about a year.
> It's gone through revisions, summit design sessions, and for a little
> while, a subteam.
>
> I would like to request incubation in the upcoming incubator, so that the
> code will have a more permanent "home" where we can collaborate and improve.
> --
> Sean M. Collins
> ___
> 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] [Neutron][QoS] Request to be considered for neutron-incubator

2014-08-19 Thread Alan Kavanagh 
+1, I am hoping this is just a short term holding point and this will 
eventually be merged into main branch as this is a feature a lot of companies, 
us included would definitely benefit from having supported and many thanks to 
Sean for sticking with this and continue to push this.
/Alan

-Original Message-
From: Collins, Sean [mailto:sean_colli...@cable.comcast.com] 
Sent: August-19-14 8:33 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron][QoS] Request to be considered for 
neutron-incubator

Hi,

The QoS API extension has lived in Gerrit/been in review for about a year. It's 
gone through revisions, summit design sessions, and for a little while, a 
subteam.

I would like to request incubation in the upcoming incubator, so that the code 
will have a more permanent "home" where we can collaborate and improve.
--
Sean M. Collins
___
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] [Neutron][QoS] Request to be considered for neutron-incubator

2014-08-19 Thread Robert Kukura 
Actually, whether the incubator is involved for not, this might be a 
great candidate for implementation using an ML2 extension driver. See 
https://review.openstack.org/#/c/89211/ for the code under review for 
Juno, and also 
https://docs.google.com/a/noironetworks.com/document/d/14T-defRnFl6M2xR5ZNFGYD6aIiAVWdd1Al9BnjV_JOs 
for planned followup work that would enforce extension semantics during 
port binding.


-Bob

On 8/19/14, 2:46 PM, Kevin Benton wrote:

+1.

This work in particular brings up a question about the incubator. One 
of the rules was that the neutron core code can't import code from the 
incubated projects. The QoS requires a mixin to annotate the port and 
network objects with QoS settings. How exactly would we actually use 
the QoS code from the incubator since we can't import the mixins in 
the ML2 plugin?



On Tue, Aug 19, 2014 at 11:33 AM, Collins, Sean 
> wrote:


Hi,

The QoS API extension has lived in Gerrit/been in review for about a
year. It's gone through revisions, summit design sessions, and for a
little while, a subteam.

I would like to request incubation in the upcoming incubator, so that
the code will have a more permanent "home" where we can
collaborate and
improve.
--
Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Kevin Benton


___
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] [Neutron][QoS] Request to be considered for neutron-incubator

2014-08-19 Thread Kevin Benton 
+1.

This work in particular brings up a question about the incubator. One of
the rules was that the neutron core code can't import code from the
incubated projects. The QoS requires a mixin to annotate the port and
network objects with QoS settings. How exactly would we actually use the
QoS code from the incubator since we can't import the mixins in the ML2
plugin?


On Tue, Aug 19, 2014 at 11:33 AM, Collins, Sean <
sean_colli...@cable.comcast.com> wrote:

> Hi,
>
> The QoS API extension has lived in Gerrit/been in review for about a
> year. It's gone through revisions, summit design sessions, and for a
> little while, a subteam.
>
> I would like to request incubation in the upcoming incubator, so that
> the code will have a more permanent "home" where we can collaborate and
> improve.
> --
> Sean M. Collins
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

[openstack-dev] [Neutron][QoS] Request to be considered for neutron-incubator

2014-08-19 Thread Collins, Sean 
Hi,

The QoS API extension has lived in Gerrit/been in review for about a
year. It's gone through revisions, summit design sessions, and for a
little while, a subteam.

I would like to request incubation in the upcoming incubator, so that
the code will have a more permanent "home" where we can collaborate and
improve.
-- 
Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev