[openstack-dev] [all] Does OpenStack need a common solution for DLM?

Joshua Harlow harlowja at outlook.com
Wed Aug 5 21:18:58 UTC 2015


Flavio Percoco wrote:
> On 04/08/15 21:14 -0700, Joshua Harlow wrote:
>> Morgan Fainberg wrote:
>>>
>>>
>>> On Tue, Aug 4, 2015 at 8:44 AM, Joshua Harlow <harlowja at outlook.com
>>> <mailto:harlowja at outlook.com>> wrote:
>>>
>>> Flavio Percoco wrote:
>>>
>>> On 03/08/15 19:48 +0200, Gorka Eguileor wrote:
>>>
>>> On Mon, Aug 03, 2015 at 03:42:48PM +0000, Fox, Kevin M wrote:
>>>
>>> I'm usually for abstraction layers, but they don't
>>> always pay off
>>> very well due to catering to the lowest common denominator.
>>>
>>> Lets clearly define the problem space first. IFF the
>>> problem space
>>> can be fully implemented using Tooz, then lets do that.
>>> Then the
>>> operator can choose. If Tooz cant and wont handle the
>>> problem space,
>>> then we're trying to fit a square peg in a round hole.
>>>
>>>
>>> What do you mean with clearly define the problem space? We
>>> know what we
>>> want, we just need to agree on the compromises we are
>>> willing to make,
>>> use a DLM and make admins' life a little harder (only for
>>> those that
>>> deploy A-A) but have an A-A solution earlier, or postpone A-A
>>> functionality but make their life easier.
>>>
>>> And we already know that Tooz is not the Holy Grail and will
>>> not perform
>>> the miracle of giving Cinder HA A-A. It is only a piece of
>>> the problem,
>>> so there's nothing to discuss there, and it's not a square
>>> peg on a
>>> round hole, because it fits perfectly for what it is
>>> intended. But once
>>> you have filled that square hole you need another peg, the
>>> round one for
>>> the round hole.
>>>
>>> If people are expecting to find one thing that fixes
>>> everything and
>>> gives us HA A-A on its own, then I believe they are a little
>>> bit lost.
>>>
>>>
>>> As confusing as it seems, we've now moved from talking about just
>>> Cinder to understanding whether this is a problem many projects have
>>> and whether we can find a solution that will work for most of them.
>>> Therefore, I've renamed this thread to make this more evident.
>>>
>>> Now, so far we have:
>>>
>>> - Ironic has an internal distributed lock and it uses a hash-ring
>>> - Ceilometer uses tooz
>>> - Several projects use a file lock of some other fashion of
>>> distributed lock.
>>> - *Add yours here*
>>>
>>> Each one of these projects has a specific use-case that doesn't
>>> necessarily overlap. I'd like to see those cases listed somewhere.
>>> We've done this in the past already and I believe we can do it
>>> now as
>>> well. As I've mentioned in another thread, Gorka has done this for
>>> Cinder already now we need to do it for other services too. Even if
>>> your project has a DLM in place, it'd be good to know what
>>> problem you
>>> solved with it as it may be a problem that other projects have as
>>> well.
>>>
>>> As a community, we've been able to do away with adding a new service
>>> for DLM's thus far. I'm not saying we don't need one but, as
>>> mentioned
>>> in other threads, lets give this some more thought before we add
>>> a new
>>> service that'll make deploying and maintaining OpenStack harder.
>>>
>>>
>>> On the contrary, I think it would make deploying and maintaining
>>> openstack easier... As each service implements its own DLM pieces
>>> this means that they all do it in a way that is different from each
>>> other, which actually makes the situation worse (now operators needs
>>> to figure out the X different ways this was done, the X different
>>> ways to release a messed up/stale/other lock...). DLM(s) like
>>> zookeeper and others provide that 'single' way of doing it (they
>>> also provide introspection abilities, ie to see who is waiting on a
>>> lock, what connection has a lock...) so IMHO I feel the question of
>>> should we has really already been passed (but others may disagree).
>>>
>>>
>>> I strongly agree that we are past the point of needing a DLM. We have
>>> mostly papered over the missing choice of a consistent DLM across
>>> projects with many different implementations. I'm all for picking a DLM
>>> that is consistent across all of OpenStack and help our deployers and
>>> operators only need to know one of these technologies. A single use of a
>>> DLM should not inflame the "technology proliferation" argument as long
>>> as we can be opinionated on the one we use and test against.
>>>
>>> Is the next step something x-project outlining the choices/direction so
>>> we can start that phase of the conversation? I am sure that once we have
>>> a clear direction, more and more use-cases will come out of the
>>> woodwork...
>>
>> I can start a cross-project spec tomorrow if people feel that is
>> useful, it may be slightly opinionated (I am one of the cores that
>> works on https://kazoo.readthedocs.org/ so I am going be slightly
>> biased for obvious reasons).
>
> By all means, go crazy!

Ok, craziness has commenced,

https://review.openstack.org/#/c/209661/

(WIP...)

>
> Flavio
>
> __________________________________________________________________________
> 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



More information about the OpenStack-dev mailing list