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