On 31 October 2013 06:42, Clint Byrum <cl...@fewbar.com> wrote: > So, recently we've had quite a long thread in gerrit regarding locking > in Heat: > > https://review.openstack.org/#/c/49440/ > > In the patch, there are two distributed lock drivers. One uses SQL, > and suffers from all the problems you might imagine a SQL based locking > system would. It is extremely hard to detect dead lock holders, so we > end up with really long timeouts. The other is ZooKeeper. > > I'm on record as saying we're not using ZooKeeper. It is a little > embarrassing to have taken such a position without really thinking things > through. The main reason I feel this way though, is not because ZooKeeper > wouldn't work for locking, but because I think locking is a mistake.
I agree with all your points: - that mutex style locking here is a mistake - that we need a workaround in the short term - that sql locking can be hard to get right However if this is a short term workaround, who cares if SQL locking has bad failure modes: it's short term and the failure we're replacing (engines tramping on each other) is also bad. On Zookeeper: this would be the first Java service /required/ as part of a deployment of OpenStack's integrated components. I think that requires broad consensus - possibly even a TC vote - before adding it. [NB: I'm not against Java, but it's not a social norm here]. Secondly, but also importantly, I seem to recall Zookeeper really not being suitable for secure environments, but maybe thats just how it was used in my previous interactions with it? -Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
