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 <harlo...@outlook.com
<mailto:harlo...@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-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
