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 19:01:42 GMT
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