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

Reply via email to