hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aditya <adityakish...@gmail.com>
Subject Re: DISCUSSION: 1.0.0
Date Mon, 07 Jul 2014 16:52:00 GMT
Do we want to have the C APIs part of 1.0.0 release. I had posted few
patches and a set of review request sometime last week.


On Fri, Jul 4, 2014 at 1:21 AM, Enis Söztutar <enis.soz@gmail.com> wrote:

> On Thu, Jul 3, 2014 at 4:41 PM, Mikhail Antonov <olorinbant@gmail.com>
> wrote:
>
> > Moved ZK watcher & listener subtask out of scope HBASE-10909. Enis - with
> > that, I guess HBASE-10909 can be marked in branch-1?
> >
>
> Sounds good.
>
>
> >
> > 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).
> >
>
> Not sure whether we can make it fully backwards compatible with 1.0
> clients. I guess we will see when the patches are done.
>
>
> >
> > 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