Here's a Devstack review for zookeeper in support of this initiative: https://review.openstack.org/241040
Thanks, Dims On Mon, Nov 2, 2015 at 11:05 PM, Joshua Harlow <harlo...@fastmail.com> wrote: > Thanks robert, > > I've started to tweak https://review.openstack.org/#/c/209661/ with regard > to the outcome of that (at least to cover the basics)... Should be finished > up soon (I hope). > > > Robert Collins wrote: >> >> Hi, at the summit we had a big session on distributed lock managers >> (DLMs). >> >> I'd just like to highlight the conclusions we came to in the session ( >> https://etherpad.openstack.org/p/mitaka-cross-project-dlm >> ) >> >> Firstly OpenStack projects that want to use a DLM can make it a hard >> dependency. Previously we've had a unwritten policy that DLMs should >> be optional, which has led to us writing poor DLM-like things backed >> by databases :(. So this is a huge and important step forward in our >> architecture. >> >> As in our existing pattern of usage for database and message-queues, >> we'll use an oslo abstraction layer: tooz. This doesn't preclude a >> different answer in special cases - but they should be considered >> special and exception, not the general case. >> >> Based on the project requirements surfaced in the discussion, it seems >> likely that all of konsul, etc and zookeeper will be able to have >> suitable production ready drivers written for tooz. Specifically no >> project required a fair locking implementation in the DLM. >> >> After our experience with oslo.messaging however, we wanted to avoid >> the situation of having unmaintained drivers and no signalling to >> users about them. >> >> So, we resolved to adopt roughly the oslo.messaging requirements for >> drivers, with a couple of tweaks... >> >> Production drivers in-tree will need: >> - two nominated developers responsible for it >> - gating functional tests that use dsvm >> Test drivers in-tree will need: >> - clear identification that the driver is a test driver - in the >> module name at minimum >> >> All hail our new abstraction overlords. >> >> -Rob >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev