On 15 March 2017 at 12:33, Sean Dague <s...@dague.net> wrote: > On 03/15/2017 08:10 AM, John Garbutt wrote: >> On 15 March 2017 at 11:58, Jay Pipes <jaypi...@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.
Good point. +1 to collecting the patterns. Thats the bit I didn't want to throw away. Thanks, John __________________________________________________________________________ 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
