Open Stack

I've been working on assembling a QoS[1] POC since last day of the 
coding sprint in Israel [2],
Ihar has reported to the list our plan to get into master [3].

I've been able to validate and integrate lots of the patches, and find 
the gaps, while still
finishing the top-down assembly may require a few more hours, or an 
extra day, I believe
we should prioritize the work to make such POC available for easy 
consumption in
feature/qos.

For that to happen, we should prioritize review and merge of the 
following patches into the branch:
(I'd be very thankful to any review cycles anyone could spend on this, 
specially cores, of course)

QoS service plugin:

* https://review.openstack.org/#/c/197564/
* https://review.openstack.org/#/c/197898/

Agent side:

* https://review.openstack.org/#/c/195440/ (I just found a bug in the 
logic, working to submit a new PS)
* https://review.openstack.org/#/c/197557/ (waiting for merge, dependent 
on other patch)

DB Models & Versioned Objects (unit tests+ fixes):

* https://review.openstack.org/#/c/200005/
* https://review.openstack.org/#/c/200036/
* https://review.openstack.org/#/c/200418/
--
ready for merge, waiting on rebase from master, failing on the mock-hell:
* https://review.openstack.org/#/c/198163/
* https://review.openstack.org/#/c/197898/
* https://review.openstack.org/#/c/199627/
* https://review.openstack.org/#/c/199634/


Extra stones:
a)

@armax, please check where I make sense here, I believe I do, but of 
course I want your opinion:
We also need to introduce new BEFORE_UPDATE callbacks for ports and networks
before any call to plugin. So we'll be able to retrieve qos_profile_id, 
and check it, and
associate/dissociate network/port to profile.

AFTER_UPDATE is working ok here, with a few workarounds, since, for example,
it's called from ML2, and ML2, will only push information of the port 
when the port
has changed anything relevant to ML2, and won't even provide the port_id ...
I'm not sure where this is used/what's the use case.


b) rule list handling in the policy versioned object (Ihar is handling 
that here, WIP): https://review.openstack.org/#/c/200608/
c) serializing and deserializing the policy - rules dictionary over the 
wire (thanks to versioned objects).


Afterwards, we must follow with the plan Ihar explained in [3], we don't 
have much time,
so, if you have an interest on QoS, please join the effort and help us 
with anything you can
if you want it as an experimental feature available by L.

Quality Regards ;)
Miguel Ángel

[1] 
http://specs.openstack.org/openstack/neutron-specs/specs/liberty/qos-api-extension.html
[2] TL;DR report, with nice pictures : 
http://www.ajo.es/post/123458887419/neutron-quality-of-service-coding-sprint
[3] http://lists.openstack.org/pipermail/openstack-dev/2015-July/069188.html