On 22 April 2015 at 06:02, Miguel Angel Ajo Pelayo <mangel...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev