<div dir="ltr">Aloha!<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Thankfully nobody bothered to look at that - possibly because it renders horribly in HTML - and that spared me a public shaming.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Please advice.</div><div><br></div><div>Regards,</div><div>Salvatore</div><div><br></div><div>[1] <a href="http://specs.openstack.org/openstack/neutron-specs/specs/kilo-backlog/better-quotas.html">http://specs.openstack.org/openstack/neutron-specs/specs/kilo-backlog/better-quotas.html</a></div><div>[2] <a href="https://review.openstack.org/#/c/190798/">https://review.openstack.org/#/c/190798/</a></div><div>[3] <a href="https://review.openstack.org/#/q/project:openstack/neutron+branch:master+topic:bp/better-quotas,n,z">https://review.openstack.org/#/q/project:openstack/neutron+branch:master+topic:bp/better-quotas,n,z</a></div></div>