>> That said, both etcd and consul are more k/v stores than they are distributed coordinators.
Not sure about consul, but for etcd v3, it seems has evolved towards a direction where more and more features that's critical for a coordinator is being added, instead of just a generic key value store. Some changes in v3 such as introduction of the concept of lease (ZK session) and the multiplexed gRPC streams allows more efficient implementation of watcher as well as features such as ephemeral nodes which is very useful for coordination use cases. Previously the v2 etcd seems stateless and it would be hard to implement session and ephemeral effectively on top of stateless server and API semantics. So it looks to me that etcd folks are very consciously improving it for coordination use cases, which made zetcd easier to implement as well. On Tue, May 23, 2017 at 6:57 AM, Patrick Hunt <ph...@apache.org> wrote: > Lots of different requirements out there. VMWare recently pushed this to > github: > > https://github.com/vmware/haret > https://github.com/vmware/haret/blob/master/docs/why.md > > Patrick > > > On Tue, May 23, 2017 at 3:33 AM, Flavio Junqueira <f...@apache.org> wrote: > > > Yeah, that's a good reference, thanks for starting the thread. > > > > @phunt > > I see a lot of systems trying to implement the API of others in the same > > space hoping that they can make the migration easier. I feel that it > isn't > > so much about us being a de facto standard, but more about the widespread > > use. Another point is that some applications have decided that they like > > etcd/Consul better, and they still need to have that pesky zookeeper > > because of some other dependency, e.g., Kafka. > > > > @jordan > > I'm really interested in your observation about the Consul herding. > Could > > you elaborate on the herding argument? Perhaps we should write a post > about > > it... > > > > -Flavio > > > > > On 20 May 2017, at 18:44, Jordan Zimmerman <jor...@jordanzimmerman.com > > > > wrote: > > > > > > I think they're trying to displace ZK for places that use things like > > Kafka too. They can make the argument that you can install Hashicorp > > everything and get rid of having to manage anything else. That said, both > > etcd and consul are more k/v stores than they are distributed > coordinators. > > I was playing around with Consul this past week and it's locking recipes > > are far inferior to ZooKeeper, for example (it suffers serious herding > when > > contending for a new lock holder). > > > > > > -Jordan > > > > > >> On May 20, 2017, at 6:40 PM, Patrick Hunt <ph...@apache.org> wrote: > > >> > > >> I saw that a few days ago, seems like it could be a real boon for > folks > > >> running in K8s (for example). The long term stability of our APIs > really > > >> reduce the pain of implementing something like this. Does Hashicorp > have > > >> something like this yet? > > >> > > >> If I knew ten years ago that we would become the standard I would have > > >> pushed harder to fix some of the rough(er) edges. ;-) > > >> > > >> Patrick > > >> > > >> On Fri, May 19, 2017 at 10:34 PM, Jordan Zimmerman < > > >> jor...@jordanzimmerman.com> wrote: > > >> > > >>> "The zetcd proxy sits in front of an etcd cluster and serves an > > emulated > > >>> ZooKeeper client port, letting unmodified ZooKeeper applications run > > on top > > >>> of etcd." > > >>> > > >>> https://coreos.com/blog/introducing-zetcd > > > > > > > > -- Cheers Michael.
