zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Han <h...@cloudera.com>
Subject Re: FYI - zetcd: running ZooKeeper apps without ZooKeeper
Date Wed, 24 May 2017 05:12:01 GMT
>> 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 <phunt@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 <fpj@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 <jordan@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 <phunt@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 <
> > >> jordan@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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message