You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@hbase.apache.org by Stack <st...@duboce.net> on 2014/06/02 19:11:49 UTC

Re: DISCUSSION: 1.0.0

1.0.0 has been going on for a while now.  Master has a bunch of good stuff
in it .  What are we thinking of as a release date for the first 0.99.0 and
for 1.0.0 itself?

Thanks,
St.Ack




On Thu, Jan 2, 2014 at 11:26 AM, Stack <st...@duboce.net> wrote:

> Andrew is talking of the first 0.98RC being imminent.
>
> Time to start in on the release that will follow 0.98.x.  We seem to all
> be good with calling it 1.0.0.  Speak up if you think different. (I just
> added a 1.0.0 version to JIRA).
>
> + What should 1.0.0 have in it beyond what is in 0.98.
> + Why can't 1.0.0 just be 0.98.0, or 0.98.1 altogether?
> + When should it come out?  I'm thinking soon after 0.98. Feb/March?
> (Presuming 0.98 ships in Jan).
> + Who should RM it? (I could but perhaps others are interested).
>
> What else should we consider achieving the state of 1.0.0ness?
>
> Happy New Year all,
> St.Ack
>
>
>
>
>

Re: DISCUSSION: 1.0.0

Posted by Ted Yu <yu...@gmail.com>.

We're on the same page, Enis.

Cheers


On Mon, Jul 7, 2014 at 10:56 AM, Enis Söztutar <en...@apache.org> wrote:

> I think it is fair to say for both C API and transaction API that it should
> be ok to include them if they are ready before the time to cut the 1.0 RC.
> If not, I do not want to hold the release waiting for those.
>
> Enis
>
>
> On Mon, Jul 7, 2014 at 10:50 AM, Andrew Purtell <an...@gmail.com>
> wrote:
>
> > And by definition of that being a proposed design, there is no
> > implementation to track (yet). There being no implementation, it's hard
> to
> > see how it makes a 1.0 happening "soon".
> >
> > Don't misunderstand me to be opposed to the idea or feature, far from it.
> > I don't think Ted did anyone a service bringing it up in the context of
> > 1.0. Already we are on some kind of detour from discussing things where
> > there are patches available.
> >
> >
> > > On Jul 7, 2014, at 10:43 AM, Mikhail Antonov <ol...@gmail.com>
> > wrote:
> > >
> > > I thought the scope of HBASE-11447 is to review and refine proposed
> > design,
> > > not to track the implementation of the feature?
> > >
> > > -Mikhail
> > >
> > >
> > > 2014-07-07 10:40 GMT-07:00 Andrew Purtell <an...@gmail.com>:
> > >
> > >> That is not a realistic proposal for 1.0 as far as I can see. There is
> > >> only a tentative design spec on that issue. I assume we are sticking
> > with
> > >> Enis' earlier stated intent to get 1.0 out "soon".
> > >>
> > >>
> > >>> On Jul 7, 2014, at 10:30 AM, Ted Yu <yu...@gmail.com> wrote:
> > >>>
> > >>> The following is another candidate for 1.0.0 release
> > >>>
> > >>> HBASE-11447 Proposal for a generic transaction API for HBase
> > >>>
> > >>> Cheers
> > >>>
> > >>>
> > >>>> On Mon, Jul 7, 2014 at 9:52 AM, Aditya <ad...@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 <en...@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 <st...@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
> > >
> > >
> > >
> > > --
> > > Thanks,
> > > Michael Antonov
> >
>

Re: DISCUSSION: 1.0.0

Posted by lars hofhansl <la...@apache.org>.

And since they are both strictly additional we can add them at any time later without risking breaking anything existing.



________________________________
 From: Enis Söztutar <en...@apache.org>
To: "dev@hbase.apache.org" <de...@hbase.apache.org> 
Sent: Monday, July 7, 2014 7:56 PM
Subject: Re: DISCUSSION: 1.0.0
 

I think it is fair to say for both C API and transaction API that it should
be ok to include them if they are ready before the time to cut the 1.0 RC.
If not, I do not want to hold the release waiting for those.

Enis





