<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On 22 April 2015 at 06:02, Miguel Angel Ajo Pelayo <span dir="ltr"><<a href="mailto:mangelajo@redhat.com" target="_blank">mangelajo@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
Hi everybody,<br>
<br>
   In the latest QoS meeting, one of the topics was a discussion about how to implement<br>
QoS [1] either as in core, or as a service plugin, in, or out-tree.<br></blockquote><div><br></div>My apologies if I was unable to join, the meeting clashed with another one I was supposed to attend.<div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
   It’s my feeling, and Mathieu’s that it looks more like a core feature, as we’re talking of<br>
port properties that we define at high level, and most plugins (QoS capable) may want<br>
to implement at dataplane/controlplane level, and also that it’s something requiring a good<br>
amount of review.<br>
<br>
<br>
   In the other hand Irena and Sean were more concerned about having a good separation<br>
of concerns (I agree actually with that part), and being able to do quicker iterations on a<br>
separate stackforge repo.<br></blockquote><div><br></div><div>Perhaps we're trying to address the issue at the wrong time. Once a reasonable agreement has been reached on the data model, and the API, whether we're going with a service plugin or core etc should be an implementation detail. I think the crux of the matter is the data plane integration. From a management and control standpoint it should be fairly trivial to expose/implement the API and business logic via a service plugin and, and some of you suggested, integrate with the core via callbacks.</div><div><br></div><div>However, I am pretty sure there will be preliminary work necessary to integrate the server with the agent fabric (when there is one) so that is no longer a pain. Extending what the agent can do the way we did so far (e.g. by adding extra payloads/messages, mixin etc) is not sustainable, and incredibly brittle.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
   Since we didn’t seem to find an agreement, and I’m probably missing some details,<br>
I’d like to loop in our core developers and PTL to provide an opinion on this.<br>
<br>
<br>
[1] <a href="http://eavesdrop.openstack.org/meetings/neutron_qos/2015/neutron_qos.2015-04-21-14.03.log.html#l-192" target="_blank">http://eavesdrop.openstack.org/meetings/neutron_qos/2015/neutron_qos.2015-04-21-14.03.log.html#l-192</a><br>
<br>
<br>
Thanks for your patience,<br>
Miguel Angel Ajo<br>
<br>
<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>
</blockquote></div><br></div></div>