[openstack-dev] [all] Outcome of distributed lock manager discussion @ the summit

Sean Dague sean at dague.net
Wed Nov 4 12:07:48 UTC 2015


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 <harlowja at 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-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 


-- 
Sean Dague
http://dague.net



More information about the OpenStack-dev mailing list