Lock wait timeout adding ipavailabilityranges

[Eugene Nikanorov]

Traceback:
 http://logs.openstack.org/03/97803/3/check/check-tempest-dsvm-neutron-full/745ec83/logs/screen-q-svc.txt.gz#_2014-06-16_15_50_30_386

Occurence: rare

[Salvatore Orlando (salvatore-orlando)]

I unfortunately thought I filed a bug for this one bug I probably dreamt of that.

[Angus Lees (gus)]

So what's the plan with these "lock wait timeout" bugs?

Is the plan to A) squash each one separately, or B) squash the single underlying issue?

If A) it will mean preventing all eventlet-yielding calls while a transaction is open. I _think_ I can write a pylint check to find those cases for us.

If B) then I'd like to close all of these as duplicates of bug 1350149 - or some other central description of the problem.

I feel rather strongly that (B) is the right answer here, but the fact that multiple bugs were opened without linking to a single cause - and the general resistance I've been getting trying to abandon mysqldb(*) - makes me thing we (plural) want to go with (A) instead.

Thoughts?

(*) See for example Eugene's comment on bug 1350149. Not trying to highlight any particular incident, but I encountered such a total lack of enthusiasm from all directions for (B) that I went and worked on something else instead.

[Eugene Nikanorov (enikanorov)]

Writing such script might help.

There are known places where such yielding calls (usually, rpc calls) are made, but most of them are not the cause of those issues.

So each case requires it's own analysis.

The best solution is to move to non-blocking python client for mysql.

[Cedric Brandily (cbrandily)]

This bug is > 365 days without activity. We are unsetting assignee and milestone and setting status to Incomplete in order to allow its expiry in 60 days.

If the bug is still valid, then update the bug status.

[Ihar Hrachyshka (ihar-hrachyshka)]

We moved to pymysql since L.

[Launchpad Janitor (janitor)]

[Expired for neutron because there has been no activity for 60 days.]