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