+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 
<alan.kavan...@ericsson.com<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

Reply via email to