Open Stack

On Tue, Aug 04, 2015 at 05:47:44AM +1000, Morgan Fainberg wrote:
> 
> 
> > On Aug 4, 2015, at 01:42, Fox, Kevin M <Kevin.Fox at pnnl.gov> 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.
> > 
> 
> +1 and specifically around tooz, it is narrow in comparison to the feature sets of some the DLMs (since it has to mostly-implement to the lowest common denominator, as abstraction layers do). Defining the space we are trying to target will let us make the informed decision on what we use. 

Again with this?

We already what we want to get out of Tooz, where we want it and for how
long we'll be using it in each of those places.

To answer those questions all that's needed is to read this thread and
the links referred on some conversations.

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