hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Dimiduk <ndimi...@gmail.com>
Subject Re: DISCUSSION: 1.0.0
Date Wed, 09 Jul 2014 18:32:00 GMT
This ticket has only open subtasks, ie nothing in 'patch available'. I
assume you mean HBASE-10168. We'll see about getting you some reviews, but
you should also go about formatting the patch for buildbot. Also, since
your 3 reviews are individually 100+k, you should consider breaking them
into three separate tickets.

my 2¢
-n


On Mon, Jul 7, 2014 at 12:01 PM, Aditya <adityakishore@gmail.com> wrote:

> Sorry about that.
>
> Here is the umbrella JIRA https://issues.apache.org/jira/browse/HBASE-1015
>
>
> On Mon, Jul 7, 2014 at 10:05 AM, Nick Dimiduk <ndimiduk@gmail.com> wrote:
>
>> Would you mind including the JIRA numbers along with the request?
>>
>> Thanks,
>> Nick
>>
>>
>> On Mon, Jul 7, 2014 at 9:52 AM, Aditya <adityakishore@gmail.com> wrote:
>>
>>> 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