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