> > This brings up another point, I’d like to see if we can somehow collapse > overseer election with overseer role advertising I would be strongly in > favor of that. >
It would seem natural to move it into this structure, I agree, though that might be done in a follow on ticket. > > Or Zk nodes might want to record the desired redundancy for zk, and how >> long past zk nodes have been down to bring up another zk from the pool of >> zk nodes if some timeout has been exceeded... And Ilan gave an example I >> don't recall at the moment that persuaded me that we can't really predict >> what each role wants to tack so my capable vs providing distinction got >> converted to a space in the struture (peer to nodes) to track any such info >> that a role needs to. thus namespacing role related stuff, enabling >> recursive watch if desired, >> > > Yikes. Let’s figure out how to partition the data such that we don’t need > every node in the cluster watching every znode. I need to think about this > some more to convince myself we’re not in that space right now. > A) not yet thinking of a good use case for it, and B) want to check that you realize that I am referring to the newish feature described here: https://zookeeper.apache.org/doc/r3.6.1/zookeeperProgrammers.html#sc_WatchPersistentRecursive and not recursively setting many watches on a whole tree :) -- http://www.needhamsoftware.com (work) http://www.the111shift.com (play)
