Open Stack

Excerpts from Doug Wiegley's message of 2014-07-30 09:48:17 -0700:
> > I'd have to look at the Neutron code, but I suspect that a simple
> > strategy of issuing the UPDATE SQL statement with a WHERE condition that
> 
> I¹m assuming the locking is for serializing code, whereas for what you
> describe above, is there some reason we wouldn¹t just use a transaction?
> 

I believe the code in question is doing something like this:

1) Check DB for initialized "SDN controller driver"
2) Not initialized -> initialize the SDN controller via its API
3) Record in DB that it is initialized

Step (2) above needs serialization, not (3).

Compare and update will end up working like a distributed lock anyway,
because the db model will have to be changed to have an "initializing"
state, and then if initializing fails, you'll have to have a timeout.. and
stealing for stuck processes.

Sometimes a distributed lock is actually a simpler solution.

Tooz will need work, no doubt. Perhaps if we call it 'oslo.locking' it
will make more sense. Anyway, my point stands: trust the experts, avoid
reinventing locking. And if you don't like tooz, extract the locking
code from Heat and turn it into an oslo.locking library or something.