Open Stack

On Tue, Aug 4, 2015 at 8:44 AM, Joshua Harlow <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...

--Morgan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150804/ea60569e/attachment.html>