Hello, HBase folks
For your consideration today is Backup/Restore feature for Apache HBAse 2.0.
Backup code is available as a mega patch in HBASE-14123 (v61), applies
cleanly to the current master, all test PASS, patch has no other issues.
The patch has gone through numerous rounds of code review
March 11th is on weekend.
Do you want to give people who haven't looked at the mega patch in depth
some more time ?
Cheers
On Wed, Mar 8, 2017 at 1:32 PM, Vladimir Rodionov
wrote:
> Hello, HBase folks
>
> For your consideration today is Backup/Restore feature for Apache HBAse
> 2.0.
> Backup c
Thanks Vladimir for the write up and the work. Glad to see progress.
Here is my +1. I'm pretty sure we can get the blockers in before the 2.0
timeframe with the momentum, so it is a good idea to merge now so that
development can continue in master, and there is more exposure for testing,
etc.
Eni
No problem, we can extend deadline.
On Wed, Mar 8, 2017 at 3:31 PM, Ted Yu wrote:
> March 11th is on weekend.
>
> Do you want to give people who haven't looked at the mega patch in depth
> some more time ?
>
> Cheers
>
> On Wed, Mar 8, 2017 at 1:32 PM, Vladimir Rodionov
> wrote:
>
> > Hello, HB
+1 from me as well.
On Wed, Mar 8, 2017 at 3:48 PM, Enis Söztutar wrote:
> Thanks Vladimir for the write up and the work. Glad to see progress.
>
> Here is my +1. I'm pretty sure we can get the blockers in before the 2.0
> timeframe with the momentum, so it is a good idea to merge now so that
>
bump
On Wed, Mar 8, 2017 at 3:52 PM, Vladimir Rodionov
wrote:
> No problem, we can extend deadline.
>
> On Wed, Mar 8, 2017 at 3:31 PM, Ted Yu wrote:
>
>> March 11th is on weekend.
>>
>> Do you want to give people who haven't looked at the mega patch in depth
>> some more time ?
>>
>> Cheers
>>
bump
On Thu, Mar 9, 2017 at 10:11 AM, Ted Yu wrote:
> +1 from me as well.
>
> On Wed, Mar 8, 2017 at 3:48 PM, Enis Söztutar wrote:
>
> > Thanks Vladimir for the write up and the work. Glad to see progress.
> >
> > Here is my +1. I'm pretty sure we can get the blockers in before the 2.0
> > time
Still need one more +1
On Thu, Mar 9, 2017 at 11:27 PM, Vladimir Rodionov
wrote:
> bump
>
> On Thu, Mar 9, 2017 at 10:11 AM, Ted Yu wrote:
>
>> +1 from me as well.
>>
>> On Wed, Mar 8, 2017 at 3:48 PM, Enis Söztutar wrote:
>>
>> > Thanks Vladimir for the write up and the work. Glad to see prog
> Only BLOCKERs and CRITICALs are guaranteed for HBase 2.0 release.
If we have identified blockers, why merge this before they are in?
Otherwise we can't release 2.0, and it is overdue.
On Wed, Mar 8, 2017 at 1:32 PM, Vladimir Rodionov
wrote:
> Hello, HBase folks
>
> For your consideration tod
They are not blockers for merge - only for 2.0. GA
As I said already the feature is usable right now
We would like to continue working on master and we would like to see a
commitment from community
Sent from my iPhone
On Mar 10, 2017, at 11:16 AM, Andrew Purtell wrote:
>> Only BLOCKERs and CR
I know the merge of this feature has lagged substantially. I think that is
regrettable but on another thread we are lamenting that 2.0 is already
late. Unless I misunderstand, this is a proposal to merge something with
known blockers into trunk before we branch it for 2.0 which will
effectively pr
No problem I will downgrade Blockers to Majors if it scares you, Andrew 🙂
Sent from my iPhone
> On Mar 10, 2017, at 1:52 PM, Andrew Purtell wrote:
>
> I know the merge of this feature has lagged substantially. I think that is
> regrettable but on another thread we are lamenting that 2.0 is alr
Thanks for the offer but I like that you were honest about compiling a list
of issues that you thought were blockers for release. Since this proposal
is a merge into 2.0, and we are trying to release 2.0, I am -1 on this
merge until those blockers are addressed.
I had a look at the list.
I think
I have no vote here, but I'd argue that HBASE-14417 and HBASE-14141
shouldn't be blockers. I agree that HBASE-15227 to add fault tolerance is a
blocker.
HBASE-14417 is support for incrementally backing up bulk loaded rows.
That's an important feature, but if you don't use bulk loads, or don't care
Thanks for the feedback, Andrew.
How about the following plan:
create branch HBASE-14123 off of master with mega patch v61 as the first
commit (reviewed by Stack and Enis)
Vlad and I continue development (the 3 blockers) based on HBASE-14123 branch
when all of the blockers get +1 and merged into
HBASE-14123 branch has been created, with Vlad's mega patch v61.
FYI
On Fri, Mar 10, 2017 at 3:30 PM, Ted Yu wrote:
> Thanks for the feedback, Andrew.
>
> How about the following plan:
>
> create branch HBASE-14123 off of master with mega patch v61 as the first
> commit (reviewed by Stack and E
On Fri, Mar 10, 2017 at 6:01 PM, Ted Yu wrote:
> HBASE-14123 branch has been created, with Vlad's mega patch v61.
>
The patch put up for VOTE here was done on a branch. The call to merge
seems to have been premature given the many cycles of review and test that
happened subsequent (The cycles bu
On Fri, Mar 10, 2017 at 9:09 PM, Stack wrote:
> On Fri, Mar 10, 2017 at 6:01 PM, Ted Yu wrote:
>
>> HBASE-14123 branch has been created, with Vlad's mega patch v61.
>>
>
> The patch put up for VOTE here was done on a branch. The call to merge
> seems to have been premature given the many cycles
>> It ignores the feedback
If I "ignore" feedback, I put my comment - why? I am always open for
further discussions. If reviewer does not insist on a particular request -
it will be dropped. I think it is fair.
>> he list is incomplete because a bunch of
>> follow-ons came of the review cycle (
t: Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
>> It ignores the feedback
If I "ignore" feedback, I put my comment - why? I am always open for
further discussions. If reviewer does not insist on a particular request -
it will be dropped. I think it is
_
> From: Vladimir Rodionov
> Sent: Monday, March 13, 2017 3:09 PM
> To: dev@hbase.apache.org
> Subject: Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing
> 3/11/2017
>
> >> It ignores the feedback
>
> If I "ignore"
nding work.
> > ________________________
> > From: Vladimir Rodionov
> > Sent: Monday, March 13, 2017 3:09 PM
> > To: dev@hbase.apache.org
> > Subject: Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing
> > 3/11/2017
> >
> >
e, again, that was reverted to ease
> > reviews of the mega-patch, and was noted as work to be done later. I
> think
> > Stack just wants to make the list of remaining work more complete by
> citing
> > that as pending work.
> > _______________________
> > the iterations of the mega-patch. That's a wrong way to go.
> > > On the separation into a backup module, again, that was reverted to
> ease
> > > reviews of the mega-patch, and was noted as work to be done later. I
> > think
> > > Stack just wants
ule, again, that was reverted to
> > ease
> > > > reviews of the mega-patch, and was noted as work to be done later. I
> > > think
> > > > Stack just wants to make the list of remaining work more complete by
> > > citing
> > > > that as pend
From: Vladimir Rodionov
Sent: Monday, March 13, 2017 3:09 PM
To: dev@hbase.apache.org
Subject: Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing
3/11/2017
It ignores the feedback
If I "ignore" feedback, I put my comment - why? I am always open for
further discussions. If r
3, 2017 at 3:46 PM, Devaraj Das
>>> wrote:
>>>
>>> Vlad, on the first point, I think what Stack is saying is that creating
>>>> the new branch (as Ted did) ignores the feedback incorporated thus far
>>>> in
>>>> the iterations of the
om: Vladimir Rodionov
Sent: Monday, March 13, 2017 3:09 PM
To: dev@hbase.apache.org
Subject: Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing
3/11/2017
It ignores the feedback
If I "ignore" feedback, I put my comment - why? I am always open for
further discussions.
gt;
>>>>> We are proposing the merge at this time because of the above that
>>>>> maintaining this in a branch is becoming extremely costly and not
>>>>> productive for the HBase community. Realistically, we cannot have the
>>>>> luxury
gt;>
>>> Enis
>>>
>>> On Mon, Mar 13, 2017 at 3:46 PM, Devaraj Das
>>> wrote:
>>>
>>> Vlad, on the first point, I think what Stack is saying is that creating
>>>> the new branch (as Ted did) ignores the feedback incorporated thus fa
t; >>> giant round of reviews because the code base is a moving target.
> >>>
> >>> Enis
> >>>
> >>> On Mon, Mar 13, 2017 at 3:46 PM, Devaraj Das
> >>> wrote:
> >>>
> >>> Vlad, on the first point, I think wha
ining work more complete by
citing
that as pending work.
________________________
From: Vladimir Rodionov
Sent: Monday, March 13, 2017 3:09 PM
To: dev@hbase.apache.org
Subject: Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing
3/11/2017
It ignores the feedback
If
e blockers.
>>>>>
>>>>> We are proposing the merge at this time because of the above that
>>>>> maintaining this in a branch is becoming extremely costly and not
>>>>> productive for the HBase community. Realistically, we cannot have the
>
r. I
think
Stack just wants to make the list of remaining work more complete by
citing
that as pending work.
From: Vladimir Rodionov
Sent: Monday, March 13, 2017 3:09 PM
To: dev@hbase.apache.org
Subject: Re: [VOTE] Backup/Restore feature for HBase 2.0
t;>
>>>>>> I think there is some misconception of using the term "blockers" for
>>>>>>
>>>>>> referring to those jiras. My understanding is that those three jiras
>>>>>>> are
>>>>>>> blocke
perimental should be done on the merits of
>>>>>>> that
>>>>>>> evaluation, not simply to justify dropping unfinished work into a
>>>>>>> release
>>>>>>> branch.
>>>>>>>
>>>>>>
committed
> >>>>>> before we spin a 2.0 RC, and without causing a 2.0 release to slip
> >>>>>> further.
> >>>>>>
> >>>>>> Also, marking something experimental should be done on the merits of
> >>>>>> that
> &
ot currency. Commits are
> > >>>>>> currency.
> > >>>>>> I hope at least the fault tolerance changes can be completed and
> > >>>>>> committed
> > >>>>>> before we spin a 2.0 RC, and without causing a
; > > >>>>>> that we are trying to get a 2.0 out the door. Because this is a
> > > >>>>>> volunteer
> > > >>>>>> project I cannot make any demand that it should be done, but I
> can
> > > >>>>>> certainly l
; > > > is
> > > > >>>>>
> > > > >>>>>> an
> > > > >>>>>> attempt to walk that back.
> > > > >>>>>>
> > > > >>>>>> I don't like that developm
blems before I can consider whether I'm ok with the
> feature
> > > > > hitting
> > > > > >>>>> 2.0...
> > > > > >>>>>
> > > > > >>>>> I'll also try to throw up a few nodes and play with it to
> > address
> > > > the
> > &
>>>>>
> > > > > > >>>>> I think I could stomach the docs being inaccurate (with a
> > clear
> > > > > > >>>>> disclaimer
> > > > > > >>>>> that the chapter is incomplete -- that's a 5min
42 matches
Mail list logo
