Moved ZK watcher & listener subtask out of scope HBASE-10909. Enis - with that, I guess HBASE-10909 can be marked in branch-1?
HBASE-11464 - this is the jira where I'll capture tasks to abstract hbase client from ZK (mostly it would be post-1.0 work). Thanks, Mikhail 2014-07-03 12:52 GMT-07:00 Stack <st...@duboce.net>: > On Thu, Jul 3, 2014 at 12:25 PM, Mikhail Antonov <olorinb...@gmail.com> > wrote: > > > Guys, > > > > getting back to ZK abstraction work w.r.t. release 1.0 and thereafter, > some > > status update. So as we're getting closer to complete HBASE-10909, it > looks > > like the steps may be like this: > > > > - there are 2 subtasks out there not closed yet, one of which is about > log > > splitting (and Sergey S has submitted a patch for review), another is > > abstraction of ZK watcher (this is what I've been working on in the > > background; but after sketching the patch it seems like without being > able > > to modify the control flows and some changes in the module structure, > it'd > > be a lot of scaffolding code not really simplifying current code). So I'd > > propose to descope abstraction of ZK watcher jira (HBASE-11073), namely: > > convert it to top-level JIRA and continue to work on it separately; > rename > > HBASE-10909 to "ZK abstraction: phase 1", and mark it as closed as soon > as > > log splitting jira is completed. This way HBASE-10909 fits to branch-1. > > > > Sounds good to me. > > > > - secondly, in the discussion to the CatalogTracker patch, we started > > talking about modifying client to not know about ZK, but rather keep the > > location of current masters and talk to them using RPC calls. This work > can > > not go into branch-1, as it involves invasive changes in client including > > new RPC. As I understand the branching schema now, those changes can go > to > > master branch, we just don't merge them to branch-1, and depending on > their > > completeness we can pull them to 1.1 release or so. > > > > You have it right Mikhail. > > St.Ack > -- Thanks, Michael Antonov
