[openstack-dev] [oslo][kolla][openstack-helm][tripleo][all] Storing configuration options in etcd(?)

Thierry Carrez thierry at openstack.org
Wed Mar 15 10:14:44 UTC 2017

Joshua Harlow wrote:
> Monty Taylor wrote:
>> On 03/14/2017 06:04 PM, Davanum Srinivas wrote:
>>> PS: Between this thread and the other one about Tooz/DLM and
>>> os-lively, we can probably make a good case to add etcd as a base
>>> always-on service.
>> As I mentioned in the other thread, there was specific and strong
>> anti-etcd sentiment in Tokyo which is why we decided to use an
>> abstraction. I continue to be in favor of us having one known service in
>> this space, but I do think that it's important to revisit that decision
>> fully and in context of the concerns that were raised when we tried to
>> pick one last time.
> I'm in agreement with this.
> I don't mind tooz either (it's good at what it is for) since I took a
> part in creating it... Given that I can't help but wonder how nice it
> would be to pick one (etcd, zookeeper, consul?) and just do nice things
> with it (perhaps u know even work with the etcd or zookeeper or consul
> developers [depending on which one we pick] on features and bug fixes
> and such).

If I remember correctly:

- the root of the anti-etcd sentiment was that it was less featureful
than ZooKeeper/Consul (I remember arguments that ZooKeeper was the only
one to do DLM correctly)

- the root of the anti-ZK sentiment was that it was a Java stack, which
comes with some extra complexity, some operational baggage and some
licensing concerns.

so it felt like enabling all three through an abstraction library would
give operators choice, and the features we needed actually led
themselves to abstraction well.

Now, a number of things happened since then:

- etcd3 is widely seen as doing DLM features as well as ZooKeeper or
Consul, and has closed (some say even surpassed) the performance gap

- as each day passes we (OpenStack) are growing a stronger
complementarity with the Kubernetes ecosystem, which relies on etcd as a
base service extensively

So unless someone can make an argument that Zookeeper has technical
benefits that etcd3 can't provide (and therefore should be kept as one
option under an abstraction layer), it's still time to directly pick
etcd3 as a base service. Skip the expand step if unnecessary, and go
directly to the contract phase.

PS: Nobody mentions Consul anymore -- In all cases I don't think it
provides any extra value to us over etcd3 that would justify the cost of
maintaining an abstraction driver for it.

Thierry Carrez (ttx)

More information about the OpenStack-dev mailing list