<div dir="ltr">><span style="color:rgb(0,0,0);font-family:Tahoma;font-size:13.333333969116211px">Vendors can even implement their own private extension without any change to ML2 by defining their customized vif-detail fields.</span><div>
<span style="color:rgb(0,0,0);font-family:Tahoma;font-size:13.333333969116211px"><br></span></div><div><span style="color:rgb(0,0,0);font-family:Tahoma;font-size:13.333333969116211px">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. </span></div>
<div><span style="color:rgb(0,0,0);font-family:Tahoma;font-size:13.333333969116211px"><br></span></div><div><span style="color:rgb(0,0,0);font-family:Tahoma;font-size:13.333333969116211px">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.</span></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 19, 2014 at 6:11 PM, Wuhongning <span dir="ltr"><<a href="mailto:wuhongning@huawei.com" target="_blank">wuhongning@huawei.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt">+1 to service plugin
<div><br>
</div>
<div>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. <span style="font-size:10pt">For the "binding" issue, vif-detail
dict might be used for foreign key association.</span></div>
<div><span style="font-size:10pt"><br>
</span></div>
<div><span style="font-size:10pt">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.</span></div>
<div>
<div><br>
</div>
<div><span style="font-size:10pt">In the previous GBP discussion, I've also suggested similar idea. If we have clean boundary between ML2 core plugin and service plugin, the </span><span style="font-size:10pt;font-family:'Segoe UI',Helvetica,Arial,sans-serif;background-color:rgb(255,255,255)">argumentative
EP/EPG or renamed PT/PG resource </span><span style="font-size:10pt;background-color:rgb(255,255,255)"><font face="Segoe UI, Helvetica, Arial, sans-serif">object could be </font><font face="Segoe UI, Helvetica, Arial, sans-serif">eliminated
even if GBP is in the Neutron<font>, 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. </font></font></span></div>
<div><br>
<div style="font-family:Times New Roman;color:#000000;font-size:16px">
<hr>
<div style="direction:ltr"><font face="Tahoma" color="#000000"><b>From:</b> Salvatore Orlando [<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>]<br>
<b>Sent:</b> Wednesday, August 20, 2014 6:12 AM<div class=""><br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
</div><b>Subject:</b> Re: [openstack-dev] [Neutron][QoS] Request to be considered for neutron-incubator<br>
</font><br>
</div><div><div class="h5">
<div></div>
<div>
<div dir="ltr">In the current approach QoS support is being "hardwired" into ML2.
<div><br>
</div>
<div>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.</div>
<div>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).</div>
<div>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. </div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>This obviously provided the QoS team wants me to do that!</div>
<div><br>
</div>
<div>Salvatore</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On 19 August 2014 23:15, Alan Kavanagh <span dir="ltr"><<a href="mailto:alan.kavanagh@ericsson.com" target="_blank">alan.kavanagh@ericsson.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+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.<br>
<span><font color="#888888">/Alan<br>
</font></span>
<div>
<div><br>
-----Original Message-----<br>
From: Collins, Sean [mailto:<a href="mailto:Sean_Collins2@cable.comcast.com" target="_blank">Sean_Collins2@cable.comcast.com</a>]<br>
Sent: August-19-14 8:33 PM<br>
To: OpenStack Development Mailing List (not for usage questions)<br>
Subject: [openstack-dev] [Neutron][QoS] Request to be considered for neutron-incubator<br>
<br>
Hi,<br>
<br>
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.<br>
<br>
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.<br>
--<br>
Sean M. Collins<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div></div></div>
</div>
</div>
</div>
</div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Kevin Benton</div>
</div>