hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mikhail Antonov <olorinb...@gmail.com>
Subject Re: DISCUSSION: 1.0.0
Date Thu, 03 Jul 2014 23:41:06 GMT
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 <stack@duboce.net>:

> On Thu, Jul 3, 2014 at 12:25 PM, Mikhail Antonov <olorinbant@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message