Open Stack

On 09/05/16 09:44, Julien Danjou wrote:
> On Mon, May 09 2016, Thomas Herve wrote:
>
>
> […]
>
>> Using DLM
>> ----------------
>>
>> We managed to not talk about ZooKeeper too much :). We want to remove
>> the database locks that we have and use tooz instead. The key is to
>> provide a nice upgrade path, so starting with the locks use for
>> convergence seems easier. If it turns out to be painless, we'll move
>> the stack locks from the legacy engine as well.
>
> I don't know what stack lock so my apologies if I'm saying anything
> wrong.
>
> There might be a nice upgrade path solution, which is to use your
> database as the lock manager. Tooz provides locking primitive against
> MySQL and PostgreSQL with their respective driver.
>
> We do that by default in Gnocchi. It offers a very nice and simple
> "works by default": Gnocchi picks the database URL and pass it to Tooz,
> so we have a DLM "for free".
>
> Then, bigger deployments can tweak the Tooz URL to make it point to
> something more robust (ZooKeeper, etcd…).

I missed this session because I was at a TripleO one, but that would be 
a good plan for anything where we have an entry in the StackLock table. 
I know that this includes the stack-level locks in the legacy code path.

I believe, but am open to correction, that the resource-level locks in 
convergence are directly in the Resource table - that is, they ensure 
that the writes we're already doing are atomic, rather than providing a 
distributed mutex implementation. In performance terms, we get this 
effectively for free because we are doing those writes anyway. Switching 
to a database-backed distributed mutex like tooz or our existing 
StackLock would result in a bunch of extra database writes at a time 
when we're trying to _reduce_ the impact of convergence hammering the 
DB. So in that case I think we'd have to make it optional/selectable. 
(Optional locking would actually work here - it would eliminate 
contention at the DB level and therefore improve worst-case performance, 
but wouldn't be required for correctness since our writes are already 
atomic.)

cheers,
Zane.