<div dir="ltr">><span style="font-size:12.8000001907349px">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.</span><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">+1!</span></div><div><br></div><div><span style="font-size:12.8000001907349px">></span><span style="font-size:12.8000001907349px">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.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">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. </span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">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. </span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div>><span style="font-size:12.8000001907349px">Finally, please note I am using DB-level locks rather than non-locking algorithms for making reservations.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">I thought these were effectively broken in Galera clusters. Is that not correct?</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">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.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">Cheers,</span></div><div><span style="font-size:12.8000001907349px">Kevin Benton</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 11, 2015 at 1:45 PM, Salvatore Orlando <span dir="ltr"><<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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" target="_blank">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/" target="_blank">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" target="_blank">https://review.openstack.org/#/q/project:openstack/neutron+branch:master+topic:bp/better-quotas,n,z</a></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div>Kevin Benton</div></div>
</div>