[openstack-dev] [Neutron] Quota enforcement

Salvatore Orlando sorlando at nicira.com
Thu Jun 11 20:45:18 UTC 2015


Aloha!

As you know I pushed spec [1] during the Kilo lifecycle, but given the lazy
procrastinator that I am, I did not manage to complete in time for the
release.

This actually gave me a chance to realise that the spec that I pushed and
had approved did not make a lot of sense. Even worse, there were some false
claims especially when it comes to active-active DB clusters such as mysql
galera.

Thankfully nobody bothered to look at that - possibly because it renders
horribly in HTML - and that spared me a public shaming.

I have been then following a different approach. And a set of patches,
including a devref one [2], if up for review [3]. This hardly completes the
job: more work is required on the testing side, both as unit and functional
tests.

As for the spec, since I honestly would like to spare myself the hassle of
rewriting it, I would kindly ask our glorious drivers team if they're ok
with me submitting a spec in the shorter format approved for Liberty
without going through the RFE process, as the spec is however in the Kilo
backlog.

For testing I wonder what strategy do you advice for implementing
functional tests. I could do some black-box testing and verifying quota
limits are correctly enforced. However, I would also like to go a bit
white-box and also verify that reservation entries are created and removed
as appropriate when a reservation is committed or cancelled.
Finally it would be awesome if I was able to run in the gate functional
tests on multi-worker servers, and inject delays or faults to verify the
systems behaves correctly when it comes to quota enforcement.

Do these kinds of test even make sense? And are they feasible at all? I
doubt we have any framework for injecting anything in neutron code under
test.

Finally, please note I am using DB-level locks rather than non-locking
algorithms for making reservations. I can move to a non-locking algorithm,
Jay proposed one for nova for Kilo, and I can just implement that one, but
first I would like to be convinced with a decent proof (or sort of) that
the extra cost deriving from collision among workers is overshadowed by the
cost for having to handle a write-set certification failure and retry the
operation.

Please advice.

Regards,
Salvatore

[1]
http://specs.openstack.org/openstack/neutron-specs/specs/kilo-backlog/better-quotas.html
[2] https://review.openstack.org/#/c/190798/
[3]
https://review.openstack.org/#/q/project:openstack/neutron+branch:master+topic:bp/better-quotas,n,z
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150611/7f96a68e/attachment.html>


More information about the OpenStack-dev mailing list