[openstack-dev] [Heat] Locking and ZooKeeper - a space oddysey

Clint Byrum clint at fewbar.com
Wed Oct 30 19:37:37 UTC 2013


Excerpts from Joshua Harlow's message of 2013-10-30 11:57:30 -0700:
> As for the mutex and locking and all that problem.
> 
> I would expect locking to be a necessity at some point for openstack.
> 
> Even if the state transitions are the locks themselves (that¹s still a
> lock by another name imho) and u need a reliable way to store and change
> those state transitions (aka what the last one was, what the next one is).
> A database can be likely ok here but is not ideal as complexity increases.
> The other part that I think zookeepr addresses is similar to how it is
> used in nova, where its used as a 'liveness' system, where instead of
> consistently updating a database with heartbeats zookeeper itself
> maintains that information without requiring constant updates to a DB
> (which doesn't scale).

I'm not so concerned with locks under the covers, I am concerned with
locking as a paradigm. It is too low level for what Heat is aiming at.
Yes of course serialization can and often does rely on locking. My point
is really that we should not care how serialization happens, we should
just express the work-flow, and let the underlying mechanisms distribute
and manage it as it is completed. My sincerest hope is that we can make
TaskFlow do this.



More information about the OpenStack-dev mailing list