>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.
+1! >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. I was thinking about this in the context of a lot of the fixes we have for other concurrency issues with the database. There are several exception handlers that aren't exercised in normal functional, tempest, and API tests because they require a very specific order of events between workers. I wonder if we could write a small shim DB driver that wraps the python one for use in tests that just makes a desired set of queries take a long time or fail in particular ways? That wouldn't require changes to the neutron code, but it might not give us the right granularity of control. >Finally, please note I am using DB-level locks rather than non-locking algorithms for making reservations. I thought these were effectively broken in Galera clusters. Is that not correct? If you do go that route, I think you will have to contend with DBDeadlock errors when we switch to the new SQL driver anyway. From what I've observed, it seems that if someone is holding a lock on a table and you try to grab it, pymsql immediately throws a deadlock exception. Cheers, Kevin Benton On Thu, Jun 11, 2015 at 1:45 PM, Salvatore Orlando <sorla...@nicira.com> wrote: > 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 > > -- Kevin Benton
__________________________________________________________________________ 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