On Mon, Jul 7, 2014 at 10:50 AM, Andrew Purtell <an...@gmail.com>
wrote:

> And by definition of that being a proposed design, there is no
> implementation to track (yet). There being no implementation, it's hard to
> see how it makes a 1.0 happening "soon".
>
> Don't misunderstand me to be opposed to the idea or feature, far from it.
> I don't think Ted did anyone a service bringing it up in the context of
> 1.0. Already we are on some kind of detour from discussing things where
> there are patches available.
>
>
> > On Jul 7, 2014, at 10:43 AM, Mikhail Antonov <ol...@gmail.com>
> wrote:
> >
> > I thought the scope of HBASE-11447 is to review and refine proposed
> design,
> > not to track the implementation of the feature?
> >
> > -Mikhail
> >
> >
> > 2014-07-07 10:40 GMT-07:00 Andrew Purtell <an...@gmail.com>:
> >
> >> That is not a realistic proposal for 1.0 as far as I can see. There is
> >> only a tentative design spec on that issue. I assume we are sticking
> with
> >> Enis' earlier stated intent to get 1.0 out "soon".
> >>
> >>
> >>> On Jul 7, 2014, at 10:30 AM, Ted Yu <yu...@gmail.com> wrote:
> >>>
> >>> The following is another candidate for 1.0.0 release
> >>>
> >>> HBASE-11447 Proposal for a generic transaction API for HBase
> >>>
> >>> Cheers
> >>>
> >>>
> >>>> On Mon, Jul 7, 2014 at 9:52 AM, Aditya <ad...@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 <en...@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 <st...@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
> >
> >
> >
> > --
> > Thanks,
> > Michael Antonov
>

Re: DISCUSSION: 1.0.0

Posted by Jonathan Hsieh <jo...@cloudera.com>.

I agree.  These are fine things we could get in  1.1 or 1.2 release if they
don't break compat and otherwise a 2.0 release timeframe.

Jon.


On Mon, Jul 7, 2014 at 10:56 AM, Enis Söztutar <en...@apache.org> wrote:

> I think it is fair to say for both C API and transaction API that it should
> be ok to include them if they are ready before the time to cut the 1.0 RC.
> If not, I do not want to hold the release waiting for those.
>
> Enis
>
>
> On Mon, Jul 7, 2014 at 10:50 AM, Andrew Purtell <an...@gmail.com>
> wrote:
>
> > And by definition of that being a proposed design, there is no
> > implementation to track (yet). There being no implementation, it's hard
> to
> > see how it makes a 1.0 happening "soon".
> >
> > Don't misunderstand me to be opposed to the idea or feature, far from it.
> > I don't think Ted did anyone a service bringing it up in the context of
> > 1.0. Already we are on some kind of detour from discussing things where
> > there are patches available.
> >
> >
> > > On Jul 7, 2014, at 10:43 AM, Mikhail Antonov <ol...@gmail.com>
> > wrote:
> > >
> > > I thought the scope of HBASE-11447 is to review and refine proposed
> > design,
> > > not to track the implementation of the feature?
> > >
> > > -Mikhail
> > >
> > >
> > > 2014-07-07 10:40 GMT-07:00 Andrew Purtell <an...@gmail.com>:
> > >
> > >> That is not a realistic proposal for 1.0 as far as I can see. There is
> > >> only a tentative design spec on that issue. I assume we are sticking
> > with
> > >> Enis' earlier stated intent to get 1.0 out "soon".
> > >>
> > >>
> > >>> On Jul 7, 2014, at 10:30 AM, Ted Yu <yu...@gmail.com> wrote:
> > >>>
> > >>> The following is another candidate for 1.0.0 release
> > >>>
> > >>> HBASE-11447 Proposal for a generic transaction API for HBase
> > >>>
> > >>> Cheers
> > >>>
> > >>>
> > >>>> On Mon, Jul 7, 2014 at 9:52 AM, Aditya <ad...@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 <en...@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 <st...@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
> > >
> > >
> > >
> > > --
> > > Thanks,
> > > Michael Antonov
> >
>



-- 
// Jonathan Hsieh (shay)
// HBase Tech Lead, Software Engineer, Cloudera
// jon@cloudera.com // @jmhsieh

