Open Stack

Lock free solutions usually involve very predictable and very well understood (and typically provably correct) state machines. In openstack u have state machines but I think there is work to be done to increase there understandability and predictability. 

Lock free algorithms are also extremely hard to get right (this is why the above state machine typically undergoes very thought out and extensive peer review). In openstack we all are that peer review :)

Hopefully this discussion here (and on irc and on code reviews) can help jump start more thinking around this whole area.

Sent from my really tiny device...

> On Oct 30, 2013, at 12:33 PM, "Qing He" <Qing.He at radisys.com> wrote:
> 
> Has anyone looked at any  lock-free solution?
> 
> -----Original Message-----
> From: Sandy Walsh [mailto:sandy.walsh at rackspace.com] 
> Sent: Wednesday, October 30, 2013 12:20 PM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [Heat] Locking and ZooKeeper - a space oddysey
> 
> 
> 
>> On 10/30/2013 03:10 PM, Steven Dake wrote:
>> I will -2 any patch that adds zookeeper as a dependency to Heat.
> 
> Certainly any distributed locking solution should be plugin based and optional. Just as a database-oriented solution could be the default plugin.
> 
> Re: the Java issue, we already have optional components in other languages. I know Java is a different league of pain, but if it's an optional component and left as a choice of the deployer, should we care?
> 
> -S
> 
> PS> As an aside, what are your issues with ZK?
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev