Regarding this conversation about QoS, [1] as Nate said, we have every feature x4 ( x[API, OVS, LB, SR-IOV]) and I add: we should avoid writing RFEs for any missing piece in the reference implementations, if any of those is missing, that’s just a bug.
I guess I haven’t been communicating the status and plan lately neither reviewing new RFEs due to our focus on the current ones, sorry about that. I believe the framework we have is solid (what could I say!) but we’re sticking to the features that are easier to develop on the reference implementation, and still beneficial to the broadest audience (like bandwidth policing, L3 marking -DSCP- , … ) and then we will be able to jump into more complicated QoS rules. Some of the things, are simply technically complicated in the low level while very easy to model with the current framework. And some of the things need integration with the nova scheduler (like min bandwidth guarantees -requested by NFV/operators-) After the QoS meeting I will work on a tiny report so we can raise visibility about the features, and the plans. Best regards, Miguel Ángel. [1] http://eavesdrop.openstack.org/meetings/neutron_drivers/2016/neutron_drivers.2016-02-18-22.01.log.html#l-52 <http://eavesdrop.openstack.org/meetings/neutron_drivers/2016/neutron_drivers.2016-02-18-22.01.log.html#l-52>
__________________________________________________________________________ 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
