Open Stack

>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 <sorlando at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150615/ae4cc75a/attachment.html>