Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: pass (athena.apache.org: domain of andrew.purtell@gmail.com
 designates 209.85.213.44 as permitted sender)
Subject: Re: DISCUSSION: 1.0.0
References: 
 <CADcMMgEhM1rN4AsazErDAUqXO5fcCbgcRz+2nDXo9q2CQL=7jg@mail.gmail.com>
 <CA+RK=_AfdeyYXWBv9XBfbrerKeReo_p4WtFipUW3b85mnnyh7w@mail.gmail.com>
 <CA+RK=_A_qBBNDeyOtmC4LGvr3jLZc=YBoY=OvRJPJbnW-zgtvA@mail.gmail.com>
 <CAMUu0w8EQtkb-bHTGe_z-ZUNh60OKSx9qG-cdTse313JuS_68g@mail.gmail.com>
 <CA+RK=_AMVnOmkUbTPa0JCuz3FH0ps8piHKCKu7dFMh3vCAkCmg@mail.gmail.com>
 <CAHxLZBVx8ZH1zkNpDmM6RdeC4Q39UV95mXV3VaQvFAWwb1RGEA@mail.gmail.com>
 <CAOmV22sQX1RjgST1k=+1vy34E59qKSYJbswLknzjww2wewqHjg@mail.gmail.com>
 <CAHxLZBVef0eANjB8Px0nEkoEtv-Av4FuMS9ZGaMCbYPpj7nmwg@mail.gmail.com>
 <CADcMMgF9i=NcoAM-MBOb+sR5NbM0iK98-fM0nh8URF_gRg2rpQ@mail.gmail.com>
 <CAHxLZBXmSMZsm=UV=O-pF_BU9VzO+FU_K748ebdZT1ZiOiEV1w@mail.gmail.com>
 <CAMUu0w9pTtdXknOK5QWZBKDv25jO6wTcxC=yNoP9Tx_XY1wBbw@mail.gmail.com>
 <CAP+2gDpgj18U+SirjBtmhtd51n+rL5F378Tfy2G3yexFuFRSuA@mail.gmail.com>
From: Andrew Purtell <andrew.purtell@gmail.com>
Content-Type: text/plain;
	charset=utf-8
In-Reply-To: 
 <CAP+2gDpgj18U+SirjBtmhtd51n+rL5F378Tfy2G3yexFuFRSuA@mail.gmail.com>
Message-Id: <850563EF-C92B-499B-8B56-CCD573538854@gmail.com>
Date: Mon, 7 Jul 2014 10:01:35 -0700
To: "dev@hbase.apache.org" <dev@hbase.apache.org>
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)

Hi Aditya,

I think it would be good to have a native client API in 1.0. I can look at t=
he patches when back in the office later this week.=20


> On Jul 7, 2014, at 9:52 AM, Aditya <adityakishore@gmail.com> wrote:
>=20
> 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.
>=20
>=20
>> On Fri, Jul 4, 2014 at 1:21 AM, Enis S=C3=B6ztutar <enis.soz@gmail.com> w=
rote:
>>=20
>> On Thu, Jul 3, 2014 at 4:41 PM, Mikhail Antonov <olorinbant@gmail.com>
>> wrote:
>>=20
>>> Moved ZK watcher & listener subtask out of scope HBASE-10909. Enis - wit=
h
>>> that, I guess HBASE-10909 can be marked in branch-1?
>>=20
>> Sounds good.
>>=20
>>=20
>>>=20
>>> HBASE-11464 - this is the jira where I'll capture tasks to abstract hbas=
e
>>> client from ZK (mostly it would be post-1.0 work).
>>=20
>> Not sure whether we can make it fully backwards compatible with 1.0
>> clients. I guess we will see when the patches are done.
>>=20
>>=20
>>>=20
>>> Thanks,
>>> Mikhail
>>>=20
>>>=20
>>> 2014-07-03 12:52 GMT-07:00 Stack <stack@duboce.net>:
>>>=20
>>>> On Thu, Jul 3, 2014 at 12:25 PM, Mikhail Antonov <olorinbant@gmail.com
>>>=20
>>>> wrote:
>>>>=20
>>>>> Guys,
>>>>>=20
>>>>> 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:
>>>>>=20
>>>>> - 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.
>>>>=20
>>>> Sounds good to me.
>>>>=20
>>>>=20
>>>>> - 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.
>>>>=20
>>>> You have it right Mikhail.
>>>>=20
>>>> St.Ack
>>>=20
>>>=20
>>>=20
>>> --
>>> Thanks,
>>> Michael Antonov
>>=20