Thanks Dims, +2
On 11/03/2015 07:45 AM, Davanum Srinivas wrote: > 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 > > > -- Sean Dague http://dague.net __________________________________________________________________________ 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