Open Stack

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)
4) The containers ecosystem, which etcd came out of, has matured
dramatically

I do think this is enough change to when that decision was made to
revisit. As was said elsewhere in this thread, you have to run etcd for
kubernetes, so picking that (in an opinionated way) for OpenStack seems
like a good both technical and social call.

	-Sean

-- 
Sean Dague
http://dague.net