Open Stack

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).

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