Hongchao, Instead of telling us we're misunderstanding things it would be great if you tried to explain them. I don't think anyone here is trying to misunderstand but we don't all have the time to become experts in multiple systems. Beyond that, what is it about etcd that makes them better from your perspective with respect to reliability and robustness?
Thanks C On Apr 12, 2015 7:05 PM, "Hongchao Deng" <[email protected]> wrote: > > > > I believe the etcd index and TTL are the major feature behind lease > implementation. If you think that's a great REST feature, you probably > misunderstanding it. > I think what we should take from etcd is reliability and robustness. How > can we better prevent data inconsistency when new features being added -- > CRC, mock network partition? After that, it's scalability, like the proxy > (or better observer) I described. > With reliability and scalability eased at mind, building a REST thing on > top is a great add-on. > - Hongchao Deng > > > Date: Sat, 11 Apr 2015 15:26:29 -0400 > > Subject: Re: design thoughts: node TTLs > > From: [email protected] > > To: [email protected] > > CC: [email protected]; [email protected] > > > > 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 > > >> >>>>>>>>> > > >> >>>>>>>>> > > >> >>>>>>>> > > >> >>>>>>> > > >> >>>>>>> > > >> >>>>>> > > >> >>>> > > >> >>> > > >> >> > > >> > > >> > > > > >
