Open Stack

Angus Lees wrote:
> On Fri Feb 06 2015 at 4:25:43 AM Clint Byrum <clint at fewbar.com
> <mailto:clint at fewbar.com>> wrote:
>
>     In a single thread, using a single database session, then a read after
>     successful commit is guaranteed to read a version of the database
>     that existed after that commit.
>
>
> Ah, I'm relieved to hear this clarification - thanks.
>
>     I'd like to see actual examples where that will matter. Meanwhile making
>     all selects wait for the cluster will basically just ruin responsiveness
>     and waste tons of time, so we should be careful to think this through
>     before making any blanket policy.
>
>
> Matthew's example earlier in the thread is simply a user issuing two
> related commands in succession:
>
> $ nova aggregate-create
> $ nova aggregate-details
>
> Once that fails a few times, the user will put a poorly commented "sleep
> 2" in between the two statements, and this will "fix" the problem most
> of the time.  A "better" fix would repeat the aggregate-details query
> multiple times until it looks like it has found the previous create.
>
> Now, that sleep or poll is of course a poor version of something you
> could do at a lower level, by waiting for reads+writes to propagate to a
> majority quorum.
>
>     I'd also like to see consideration given to systems that handle
>     distributed consistency in a more active manner. etcd and Zookeeper are
>     both such systems, and might serve as efficient guards for critical
>     sections without raising latency.
>
>
> +1 for moving to such systems.  Then we can have a repeat of the above
> conversation without the added complications of SQL semantics ;)
>

So just an fyi:

http://docs.openstack.org/developer/tooz/ exists.

Specifically:

http://docs.openstack.org/developer/tooz/developers.html#tooz.coordination.CoordinationDriver.get_lock

It has a locking api that it provides (that plugs into the various 
backends); there is also a WIP https://review.openstack.org/#/c/151463/ 
driver that is being worked for etc.d.

-Josh

>   - Gus
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev