[openstack-dev] [Heat] Summit recap
zbitter at redhat.com
Mon May 9 23:22:40 UTC 2016
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
> 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
More information about the OpenStack-dev