Re: DISCUSSION: 1.0.0

Posted by Enis Söztutar <en...@apache.org>.

I think it is fair to say for both C API and transaction API that it should
be ok to include them if they are ready before the time to cut the 1.0 RC.
If not, I do not want to hold the release waiting for those.

Enis


On Mon, Jul 7, 2014 at 10:50 AM, Andrew Purtell <an...@gmail.com>
wrote:

> And by definition of that being a proposed design, there is no
> implementation to track (yet). There being no implementation, it's hard to
> see how it makes a 1.0 happening "soon".
>
> Don't misunderstand me to be opposed to the idea or feature, far from it.
> I don't think Ted did anyone a service bringing it up in the context of
> 1.0. Already we are on some kind of detour from discussing things where
> there are patches available.
>
>
> > On Jul 7, 2014, at 10:43 AM, Mikhail Antonov <ol...@gmail.com>
> wrote:
> >
> > I thought the scope of HBASE-11447 is to review and refine proposed
> design,
> > not to track the implementation of the feature?
> >
> > -Mikhail
> >
> >
> > 2014-07-07 10:40 GMT-07:00 Andrew Purtell <an...@gmail.com>:
> >
> >> That is not a realistic proposal for 1.0 as far as I can see. There is
> >> only a tentative design spec on that issue. I assume we are sticking
> with
> >> Enis' earlier stated intent to get 1.0 out "soon".
> >>
> >>
> >>> On Jul 7, 2014, at 10:30 AM, Ted Yu <yu...@gmail.com> wrote:
> >>>
> >>> The following is another candidate for 1.0.0 release
> >>>
> >>> HBASE-11447 Proposal for a generic transaction API for HBase
> >>>
> >>> Cheers
> >>>
> >>>
> >>>> On Mon, Jul 7, 2014 at 9:52 AM, Aditya <ad...@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 <en...@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 <st...@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
> >
> >
> >
> > --
> > Thanks,
> > Michael Antonov
>

Re: DISCUSSION: 1.0.0

Posted by Andrew Purtell <an...@gmail.com>.

And by definition of that being a proposed design, there is no implementation to track (yet). There being no implementation, it's hard to see how it makes a 1.0 happening "soon". 

Don't misunderstand me to be opposed to the idea or feature, far from it. I don't think Ted did anyone a service bringing it up in the context of 1.0. Already we are on some kind of detour from discussing things where there are patches available. 


> On Jul 7, 2014, at 10:43 AM, Mikhail Antonov <ol...@gmail.com> wrote:
> 
> I thought the scope of HBASE-11447 is to review and refine proposed design,
> not to track the implementation of the feature?
> 
> -Mikhail
> 
> 
> 2014-07-07 10:40 GMT-07:00 Andrew Purtell <an...@gmail.com>:
> 
>> That is not a realistic proposal for 1.0 as far as I can see. There is
>> only a tentative design spec on that issue. I assume we are sticking with
>> Enis' earlier stated intent to get 1.0 out "soon".
>> 
>> 
>>> On Jul 7, 2014, at 10:30 AM, Ted Yu <yu...@gmail.com> wrote:
>>> 
>>> The following is another candidate for 1.0.0 release
>>> 
>>> HBASE-11447 Proposal for a generic transaction API for HBase
>>> 
>>> Cheers
>>> 
>>> 
>>>> On Mon, Jul 7, 2014 at 9:52 AM, Aditya <ad...@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 <en...@gmail.com>
>> wrote:
>>>>> 
>>>>> On Thu, Jul 3, 2014 at 4:41 PM, Mikhail Antonov <ol...@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 <st...@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
> 
> 
> 
> -- 
> Thanks,
> Michael Antonov

Re: DISCUSSION: 1.0.0

Posted by Mikhail Antonov <ol...@gmail.com>.

I thought the scope of HBASE-11447 is to review and refine proposed design,
not to track the implementation of the feature?

-Mikhail


2014-07-07 10:40 GMT-07:00 Andrew Purtell <an...@gmail.com>:

