Re: FYI - zetcd: running ZooKeeper apps without ZooKeeper

[Michael Han]

>> 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  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  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  >
> > 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  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.

Re: FYI - zetcd: running ZooKeeper apps without ZooKeeper

[Patrick Hunt]

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

Re: FYI - zetcd: running ZooKeeper apps without ZooKeeper

[Jordan Zimmerman]

> @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...

Here's their recipe for Leader Election (which is the same as a lock in this 
case): https://www.consul.io/docs/guides/leader-election.html 


curl -X PUT -d  http://localhost:8500/v1/kv/?acquire= 

Note that a given session can not hold the same lock more than once. ZooKeeper 
is better here - a single client can have multiple threads participating in the 
same lock
If you don't get the lock via the first call, you start "Watching for changes 
... via a blocking query against ."
In their API, the way you watch for changes is to use what they call "blocking 
queries": https://www.consul.io/api/index.html#blocking-queries 
 - whereby "the HTTP 
request will "hang" until a change in the system occurs, or the maximum timeout 
is reached. ". In other words, when the lock is released all watchers are 
notified - i.e. a herd (also not fair). ZooKeeper is superior here because of 
sequential ephemeral nodes. A client waiting for a lock only watches the node 
the precedes him. This has the benefit of being fair and not causing a herd.

-JZ

Re: FYI - zetcd: running ZooKeeper apps without ZooKeeper

[Flavio Junqueira]

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

Re: FYI - zetcd: running ZooKeeper apps without ZooKeeper

[Jordan Zimmerman]

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

Re: FYI - zetcd: running ZooKeeper apps without ZooKeeper

[Patrick Hunt]

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

FYI - zetcd: running ZooKeeper apps without ZooKeeper

[Jordan Zimmerman]

"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