+1 ;) On 10/30/13 12:37 PM, "Clint Byrum" <cl...@fewbar.com> wrote:
>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. > >_______________________________________________ >OpenStack-dev mailing list >OpenStack-dev@lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