> That is not a realistic proposal for 1.0 as far as I can see. There is
> only a tentative design spec on that issue. I assume we are sticking with
> Enis' earlier stated intent to get 1.0 out "soon".
>
>
> > On Jul 7, 2014, at 10:30 AM, Ted Yu <yu...@gmail.com> wrote:
> >
> > The following is another candidate for 1.0.0 release
> >
> > HBASE-11447 Proposal for a generic transaction API for HBase
> >
> > Cheers
> >
> >
> >> On Mon, Jul 7, 2014 at 9:52 AM, Aditya <ad...@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 <en...@gmail.com>
> wrote:
> >>>
> >>> On Thu, Jul 3, 2014 at 4:41 PM, Mikhail Antonov <ol...@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 <st...@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
> >>
>



-- 
Thanks,
Michael Antonov

Re: DISCUSSION: 1.0.0

Posted by Andrew Purtell <an...@gmail.com>.

That is not a realistic proposal for 1.0 as far as I can see. There is only a tentative design spec on that issue. I assume we are sticking with Enis' earlier stated intent to get 1.0 out "soon". 


> On Jul 7, 2014, at 10:30 AM, Ted Yu <yu...@gmail.com> wrote:
> 
> The following is another candidate for 1.0.0 release
> 
> HBASE-11447 Proposal for a generic transaction API for HBase
> 
> Cheers
> 
> 
>> On Mon, Jul 7, 2014 at 9:52 AM, Aditya <ad...@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 <en...@gmail.com> wrote:
>>> 
>>> On Thu, Jul 3, 2014 at 4:41 PM, Mikhail Antonov <ol...@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 <st...@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
>>

Re: DISCUSSION: 1.0.0

Posted by Ted Yu <yu...@gmail.com>.

The following is another candidate for 1.0.0 release

HBASE-11447 Proposal for a generic transaction API for HBase

Cheers


On Mon, Jul 7, 2014 at 9:52 AM, Aditya <ad...@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 <en...@gmail.com> wrote:
>
> > On Thu, Jul 3, 2014 at 4:41 PM, Mikhail Antonov <ol...@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 <st...@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
> > >
> >
>

Re: DISCUSSION: 1.0.0

Posted by Andrew Purtell <an...@gmail.com>.

Hi Aditya,

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


> On Jul 7, 2014, at 9:52 AM, Aditya <ad...@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 <en...@gmail.com> wrote:
>> 
>> On Thu, Jul 3, 2014 at 4:41 PM, Mikhail Antonov <ol...@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 <st...@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
>>

Re: DISCUSSION: 1.0.0

Posted by Mikhail Antonov <ol...@gmail.com>.

My 2 cents..

 - HBASE-10909 is pretty much completed, the only outstanding subtask is
about WAL splitting (HBASE-11072), and we seem to be on-track here (the
patch was/is being reviewed, thanks a lot for all the reviews!, and now
looks really close to the state when it could be committed I guess). I hope
this one will be finished coming week or a week after that.
 - On abstracting ZK client (HBASE-11464), and in particular, rewiring
clients connections to cluster (HBASE-11467), that's in progress and
patches are there for reviews and feedbacks, but these ones don't seem to
be fittable into 1.0.0 anyway, as they change cluster topology...Same for
coordination engine work (HADOOP-10641).

I may have capacity to review some patches if that would be useful.

-Mikhail




2014-08-24 18:19 GMT-07:00 Enis Söztutar <en...@gmail.com>:

