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