On 03/11/2015 1:28 PM, "Robert Collins" <robe...@robertcollins.net> wrote: > > Hi, at the summit we had a big session on distributed lock managers (DLMs).
Awesome. > > 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. Agreed and it's also a positive step. > > 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. This really is fantastic news. Thanks for the 'heads up'. Geoff > > -Rob > > -- > Robert Collins <rbtcoll...@hp.com> > Distinguished Technologist > HP Converged Cloud > > __________________________________________________________________________ > 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
__________________________________________________________________________ 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