> Hey,
>
> Yeah, was busy with something else (HBASE-10070 subtasks) for the last
> couple of weeks. I intend to get back to 0.99 real soon.
>
> Any help would be awesome. I'll call out for an RC next week.
>
> Enis
>
>
> On Fri, Aug 22, 2014 at 1:47 PM, Stack <st...@duboce.net> wrote:
>
> > How we looking for a 0.99.0?
> >
> > I can go review of outstanding issue list np Enis, just say, but you
> > probably have a notion on where we are already.
> >
> > Grand,
> > St.Ack
> >
> >
> > On Tue, Jul 29, 2014 at 2:35 AM, Aditya <ad...@gmail.com> wrote:
> >
> > > Thanks Ted!
> > >
> > >
> > > On Mon, Jul 28, 2014 at 4:37 PM, Ted Yu <yu...@gmail.com> wrote:
> > >
> > > > I started with https://reviews.apache.org/r/23175/
> > > >
> > > > Will continue reviewing this week.
> > > >
> > > >
> > > > On Mon, Jul 28, 2014 at 1:40 PM, Aditya <ad...@gmail.com>
> > wrote:
> > > >
> > > >> Did anyone get a chance to take a look at the patches?
> > > >>
> > > >> Regards,
> > > >> aditya...
> > > >>
> > > >>
> > > >> On Sun, Jul 20, 2014 at 8:37 PM, Aditya <ad...@gmail.com>
> > > wrote:
> > > >>
> > > >> > The wrapper jar is part of the first patch, which is in git
> mailbox
> > > >> patch
> > > >> > format.
> > > >> >
> > > >> >
> > > >> > On Sat, Jul 19, 2014 at 2:03 AM, Ted Yu <yu...@gmail.com>
> > wrote:
> > > >> >
> > > >> >> You may want to attach the wrapper jar to the JIRA directly.
> > > >> >>
> > > >> >> Cheers
> > > >> >>
> > > >> >> On Jul 19, 2014, at 1:52 AM, Aditya <ad...@gmail.com>
> > wrote:
> > > >> >>
> > > >> >> Looks like the regular patch command skips any binary included in
> > > >> patches.
> > > >> >>
> > > >> >>
> > > >> >> On Sat, Jul 19, 2014 at 1:37 AM, Aditya <adityakishore@gmail.com
> >
> > > >> wrote:
> > > >> >>
> > > >> >>> Thanks for taking a look Ted!
> > > >> >>>
> > > >> >>> Looks like the second patch created with "git diff" excluded the
> > > >> Gradle
> > > >> >>> wrapper JAR from the patch.
> > > >> >>>
> > > >> >>> I would generate a new one which includes this this jar. In the
> > > >> >>> meantime, you should be able to use the first patch attached to
> > the
> > > >> JIRA
> > > >> >>> which is in git-am format and that would let you build.
> > > >> >>>
> > > >> >>>
> > > >> >>> On Fri, Jul 18, 2014 at 3:40 PM, Ted Yu <yu...@gmail.com>
> > > wrote:
> > > >> >>>
> > > >> >>>> Nice work, Aditya.
> > > >> >>>>
> > > >> >>>> Looks like the hbase-native-client profile requires gradle ?
> > > >> >>>>
> > > >> >>>>      [exec] Error: Could not find or load main class
> > > >> >>>> org.gradle.wrapper.GradleWrapperMain
> > > >> >>>>
> > > >> >>>> Will take a look at your patch.
> > > >> >>>>
> > > >> >>>> Cheers
> > > >> >>>>
> > > >> >>>>
> > > >> >>>>
> > > >> >>>> On Fri, Jul 18, 2014 at 3:08 PM, Aditya <
> adityakishore@gmail.com
> > >
> > > >> >>>> wrote:
> > > >> >>>>
> > > >> >>>>> As requested, I have attached a combined patch to the umbrella
> > > JIRA
> > > >> >>>>> <https://issues.apache.org/jira/browse/HBASE-1015> and
> > submitted
> > > >> it to
> > > >> >>>>>
> > > >> >>>>> jenkins.
> > > >> >>>>>
> > > >> >>>>> Would be great if someone could take a look and provide
> > feedback.
> > > >> >>>>>
> > > >> >>>>> Regards,
> > > >> >>>>> aditya...
> > > >> >>>>>
> > > >> >>>>>
> > > >> >>>>> On Wed, Jul 9, 2014 at 7:05 PM, Aditya <
> adityakishore@gmail.com
> > >
> > > >> >>>>> wrote:
> > > >> >>>>>
> > > >> >>>>> > I was hoping to get some initial comments before attaching
> > > patches
> > > >> >>>>> for the
> > > >> >>>>> > build boat.
> > > >> >>>>> >
> > > >> >>>>> > I have broken the entire code into 5 patch sets, layered in
> a
> > > >> >>>>> sequnce,
> > > >> >>>>> > each focusing on a particular area (public headers/JNI
> > > >> >>>>> > implementation/Examples+unit test, etc) for the ease of
> > review.
> > > >> >>>>> >
> > > >> >>>>> > https://reviews.apache.org/r/23175/
> > > >> >>>>> > https://reviews.apache.org/r/23176/
> > > >> >>>>> > https://reviews.apache.org/r/23177/
> > > >> >>>>> > https://reviews.apache.org/r/23178/
> > > >> >>>>> > https://reviews.apache.org/r/23179/
> > > >> >>>>> >
> > > >> >>>>> > These are also available as a sequence of patches as the
> pull
> > > >> request
> > > >> >>>>> > <https://github.com/apache/hbase/pull/1>.
> > > >> >>>>>
> > > >> >>>>> >
> > > >> >>>>> > Only the last patch hooks everything to the HBase build
> > process
> > > >> >>>>> > (optionally) and hence I was thinking of squashing these
> > > separate
> > > >> >>>>> patches
> > > >> >>>>> > into a single patch to be submitted for build.
> > > >> >>>>> >
> > > >> >>>>> >
> > > >> >>>>> > On Wed, Jul 9, 2014 at 11:32 AM, Nick Dimiduk <
> > > ndimiduk@gmail.com
> > > >> >
> > > >> >>>>> wrote:
> > > >> >>>>> >
> > > >> >>>>> >> 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
> > > >> >>>>> >>>>> > >
> > > >> >>>>> >>>>> >
> > > >> >>>>> >>>>>
> > > >> >>>>> >>>>
> > > >> >>>>> >>>>
> > > >> >>>>> >>>
> > > >> >>>>> >>
> > > >> >>>>> >
> > > >> >>>>>
> > > >> >>>>
> > > >> >>>>
> > > >> >>>
> > > >> >>
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
>



