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