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

Davanum Srinivas davanum at gmail.com
Tue Nov 3 12:45:29 UTC 2015


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



-- 
Davanum Srinivas :: https://twitter.com/dims



More information about the OpenStack-dev mailing list