Forgive me for not reading the code, can you share in more detail what the existing REST proxy provides? I'm curious why people are jumping to use etcd because of ease of use w/http access if we already have something that works?
On Fri, Apr 10, 2015 at 7:28 PM, Patrick Hunt <[email protected]> wrote: > There's the REST work in contrib. Both Andrei and I worked on that - I did > the basic support and Andrei added sessions and heartbeating among other > improvements. > > Now that 3.5 has embedded Jetty it should be much simpler to run REST as > part of the ZK service itself. When the original proxy work was done Jetty > was not yet part of ZK. > > Patrick > > On Thu, Apr 9, 2015 at 10:20 AM, Jordan Zimmerman < > [email protected]> wrote: > >> Since Curator is now Apache and I’m no longer at Netflix, I don’t follow >> Netflix messages very much. Sorry about that. >> >> -Jordan >> >> >> >> On April 9, 2015 at 12:15:02 PM, Camille Fournier ([email protected]) >> wrote: >> >> Thanks Jordan! I actually asked on Twitter whether Netflix had anything >> but >> didn't get a clear answer. >> >> On Thu, Apr 9, 2015 at 11:22 AM, Jordan Zimmerman < >> [email protected]> wrote: >> >> > FYI >> > >> > Curator now has a Thrift-based proxy that has all the ZK APIs exposed as >> > well as Curator’s added APIs and recipes: >> > >> > http://curator.apache.org/curator-x-rpc/index.html >> > >> > -Jordan >> > >> > On April 8, 2015 at 2:09:33 PM, Camille Fournier ([email protected]) >> > wrote: >> > >> > All, >> > >> > I've been doing a bit of research on etcd as part of work for an >> upcoming >> > talk, and it has gotten me thinking about what it would take to create >> an >> > http version of ZK for certain operations. For many operations you could >> > put an http proxy in front of ZK to translate, even implementing the >> > "long-poll-style" watch operation to some extent. But it would be very >> > hard >> > to do a temporary node via a proxy without a lot of proxy failover >> > complexity. >> > >> > As a bit of background, if you want to do an "ephemeral" node in etcd, >> you >> > basically create a key with a TTL. Unless the key is updated with a new >> > TTL, the key will auto-expire when the TTL is reached. Now, I have a lot >> > of >> > thoughts about this (seems like you have to implement heartbeats via >> http >> > to truly mimic ephemeral nodes which may not be as simple as all this >> http >> > sounds), but I do think that if there is appetite for easy http access >> for >> > consensus systems we should at least take the time to think about what >> it >> > would take for us to provide this. In particular, I think we'd have to >> > make >> > it possible to create a node with a TTL that is not tied to a particular >> > session. >> > >> > Curious to see if anyone has any thoughts on this. It seems like a bit >> of >> > a >> > shame that ZK, which is a good battle-tested system, is frequently being >> > passed-over these days because of the complexity of clients, and the >> fact >> > that it is really pretty damn hard to do a client impl in certain >> > languages >> > (Ruby is the notable one I've heard). >> > >> > Best, >> > C >> > >> > >> > >
