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