Open Stack

On 22 April 2015 at 06:02, Miguel Angel Ajo Pelayo <mangelajo at redhat.com>
wrote:

>
> Hi everybody,
>
>    In the latest QoS meeting, one of the topics was a discussion about how
> to implement
> QoS [1] either as in core, or as a service plugin, in, or out-tree.
>

My apologies if I was unable to join, the meeting clashed with another one
I was supposed to attend.


>
>    It’s my feeling, and Mathieu’s that it looks more like a core feature,
> as we’re talking of
> port properties that we define at high level, and most plugins (QoS
> capable) may want
> to implement at dataplane/controlplane level, and also that it’s something
> requiring a good
> amount of review.
>
>
>    In the other hand Irena and Sean were more concerned about having a
> good separation
> of concerns (I agree actually with that part), and being able to do
> quicker iterations on a
> separate stackforge repo.
>

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.

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.


>    Since we didn’t seem to find an agreement, and I’m probably missing
> some details,
> I’d like to loop in our core developers and PTL to provide an opinion on
> this.
>
>
> [1]
> http://eavesdrop.openstack.org/meetings/neutron_qos/2015/neutron_qos.2015-04-21-14.03.log.html#l-192
>
>
> Thanks for your patience,
> Miguel Angel Ajo
>
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150422/cd0b613b/attachment.html>