Open Stack

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 [geguileo at 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 [geguileo at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev