Open Stack

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!

Flavio

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150805/8f2a39c4/attachment.pgp>