Open Stack

On Wed, 2017-03-15 at 08:33 -0400, Sean Dague wrote:
> On 03/15/2017 08:10 AM, John Garbutt wrote:
> > On 15 March 2017 at 11:58, Jay Pipes <jaypipes at gmail.com> wrote:
> > > On 03/15/2017 07:44 AM, Sean Dague wrote:
> > > > 
> > > > On 03/14/2017 11:00 PM, Monty Taylor wrote:
> > > > <snip>
> > > > > 
> > > > > a) awesome. when the rest of this dips momentarily into words
> > > > > that might
> > > > > sound negative, please hear it all wrapped in an "awesome"
> > > > > and know that
> > > > > my personal desire is to see the thing you're working on be
> > > > > successful
> > > > > without undue burden...
> > > > > 
> > > > > b) In Tokyo, we had the big discussion about DLMs (where at
> > > > > least my
> > > > > intent going in to the room was to get us to pick one and
> > > > > only one).
> > > > > There were three camps in the room who were all vocal:
> > > > > 
> > > > > 1) YES! Let's just pick one, I don't care which one
> > > > > 2) I hate Java I don't want to run Zookeeper, so we can't
> > > > > pick that
> > > > > 3) I hate go/don't trust coreos I don't want to run etcd so
> > > > > we can't
> > > > > pick that
> > > > > 
> > > > > Because of 2 and 3 the group represented by 1 lost and we
> > > > > ended up with:
> > > > > "crap, we have to use an abstraction library"
> > > > > 
> > > > > I'd argue that unless something has changed significantly,
> > > > > having Nova
> > > > > grow a direct depend on etcd when the DLM discussion brought
> > > > > us to "the
> > > > > operators in the room have expressed a need for a pluggable
> > > > > choice
> > > > > between at least zk and etcd" should be pretty much a non-
> > > > > starter.
> > > > > 
> > > > > Now, being that I was personally in group 1, I'd be THRILLED
> > > > > if we
> > > > > could, as a community, decide to pick one and skip having an
> > > > > abstraction
> > > > > library. I still don't care which one - and you know I love
> > > > > gRPC/protobuf.
> > > > > 
> > > > > But I do think that given the anti-etcd sentiment that was
> > > > > expressed was
> > > > > equally as vehement as the anti-zk sentiment, that we need to
> > > > > circle
> > > > > back and make a legit call on this topic.
> > > > > 
> > > > > If we can pick one, I think having special-purpose libraries
> > > > > like
> > > > > os-lively for specific purposes would be neat.
> > > > > 
> > > > > If we still can't pick one, then I think adding the liveness
> > > > > check you
> > > > > implemented for os-lively as a new feature in tooz and also
> > > > > implementing
> > > > > the same thing in the zk driver would be necessary. (of
> > > > > course, that'll
> > > > > probably depend on getting etcd3 support added to tooz and
> > > > > making sure
> > > > > there is a good functional test for etcd3.
> > > > 
> > > > 
> > > > We should also make it clear that:
> > > > 
> > > > 1) Tokyo was nearly 1.5 years ago.
> > > > 2) Many stake holders in openstack with people in that room may
> > > > no
> > > > longer be part of our community
> > > > 3) Alignment with Kubernetes has become something important at
> > > > many
> > > > levels inside of OpenStack (which puts some real weight on the
> > > > etcd front)
> > > 
> > > 
> > > Yes, and even more so for etcd3 vs. etcd2, since a) k8s now uses
> > > etcd3 and
> > > b) etcd2 is no longer being worked on.
> > > 
> > > > 4) The containers ecosystem, which etcd came out of, has
> > > > matured
> > > > dramatically
> > 
> > +1 for working towards etcd3 a "base service", based on operator
> > acceptance.
> > +1 for liveness checks not causing silly DB churn.
> > 
> > While we might not need/want an abstraction layer to hide the
> > differences between different backends, but a library (tooz and/or
> > os-lively) so we all consistently use the tool seems to make sense.
> > 
> > Maybe that means get tooz using etcd3 (Julian or Jay, or both maybe
> > seemed keen?)
> > Maybe the tooz API adds bits from the os-lively POC?
> 
> I do have a concern where we immediately jump to a generic
> abstraction,
> instead of using the underlying technology to the best of our
> ability.
> It's really hard to break down and optimize the abstractions later.
> We've got all sorts of cruft (an inefficiencies) in our DB access
> layer
> because of this (UUIDs stored as UTF8 strings being a good example).
> 
> I'd definitely be more interested in etcd3 as a defined base service,
> people can use it directly. See what kind of patterns people come up
> with. Abstract late once the patterns are there.

I'm not involved in Oslo or Devstack, so not really a say in this, but:

Yes! A 1000 times yes! An 'abstraction' with only a single
implementation is (1) almost by definition not an abstraction, and (2)
in 99% of the cases just exposing a crippled version of the underlying
system's features.
Furthermore, adding a second implementation of the interface backed by
another system at some later point in time turns out to be difficult
(or impossible) because the 'abstraction' turns out to be (involuntary)
overly tied to initial backend specifics.

Been preaching this for ages, thanks for confirming ;)

Nicolas

-- 
 
<http://go.scality.com/acton/media/18585/gartner-magic-quadrant-object-storage?utm_campaign=MQ&utm_medium=Email&utm_source=signatures>