To the question of "TTL not tied to session": As far as I know (and again, if we have any etcd experts in the house I'd like to hear otherwise) TTL is an attempt to make auto-cleanup happen when you have a stateless client model, aka, http. That is the point. You can disagree that this is useful but it is pretty hard to have a stateless-based system with sessions required if you want to create nodes that clean themselves up. There is clear evidence that people are having a lot of trouble writing clients for ZK especially in languages like Ruby, and both of the major alternatives out there, etcd and Consul, rely on http-based APIs (although Consul has some session stuff going on under the covers that I honestly don't understand yet so it may do more magic with that).
Spitballing, I think that you'd want to create a special monitor for TTL'ed nodes that tracked their last touch and auto-deleted on timeout, kind of the same way we do with sessions only not with the session-specific heartbeat, but via an explicit TTL update via an update on that node. Does that make sense? For the rest: I don't know enough about http2 to comment on that, maybe that is the right way to go :) Hongchao: Distributed version management, meaning, the version of the data in a node? Don't we kind of have that implicitly in the xids? Could we expose that, if it is useful? C On Wed, Apr 8, 2015 at 4:31 PM, Hongchao Deng <[email protected]> wrote: > 1. http?http is going to be out of date soon.. I would suggest http2 based > grpc: > http://www.grpc.io/ > It also facilitates other client language choices. > 2. ttl?If you want to create an ephemeral node, TTL isn't a good design. > The notion of TTL comes from the lease in Chubby. > It's all about motivations. IIUC, ZooKeeper was built for:- configuration > management (metadata store)- leader election > Other than these two, etcd provides one more: distributed version > management. This is related to Kubernetes design. > 3. redesign?Any plan to start ZK-4? A summer project would be enough to > start :) > - Hongchao Deng > > > Date: Wed, 8 Apr 2015 15:09:25 -0400 > > Subject: design thoughts: node TTLs > > From: [email protected] > > To: [email protected] > > > > 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 > >