-- 
Thanks,
Michael Antonov

Re: DISCUSSION: 1.0.0

Posted by Enis Söztutar <en...@gmail.com>.

Hey,

Yeah, was busy with something else (HBASE-10070 subtasks) for the last
couple of weeks. I intend to get back to 0.99 real soon.

Any help would be awesome. I'll call out for an RC next week.

Enis


On Fri, Aug 22, 2014 at 1:47 PM, Stack <st...@duboce.net> wrote:

> How we looking for a 0.99.0?
>
> I can go review of outstanding issue list np Enis, just say, but you
> probably have a notion on where we are already.
>
> Grand,
> St.Ack
>
>
> On Tue, Jul 29, 2014 at 2:35 AM, Aditya <ad...@gmail.com> wrote:
>
> > Thanks Ted!
> >
> >
> > On Mon, Jul 28, 2014 at 4:37 PM, Ted Yu <yu...@gmail.com> wrote:
> >
> > > I started with https://reviews.apache.org/r/23175/
> > >
> > > Will continue reviewing this week.
> > >
> > >
> > > On Mon, Jul 28, 2014 at 1:40 PM, Aditya <ad...@gmail.com>
> wrote:
> > >
> > >> Did anyone get a chance to take a look at the patches?
> > >>
> > >> Regards,
> > >> aditya...
> > >>
> > >>
> > >> On Sun, Jul 20, 2014 at 8:37 PM, Aditya <ad...@gmail.com>
> > wrote:
> > >>
> > >> > The wrapper jar is part of the first patch, which is in git mailbox
> > >> patch
> > >> > format.
> > >> >
> > >> >
> > >> > On Sat, Jul 19, 2014 at 2:03 AM, Ted Yu <yu...@gmail.com>
> wrote:
> > >> >
> > >> >> You may want to attach the wrapper jar to the JIRA directly.
> > >> >>
> > >> >> Cheers
> > >> >>
> > >> >> On Jul 19, 2014, at 1:52 AM, Aditya <ad...@gmail.com>
> wrote:
> > >> >>
> > >> >> Looks like the regular patch command skips any binary included in
> > >> patches.
> > >> >>
> > >> >>
> > >> >> On Sat, Jul 19, 2014 at 1:37 AM, Aditya <ad...@gmail.com>
> > >> wrote:
> > >> >>
> > >> >>> Thanks for taking a look Ted!
> > >> >>>
> > >> >>> Looks like the second patch created with "git diff" excluded the
> > >> Gradle
> > >> >>> wrapper JAR from the patch.
> > >> >>>
> > >> >>> I would generate a new one which includes this this jar. In the
> > >> >>> meantime, you should be able to use the first patch attached to
> the
> > >> JIRA
> > >> >>> which is in git-am format and that would let you build.
> > >> >>>
> > >> >>>
> > >> >>> On Fri, Jul 18, 2014 at 3:40 PM, Ted Yu <yu...@gmail.com>
> > wrote:
> > >> >>>
> > >> >>>> Nice work, Aditya.
> > >> >>>>
> > >> >>>> Looks like the hbase-native-client profile requires gradle ?
> > >> >>>>
> > >> >>>>      [exec] Error: Could not find or load main class
> > >> >>>> org.gradle.wrapper.GradleWrapperMain
> > >> >>>>
> > >> >>>> Will take a look at your patch.
> > >> >>>>
> > >> >>>> Cheers
> > >> >>>>
> > >> >>>>
> > >> >>>>
> > >> >>>> On Fri, Jul 18, 2014 at 3:08 PM, Aditya <adityakishore@gmail.com
> >
> > >> >>>> wrote:
> > >> >>>>
> > >> >>>>> As requested, I have attached a combined patch to the umbrella
> > JIRA
> > >> >>>>> <https://issues.apache.org/jira/browse/HBASE-1015> and
> submitted
> > >> it to
> > >> >>>>>
> > >> >>>>> jenkins.
> > >> >>>>>
> > >> >>>>> Would be great if someone could take a look and provide
> feedback.
> > >> >>>>>
> > >> >>>>> Regards,
> > >> >>>>> aditya...
> > >> >>>>>
> > >> >>>>>
> > >> >>>>> On Wed, Jul 9, 2014 at 7:05 PM, Aditya <adityakishore@gmail.com
> >
> > >> >>>>> wrote:
> > >> >>>>>
> > >> >>>>> > I was hoping to get some initial comments before attaching
> > patches
> > >> >>>>> for the
> > >> >>>>> > build boat.
> > >> >>>>> >
> > >> >>>>> > I have broken the entire code into 5 patch sets, layered in a
> > >> >>>>> sequnce,
> > >> >>>>> > each focusing on a particular area (public headers/JNI
> > >> >>>>> > implementation/Examples+unit test, etc) for the ease of
> review.
> > >> >>>>> >
> > >> >>>>> > https://reviews.apache.org/r/23175/
> > >> >>>>> > https://reviews.apache.org/r/23176/
> > >> >>>>> > https://reviews.apache.org/r/23177/
> > >> >>>>> > https://reviews.apache.org/r/23178/
> > >> >>>>> > https://reviews.apache.org/r/23179/
> > >> >>>>> >
> > >> >>>>> > These are also available as a sequence of patches as the pull
> > >> request
> > >> >>>>> > <https://github.com/apache/hbase/pull/1>.
> > >> >>>>>
> > >> >>>>> >
> > >> >>>>> > Only the last patch hooks everything to the HBase build
> process
> > >> >>>>> > (optionally) and hence I was thinking of squashing these
> > separate
> > >> >>>>> patches
> > >> >>>>> > into a single patch to be submitted for build.
> > >> >>>>> >
> > >> >>>>> >
> > >> >>>>> > On Wed, Jul 9, 2014 at 11:32 AM, Nick Dimiduk <
> > ndimiduk@gmail.com
> > >> >
> > >> >>>>> wrote:
> > >> >>>>> >
> > >> >>>>> >> 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 <st...@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
> > >> >>>>> >>>>> > >
> > >> >>>>> >>>>> >
> > >> >>>>> >>>>>
> > >> >>>>> >>>>
> > >> >>>>> >>>>
> > >> >>>>> >>>
> > >> >>>>> >>
> > >> >>>>> >
> > >> >>>>>
> > >> >>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >> >
> > >>
> > >
> > >
> >
>