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