<div dir="ltr">I was merely suggesting that this is the approach that we've followed so far.<div>The incubator is not even a real thing at the moment, so it's still too early to make any statement as we do not even know if the stuff in the incubator will use the same database or not. This is a necessary discussion to have, but until the nature of the incubator is not defined we would be just speculating.</div>
<div><br></div><div>For the time being, I'd just note that "foreign key" here might just be interpreted as "reference between two entities whose integrity will be guaranteed by a DBMS or other mechanism"</div>
<div><br></div><div>Salvatore</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 20 August 2014 13:19, Kevin Benton <span dir="ltr"><<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="">><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">From a data model perspective, I believe so if we follow the pattern we've followed so far. </span></div>
<div><font face="arial, sans-serif"><br>
</font><div><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">How will database setup work in this case? IIRC, the auto-generation of schema was just disabled in a recent merge. Will we have a big pile of various migration scripts that users will need to pick from depending on which services he/she wants to use from the various neutron incubated projects?</span></div>
</div></div><div class="gmail_extra"><div><div class="h5"><br><br><div class="gmail_quote">On Wed, Aug 20, 2014 at 4:03 AM, Salvatore Orlando <span dir="ltr"><<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">As the original thread had a completely different subject, I'm starting a new one here.<div><br></div>
<div>More specifically the aim of this thread is about:</div><div>1) Define when a service is best implemented with a service plugin or with a ML2 driver</div>
<div>2) Discuss how bindings between a "core" resource and the one provided by the service plugin should be exposed at the management plane, implemented at the control plane, and if necessary also at the data plane.</div>
<div><br></div><div>Some more comments inline.</div><div><br></div><div>Salvatore</div><div><br></div><div><div class="gmail_extra"><div class="gmail_quote">On 20 August 2014 11:31, Mathieu Rohon <span dir="ltr"><<a href="mailto:mathieu.rohon@gmail.com" target="_blank">mathieu.rohon@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi<br>
<div><br>
On Wed, Aug 20, 2014 at 12:12 AM, Salvatore Orlando <<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>> wrote:<br>
> In the current approach QoS support is being "hardwired" into ML2.<br>
><br>
> Maybe this is not the best way of doing that, as perhaps it will end up<br>
> requiring every mech driver which enforces VIF configuration should support<br>
> it.<br>
> I see two routes. One is a mechanism driver similar to l2-pop, and then you<br>
> might have a look at the proposed extension framework (and partecipate into<br>
> the discussion).<br>
> The other is doing a service plugin. Still, we'll have to solve how to<br>
> implement the "binding" between a port/network and the QoS entity.<br>
<br>
</div>We have exactly the same issue while implementing the BGPVPN service plugin [1].<br>
As for the Qos extension, the BGPVPN extension can extend network by<br>
adding route target infos.<br>
the BGPVPN data model has a foreign key to the extended network.<br>
<br>
If Qos is implemented as a service plugin, I assume that the<br>
architecture would be similar, with Qos datamodel<br>
having foreign keys to ports and/or Networks.<br></blockquote><div><br></div><div>From a data model perspective, I believe so if we follow the pattern we've followed so far. However, I think this would be correct also if QoS is not implemented as a service plugin!</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
When a port is created, and it has Qos enforcement thanks to the service plugin,<br>
let's assume that a ML2 Qos Mech Driver can fetch Qos info and send<br>
them back to the L2 agent.<br>
We would probably need a Qos Agent which communicates with the plugin<br>
through a dedicated topic.<br></blockquote><div><br></div><div>A distinct agent has pro and cons. I think however that we should try and limit the number of agents on the hosts to a minimum. And this minimum in my opinion should be 1! There is already a proposal around a modular agent which should be able of loading modules for handling distinct services. I think that's the best way forward.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
But when a Qos info is updated through the Qos extension, backed with<br>
the service plugin,<br>
the driver that implements the Qos plugin should send the new Qos<br>
enforcment to the Qos agent through the Qos topic.<br></blockquote><div><br></div><div>I reckon that is pretty much correct. At the end of the day, the agent which enforces QoS at the data plane just needs to ensure the appropriate configuration is in place on all ports. Whether this information is coming from a driver or a serivice plugin, it does not matter a lot (as long as it's not coming from an untrusted source, obviously). If you look at sec group agent module, the concept is pretty much the same.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So I feel like implementing a core resource extension with a service<br>
plugin needs :<br>
1 : a MD to interact with the service plugin<br>
2 : an agent and a mixin used by the the L2 agent.<br>
3 : a dedicated topic used by the MD and the driver of the service<br>
plugin to communicate with the new agent<br>
<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am I wrong?<br></blockquote><div><br></div><div>There is nothing wrong with that. Nevertheless, the fact that we need a Mech driver _and_ a service plugin probably also implies that the service plugin at the end of the day has not succeeded in its goal of being orthogonal.</div>
<div>I think it's worth try and exploring solutions which will allow us to completely decouple the service plugin for the core functionality, and therefore completely contain QoS management within its service plugin. If you too think this is not risible, I can perhaps put together something to validate this idea.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
[1]<a href="https://review.openstack.org/#/c/93329/" target="_blank">https://review.openstack.org/#/c/93329/</a><br>
<div><div><br>
<br>
> If we go<br>
> for the approach we've chosen so far the resource extension model you still<br>
> have to deal with ML2 extensions. But I like orthogonality in services, and<br>
> QoS is a service to me.<br>
> Another arguable point is that we might want to reconsider our<br>
> abuse^H^H^H^H^H use of resource attribute extension, but this is a story for<br>
> a different thread.<br>
><br>
> Regarding the incubator request, I think we need to wait for the process to<br>
> be "blessed". But you have my support and I would happy to help to assist<br>
> with this work item through its process towards graduation.<br>
><br>
> This obviously provided the QoS team wants me to do that!<br>
><br>
> Salvatore<br>
><br>
><br>
> On 19 August 2014 23:15, Alan Kavanagh <<a href="mailto:alan.kavanagh@ericsson.com" target="_blank">alan.kavanagh@ericsson.com</a>> wrote:<br>
>><br>
>> +1, I am hoping this is just a short term holding point and this will<br>
>> eventually be merged into main branch as this is a feature a lot of<br>
>> companies, us included would definitely benefit from having supported and<br>
>> many thanks to Sean for sticking with this and continue to push this.<br>
>> /Alan<br>
>><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<br>
>> neutron-incubator<br>
>><br>
>> Hi,<br>
>><br>
>> The QoS API extension has lived in Gerrit/been in review for about a year.<br>
>> It's gone through revisions, summit design sessions, and for a little while,<br>
>> a subteam.<br>
>><br>
>> I would like to request incubation in the upcoming incubator, so that the<br>
>> 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>
><br>
><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>
><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>
<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></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div>Kevin Benton</div>
</font></span></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></div>