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.
-Sean
--
Sean Dague
http://dague.net
__________________________________________________________________________
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
