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).
Flavio
From: Gorka Eguileor [gegui...@redhat.com]
Sent: Monday, August 03, 2015 1:43 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Cinder] A possible solution for HA
Active-Active
On Mon, Aug 03, 2015 at 10:22:42AM +0200, Thierry Carrez wrote:
> Flavio Percoco wrote:
> > [...]
> > So, to summarize, I love the effort behind this. But, as others have
> > mentioned, I'd like us to take a step back, run this accross
teams and
> > come up with an opinonated solution that would work for everyone.
> >
> > Starting this discussion now would allow us to prepare enough
material
> > to reach an agreement in Tokyo and work on a single solution for
> > Mikata. This sounds like a good topic for a cross-project session.
>
> +1
>
> The last thing we want is to rush a solution that would only solve a
> particular project use case. Personally I'd like us to pick the
simplest
> solution that can solve most of the use cases. Each of the solutions
> bring something to the table -- Zookeeper is mature, Consul is
> featureful, etcd is lean and simple... Let's not dive into the best
> solution but clearly define the problem space first.
>
> --
> Thierry Carrez (ttx)
>
I don't see those as different solutions from the point of view of
Cinder, they are different implementations to the same solution case,
using a DLM to lock resources.
We keep circling back to the fancy names like moths to a flame, when we
are still discussing whether we need or want a DLM for the solution. I
think we should stop doing that, we need to decide on the solution from
an abstract point of view (like you say, define the problem space) and
not get caught up on discussions of which one of those is best. If we
end up deciding to use a DLM, which is unlikely, then we can look into
available drivers in Tooz and if we are not convinced with the ones we
have (Redis, ZooKeeper, etc.) then we discuss which one we should be
using instead and just add it to Tooz.
__________________________________________________________________________
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
