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.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
