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) __________________________________________________________________________ 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