Ah here we go I had to dig, from: https://github.com/coreos/etcd/blob/master/Documentation/api.md
However, the watch command can do more than this. Using the index, we can watch for commands that have happened in the past. This is useful for ensuring you don't miss events between watch commands. Typically, we watch again from the (modifiedIndex + 1) of the node we got. Let's try to watch for the set command of index 7 again: curl 'http://127.0.0.1:2379/v2/keys/foo?wait=true&waitIndex=7' On Sat, Apr 11, 2015 at 3:24 PM, Camille Fournier <[email protected]> wrote: > For some reason I thought there were commands that took raft term/index > parameters and would show details over that but now I'm not seeing it so > perhaps I am just losing my mind. Too many consensus systems. > > On Sat, Apr 11, 2015 at 3:14 PM, Flavio Junqueira < > [email protected]> wrote: > >> What raft enhancements? >> >> -Flavio >> >> > On 11 Apr 2015, at 20:07, Camille Fournier <[email protected]> wrote: >> > >> > It does look like embedding the existing REST contrib into the servers >> > themselves would answer the use case I'm seeing. Then it might just be a >> > matter of making it clear that this option is available ;) >> > >> > We may also look to see what the API exposed by etcd/consul is. Perhaps >> a >> > generic API standard for accessing systems like this via HTTP would be >> > nice, for cross-compatibility. There are going to be some differences >> due >> > to the raft enhancements but the basics could be designed to be >> > cross-compatible. >> > >> > C >> > >> > On Sat, Apr 11, 2015 at 2:32 PM, Patrick Hunt <[email protected]> wrote: >> > >> >> We pack quite a bit of functionality in our client side libraries. >> That's >> >> probably one of the main things you'll noticed if you try to use REST. >> But >> >> then if your use case is primarily configuration, or something that >> doesn't >> >> require sessions then the current REST support should be more than >> >> sufficient. What are the other systems doing that we are currently not >> >> doing wrt API support? >> >> >> >> I'd think that taking our current rest contrib, updating the >> dependencies, >> >> and deploying as part of the embedded jetty would work well with >> minimal >> >> effort. >> >> >> >> Patrick >> >> >> >> On Sat, Apr 11, 2015 at 9:22 AM, Camille Fournier <[email protected]> >> >> wrote: >> >> >> >>> I agree that they have to write clients that do work, but there is >> >> clearly >> >>> a desire and willingness out there to do that work in exchange for a >> more >> >>> "obvious" way of interacting. So supporting it should be something >> that >> >> we >> >>> consider if the users of such systems want the option. >> >>> >> >>> On Sat, Apr 11, 2015 at 12:07 PM, Jordan Zimmerman < >> >>> [email protected]> wrote: >> >>> >> >>>> REST has issues for end users. They will still have to write clients >> >> and >> >>>> do a lot of extra work. REST support is good in most languages but >> >> having >> >>>> native support is superior. That’s why I choose Thrift for the >> >> CuratorRPC >> >>>> Proxy. >> >>>> >> >>>> -Jordan >> >>>> >> >>>> >> >>>> On April 10, 2015 at 9:32:47 PM, Michi Mutsuzaki ( >> >> [email protected]) >> >>>> wrote: >> >>>> >> >>>> Yeah it's quite painful to manage another set of processes just for >> >>>> proxying requests. I'd definitely use this if I can run it embedded >> in >> >>>> the ZooKeeper process. I'm very excited about the idea of being able >> >>>> to use curl to look at what's in ZooKeeper :) >> >>>> >> >>>> On Fri, Apr 10, 2015 at 6:03 PM, Patrick Hunt <[email protected]> >> >> wrote: >> >>>>> Here's the spec and readme from contrib/rest: >> >>>>> >> >>>>> >> >>>> >> >>> >> >> >> http://svn.apache.org/viewvc/zookeeper/trunk/src/contrib/rest/SPEC.txt?view=markup >> >>>>> >> >>>> >> >>> >> >> >> http://svn.apache.org/viewvc/zookeeper/trunk/src/contrib/rest/README.txt?view=markup >> >>>>> >> >>>>> The current implementation is a standalone proxy. It's not embedded >> >> in >> >>> zk >> >>>>> itself. That might be part of the reason. >> >>>>> >> >>>>> Patrick >> >>>>> >> >>>>> On Fri, Apr 10, 2015 at 4:43 PM, Camille Fournier < >> >> [email protected]> >> >>>>> wrote: >> >>>>> >> >>>>>> 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 >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>> >> >>>> >> >>> >> >> >> >> >
