On Tue, Aug 04, 2015 at 09:28:58AM +0000, Fox, Kevin M wrote: > Its been explained for Cinder, but not for other OpenStack projects that also > have needs in this area. >
For that, Flavio started a new thread "Does OpenStack need a common solution for DLM?" We are discussing Cinder specifics on this thread. Cheers, Gorka. > Thanks, > Kevin > > ________________________________ > From: Gorka Eguileor > Sent: Tuesday, August 04, 2015 1:39:07 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 06:12:23PM +0000, Fox, Kevin M wrote: > > For example, to parallel the conversation with databases: > > > > "We want a database". Well, that means mongodb, postgres, mysql, > > berkeleydb, etc.... > > > > "Oh, well, I need it to be a relational db", Well, that means postgresq, > > mysql, etc.... > > > > "Oh, and I need recursive queries"... that excludes even more. > > > > We are pretty sure "We want a distributed lock manager". What problems are > > we trying to solve using it, and what features do they require in the > > DLM/DLM Abstraction of choice? That will exclude some of them. It also may > > exclude abstraction layers that don't expose the features needed. > > (Recursive queries for example) > > > > Thanks, > > Kevin > > ________________________________________ > > Kevin all that has already been explained: > > http://gorka.eguileor.com/a-cinder-road-to-activeactive-ha/ > http://gorka.eguileor.com/simpler-road-to-cinder-active-active/ > > As well as on IRC and this thread, I don't see the point of repeating it > over and over again, at some point people need to start doing their > homework and read what's already been said to get up to speed on the > topic so we can move on. > > Gorka. > > > From: Gorka Eguileor [gegui...@redhat.com] > > Sent: Monday, August 03, 2015 10:48 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 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. > > > > Gorka. > > > > > > > > Thanks, > > > Kevin > > > ________________________________________ > > > 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. > > > > > > Cheers, > > > Gorka. > > > > > > __________________________________________________________________________ > > > 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 > > > > __________________________________________________________________________ > > 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 > > __________________________________________________________________________ > 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 __________________________________________________________________________ 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
