Open Stack

Miguel Angel Ajo wrote:
>
> 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.

Talking to Mike Kolesnik, who is currently working into this piece, he 
just realized which
what I'm saying here it's partly wrong.

We need BEFORE_UPDATE to validate the data it's being provided 
(qos_policy_id permissions,
existence, etc..) and otherwise throw an exception.

Then we need AFTER_UPDATE (when we're sure nobody threw an exception) to
really stick it to the database, and, send a message to the QoS backend 
to configure
the ports.

>
> 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.

And we need to extend the understanding of ML2 changed information to 
detect changes to
qos_profile_id and send such information down the line (agents & the 
AFTER_UPDATE).
>
>
> 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
>
>
> __________________________________________________________________________ 
>
> 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