You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by Vladimir Rodionov <vl...@gmail.com> on 2017/03/08 21:32:17 UTC
[VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
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 reviews and has probably
the most lengthy discussion thread on Apache JIRA (HBASE-14123) :)
The work has been split into 3 phases (HBASE-14030, 14123, 14414) Two first
are complete, third one is still in progress.
*** Summary of work HBASE-14123
The new feature introduces new command-line extensions to the hbase command
and, from the client side, is accessible through command-line only
Operations:
* Create full backup on a list of tables or backup set
* Create incremental backup image for table list or backup set
* Restore list of tables from a given backup image
* Show current backup progress
* Delete backup image and all related images
* Show history of backups
* Backup set operations: create backup set, add/remove table to/from backup
set, etc
In the current implementation, the feature is already usable, meaning that
users can backup tables and restore them using provided command-line tools.
Both: full and incremental backups are supported.
This work is based on original work of IBM team (HBASE-7912). The full list
of JIRAs included in this mega patch can be found in three umbrella JIRAs:
HBASE-14030 (Phase 1), HBASE-14123 (Phase 2) and HBASE-14414 (Phase 3 - all
resolved ones made it into the patch)
*** What are the remaining work items
All remaining items can be found in Phase 3 umbrella JIRA: HBASE-14414.
They are split into 3 groups: BLOCKER, CRITICAL, MAJOR
Only BLOCKERs and CRITICALs are guaranteed for HBase 2.0 release.
***** BLOCKER
* HBASE-14417 Incremental backup and bulk loading ( Patch available)
* HBASE-14135 HBase Backup/Restore Phase 3: Merge backup images
* HBASE-14141 HBase Backup/Restore Phase 3: Filter WALs on backup to
include only edits from backup tables (Patch available)
* HBASE-17133 Backup documentation
* HBASE-15227 Fault tolerance support
***** CRITICAL
* HBASE-16465 Disable split/merges during backup
We have umbrella JIRA (HBASE-14414) to track all the remaining work
All the BLOCKER and CRITICAL JIRAs currently in open state will be
implemented by 2.0 release time. Some MAJOR too, but it depends on resource
availability
The former development branch (HBASE-7912) is obsolete and will be
closed/deleted after the merge.
We want backup to be a GA feature in 2.0
We are going to support full backward compatibility for backup tool in 2.0
and onwards.
**** Configuration
Backup is disabled, by default. To enable it, the following configuration
properties must be added to hbase-site.xml:
hbase.backup.enable=true
hbase.master.logcleaner.plugins=YOUR_PLUGINS,org.apache.hadoop.hbase.backup.master.BackupLogCleaner
hbase.procedure.master.classes=YOUR_CLASSES,org.apache.hadoop.hbase.backup.master.LogRollMasterProcedureManager
hbase.procedure.regionserver.classes=YOUR_CLASSES,org.apache.hadoop.hbase.backup.regionserver.LogRollRegionServerProcedureManager
I would like to thank IBM team and Jerry He for original work,
Enis, Ted, Stack, Matteo, Jerry for time spent on code reviews
Special thanks to Ted Yu for his co-development work.
References:
https://issues.apache.org/jira/browse/HBASE-7912 (original IBM, contains
design doc)
https://issues.apache.org/jira/browse/HBASE-14030 (Phase 1)
https://issues.apache.org/jira/browse/HBASE-14123 (Phase 2)
https://issues.apache.org/jira/browse/HBASE-14414 (Phase 3)
Please vote +1/-1 by midnight Pacific Time (00:00
-0800 GMT) on March 11th on whether or not we should merge this into the
current master.
-Vladimir Rodionov
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
Posted by Geoffrey Jacoby <gj...@salesforce.com>.
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
about _incremental_ backups of bulk loads, you'd be able to use backup
quite happily without it. Even if you bulk load occasionally, you can do a
full backup afterward. In the meantime, the docs and help text would just
need to make the limitation clear in big bold letters. :-)
HBASE-14141 is allowing HBase Backup to filter out unnecessary data from
its incremental backups. Since the backup tool allows you to specify that
only certain tables be backed up, incremental backups at WAL granularity
will accidentally backup some rows from unneeded tables. This doesn't
affect the correctness of the to-be-backed-up tables backups or restores,
only its storage cost. The feature works, but there's an important storage
optimization to be done.
As someone who works on clusters that don't use bulk load, and would want
to backup all tables, neither of these seems like a showstopper. However,
if HBASE-14141 would be a breaking change to the backup format, then that
would change my mind about it being a blocker.
Geoffrey
On Fri, Mar 10, 2017 at 3:01 PM, Andrew Purtell <ap...@apache.org> wrote:
> 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 the documentation issue is important but not actually a blocker.
> That may be a controversial opinion, but documentation can be back-filled
> worst case. So take HBASE-17133 off the list.
>
> Remaining are effectively HBASE-14417, HBASE-14141, and HBASE-15227. They
> all have patches attached to the respective JIRAs so completing this work
> won't be onerous. Get these committed and I will lift my -1. The others who
> voted +1 on this thread surely can help with that.
>
> Thanks.
>
>
> On Fri, Mar 10, 2017 at 2:32 PM, Vladimir Rodionov <vladrodionov@gmail.com
> >
> wrote:
>
> > 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 <ap...@apache.org>
> 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 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 prevent that release because these blockers will be there.
> I
> > am
> > > inclined to veto. Probably we should not propose branch merges into
> code
> > we
> > > are trying to get out the door with known blockers. Why not do that
> work
> > > first? It seems an obvious question. Perhaps I am missing something.
> > >
> > > If we can branch for 2.0 now and then merge this, and not into the 2.0
> > > branch, I would vote +1 for branch merge even with known blockers
> > pending.
> > >
> > >
> > > On Fri, Mar 10, 2017 at 1:42 PM, Vladimir Rodionov <
> > vladrodionov@gmail.com>
> > > wrote:
> > >
> > >> 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 <ap...@apache.org>
> > wrote:
> > >>
> > >>>> 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 <
> > >> vladrodionov@gmail.com>
> > >>> wrote:
> > >>>
> > >>>> 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 reviews and has
> > >> probably
> > >>>> the most lengthy discussion thread on Apache JIRA (HBASE-14123) :)
> > >>>>
> > >>>> The work has been split into 3 phases (HBASE-14030, 14123, 14414)
> Two
> > >> first
> > >>>> are complete, third one is still in progress.
> > >>>>
> > >>>>
> > >>>> *** Summary of work HBASE-14123
> > >>>>
> > >>>> The new feature introduces new command-line extensions to the hbase
> > >> command
> > >>>> and, from the client side, is accessible through command-line only
> > >>>> Operations:
> > >>>> * Create full backup on a list of tables or backup set
> > >>>> * Create incremental backup image for table list or backup set
> > >>>> * Restore list of tables from a given backup image
> > >>>> * Show current backup progress
> > >>>> * Delete backup image and all related images
> > >>>> * Show history of backups
> > >>>> * Backup set operations: create backup set, add/remove table to/from
> > >> backup
> > >>>> set, etc
> > >>>>
> > >>>> In the current implementation, the feature is already usable,
> meaning
> > >> that
> > >>>> users can backup tables and restore them using provided command-line
> > >> tools.
> > >>>> Both: full and incremental backups are supported.
> > >>>> This work is based on original work of IBM team (HBASE-7912). The
> full
> > >> list
> > >>>> of JIRAs included in this mega patch can be found in three umbrella
> > >> JIRAs:
> > >>>> HBASE-14030 (Phase 1), HBASE-14123 (Phase 2) and HBASE-14414 (Phase
> 3
> > -
> > >> all
> > >>>> resolved ones made it into the patch)
> > >>>>
> > >>>> *** What are the remaining work items
> > >>>>
> > >>>> All remaining items can be found in Phase 3 umbrella JIRA:
> > HBASE-14414.
> > >>>> They are split into 3 groups: BLOCKER, CRITICAL, MAJOR
> > >>>> Only BLOCKERs and CRITICALs are guaranteed for HBase 2.0 release.
> > >>>>
> > >>>> ***** BLOCKER
> > >>>>
> > >>>> * HBASE-14417 Incremental backup and bulk loading ( Patch available)
> > >>>> * HBASE-14135 HBase Backup/Restore Phase 3: Merge backup images
> > >>>> * HBASE-14141 HBase Backup/Restore Phase 3: Filter WALs on backup to
> > >>>> include only edits from backup tables (Patch available)
> > >>>> * HBASE-17133 Backup documentation
> > >>>> * HBASE-15227 Fault tolerance support
> > >>>>
> > >>>> ***** CRITICAL
> > >>>>
> > >>>> * HBASE-16465 Disable split/merges during backup
> > >>>>
> > >>>> We have umbrella JIRA (HBASE-14414) to track all the remaining work
> > >>>> All the BLOCKER and CRITICAL JIRAs currently in open state will be
> > >>>> implemented by 2.0 release time. Some MAJOR too, but it depends on
> > >> resource
> > >>>> availability
> > >>>> The former development branch (HBASE-7912) is obsolete and will be
> > >>>> closed/deleted after the merge.
> > >>>> We want backup to be a GA feature in 2.0
> > >>>> We are going to support full backward compatibility for backup tool
> in
> > >> 2.0
> > >>>> and onwards.
> > >>>>
> > >>>> **** Configuration
> > >>>>
> > >>>> Backup is disabled, by default. To enable it, the following
> > >> configuration
> > >>>> properties must be added to hbase-site.xml:
> > >>>>
> > >>>> hbase.backup.enable=true
> > >>>> hbase.master.logcleaner.plugins=YOUR_PLUGINS,org.
> > >>>> apache.hadoop.hbase.backup.master.BackupLogCleaner
> > >>>> hbase.procedure.master.classes=YOUR_CLASSES,org.
> > >>>> apache.hadoop.hbase.backup.master.LogRollMasterProcedureManager
> > >>>> hbase.procedure.regionserver.classes=YOUR_CLASSES,org.
> > >>>> apache.hadoop.hbase.backup.regionserver.
> > LogRollRegionServerProcedureMa
> > >>>> nager
> > >>>>
> > >>>>
> > >>>> I would like to thank IBM team and Jerry He for original work,
> > >>>>
> > >>>> Enis, Ted, Stack, Matteo, Jerry for time spent on code reviews
> > >>>>
> > >>>> Special thanks to Ted Yu for his co-development work.
> > >>>>
> > >>>> References:
> > >>>>
> > >>>> https://issues.apache.org/jira/browse/HBASE-7912 (original IBM,
> > >> contains
> > >>>> design doc)
> > >>>> https://issues.apache.org/jira/browse/HBASE-14030 (Phase 1)
> > >>>> https://issues.apache.org/jira/browse/HBASE-14123 (Phase 2)
> > >>>> https://issues.apache.org/jira/browse/HBASE-14414 (Phase 3)
> > >>>>
> > >>>> Please vote +1/-1 by midnight Pacific Time (00:00
> > >>>> -0800 GMT) on March 11th on whether or not we should merge this
> into
> > >> the
> > >>>> current master.
> > >>>>
> > >>>> -Vladimir Rodionov
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> Best regards,
> > >>>
> > >>> - Andy
> > >>>
> > >>> If you are given a choice, you believe you have acted freely. -
> Raymond
> > >>> Teller (via Peter Watts)
> > >>
> > >
> > >
> > >
> > > --
> > > Best regards,
> > >
> > > - Andy
> > >
> > > If you are given a choice, you believe you have acted freely. - Raymond
> > > Teller (via Peter Watts)
> >
>
>
>
> --
> Best regards,
>
> - Andy
>
> If you are given a choice, you believe you have acted freely. - Raymond
> Teller (via Peter Watts)
>
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
Posted by Ted Yu <yu...@gmail.com>.
As of 6:06pm PST, I still saw these branches on
https://github.com/apache/hbase/
Maybe there is some delay.
Thanks Andrew.
On Mon, Mar 13, 2017 at 5:59 PM, Andrew Purtell <ap...@apache.org> wrote:
> That's because this was pushed with a different name. It's gone now.
>
> apurtell@onyx:~/src/hbase$ git branch -a | grep 14123
> remotes/origin/14123
> apurtell@onyx:~/src/hbase$ git push origin :14123
> Username for 'https://git-wip-us.apache.org': apurtell
> Password for 'https://apurtell@git-wip-us.apache.org':
> To https://git-wip-us.apache.org/repos/asf/hbase.git
> - [deleted] 14123
>
>
> On Mon, Mar 13, 2017 at 4:13 PM, Ted Yu <yu...@gmail.com> wrote:
>
> > I tried to delete the HBASE-14123 branch using commands I found on
> > http://stackoverflow.com/questions/2003505/how-to-
> > delete-a-git-branch-both-locally-and-remotely
> >
> > Not sure if there is lag on github side:
> >
> > $ git push origin :origin/HBASE-14123
> > error: unable to delete 'origin/HBASE-14123': remote ref does not exist
> > error: failed to push some refs to '
> > https://git-wip-us.apache.org/repos/asf/hbase.git'
> >
> > FYI
> >
> > On Mon, Mar 13, 2017 at 4:05 PM, Enis Söztutar <en...@apache.org> wrote:
> >
> > > I think there is some misconception of using the term "blockers" for
> > > referring to those jiras. My understanding is that those three jiras
> are
> > > blockers for the backup functionality to be more mature and more
> usable.
> > > But they are not release blockers. Let's say we merged the code in, and
> > for
> > > some reason those did not get addressed in time. We can still do the
> 2.0
> > > release without having to wait for the commits. We can instead mark the
> > > "backup" feature as experimental with known issues and go on with the
> > > release. In that sense they are not real release 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
> > > luxury of having to wait another couple of months and doing yet another
> > > giant round of reviews because the code base is a moving target.
> > >
> > > Enis
> > >
> > > On Mon, Mar 13, 2017 at 3:46 PM, Devaraj Das <dd...@hortonworks.com>
> > 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 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 to make the list of remaining work more complete by
> > > citing
> > > > that as pending work.
> > > > ________________________________________
> > > > From: Vladimir Rodionov <vl...@gmail.com>
> > > > 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 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 (including moving
> backup/restore
> > > out
> > > > of
> > > > >> core to live in its own module).
> > > >
> > > > For those who were not following our lengthy conversation on a review
> > > > board, separation of a backup code into a separate module has been
> > > > done last year, but has been reverted back by request of a reviewer.
> > > >
> > > >
> > > > -Vladimir
> > > >
> > > > On Mon, Mar 13, 2017 at 2:23 PM, Stack <st...@duboce.net> wrote:
> > > >
> > > > > On Fri, Mar 10, 2017 at 9:09 PM, Stack <st...@duboce.net> wrote:
> > > > >
> > > > > > On Fri, Mar 10, 2017 at 6:01 PM, Ted Yu <yu...@gmail.com>
> > 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 burned a bunch of dev resource).
> > > > > >
> > > > > > The patch as is is now in a state where it is too big for our
> > infra;
> > > rb
> > > > > > and JIRA are creaking under the size and # of iterations.
> > > > > >
> > > > > > Adding finish of new JIRAs to this merge implies a new round of
> > > review
> > > > > and
> > > > > > test of an already massive patch. Who is going to do this work?
> > > > > >
> > > > > > Going back to a new branch seems wrong route to take.
> > > > > >
> > > > > > St.Ack
> > > > > >
> > > > > >
> > > > > >
> > > > > To be more explicit, this patch was developed on a branch and then
> a
> > > > bunch
> > > > > of dev resources were burned getting it into a state where it could
> > be
> > > > > merged to master. Going back to a branch to bulk up the merge so it
> > > > > includes more JIRAs than the many it already incorporates is the
> > wrong
> > > > > direction for us to be headed in. It ignores the feedback given and
> > the
> > > > > work done by Vladimir slimming down an already over-broad scope. It
> > is
> > > > also
> > > > > predicated on abundant review and testing resource being on tap to
> > > cycle
> > > > on
> > > > > a feature that is useful, but non-core.
> > > > >
> > > > > The patch is ready for merge IMO. Geoffrey makes a nice list of
> what
> > is
> > > > > still to do though IIRC, the list is incomplete because a bunch of
> > > > > follow-ons came of the review cycle (including moving
> backup/restore
> > > out
> > > > of
> > > > > core to live in its own module).
> > > > >
> > > > > The patch needs three votes to merge. I am not against merge but I
> am
> > > not
> > > > > voting for the patch because I do have any more time to spend on
> this
> > > > > non-core feature and feel that a vote will have me assume a
> > > > responsibility
> > > > > I will not shirk.
> > > > >
> > > > > S
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >> FYI
> > > > > >>
> > > > > >> On Fri, Mar 10, 2017 at 3:30 PM, Ted Yu <yu...@gmail.com>
> > > 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 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,
> > > > we
> > > > > >> > propose to community for merging into branch-2 (master branch,
> > if
> > > > > >> branch-2
> > > > > >> > doesn't materialize for whatever reason) again
> > > > > >> >
> > > > > >> > Cheers
> > > > > >> >
> > > > > >> >
> > > > > >> > On Fri, Mar 10, 2017 at 3:01 PM, Andrew Purtell <
> > > > apurtell@apache.org>
> > > > > >> > wrote:
> > > > > >> >
> > > > > >> >> 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 the documentation issue is important but not
> actually a
> > > > > >> blocker.
> > > > > >> >> That may be a controversial opinion, but documentation can be
> > > > > >> back-filled
> > > > > >> >> worst case. So take HBASE-17133 off the list.
> > > > > >> >>
> > > > > >> >> Remaining are effectively HBASE-14417, HBASE-14141, and
> > > > HBASE-15227.
> > > > > >> They
> > > > > >> >> all have patches attached to the respective JIRAs so
> completing
> > > > this
> > > > > >> work
> > > > > >> >> won't be onerous. Get these committed and I will lift my -1.
> > The
> > > > > others
> > > > > >> >> who
> > > > > >> >> voted +1 on this thread surely can help with that.
> > > > > >> >>
> > > > > >> >> Thanks.
> > > > > >> >>
> > > > > >> >>
> > > > > >> >> On Fri, Mar 10, 2017 at 2:32 PM, Vladimir Rodionov <
> > > > > >> >> vladrodionov@gmail.com>
> > > > > >> >> wrote:
> > > > > >> >>
> > > > > >> >> > 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 <
> > > > apurtell@apache.org
> > > > > >
> > > > > >> >> 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
> > > > > >> 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 prevent that release because these blockers
> > will
> > > be
> > > > > >> >> there. I
> > > > > >> >> > am
> > > > > >> >> > > inclined to veto. Probably we should not propose branch
> > > merges
> > > > > into
> > > > > >> >> code
> > > > > >> >> > we
> > > > > >> >> > > are trying to get out the door with known blockers. Why
> not
> > > do
> > > > > that
> > > > > >> >> work
> > > > > >> >> > > first? It seems an obvious question. Perhaps I am missing
> > > > > >> something.
> > > > > >> >> > >
> > > > > >> >> > > If we can branch for 2.0 now and then merge this, and not
> > > into
> > > > > the
> > > > > >> 2.0
> > > > > >> >> > > branch, I would vote +1 for branch merge even with known
> > > > blockers
> > > > > >> >> > pending.
> > > > > >> >> > >
> > > > > >> >> > >
> > > > > >> >> > > On Fri, Mar 10, 2017 at 1:42 PM, Vladimir Rodionov <
> > > > > >> >> > vladrodionov@gmail.com>
> > > > > >> >> > > wrote:
> > > > > >> >> > >
> > > > > >> >> > >> 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 <
> > > > > apurtell@apache.org
> > > > > >> >
> > > > > >> >> > wrote:
> > > > > >> >> > >>
> > > > > >> >> > >>>> 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 <
> > > > > >> >> > >> vladrodionov@gmail.com>
> > > > > >> >> > >>> wrote:
> > > > > >> >> > >>>
> > > > > >> >> > >>>> 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
> > reviews
> > > > and
> > > > > >> has
> > > > > >> >> > >> probably
> > > > > >> >> > >>>> the most lengthy discussion thread on Apache JIRA
> > > > > (HBASE-14123)
> > > > > >> :)
> > > > > >> >> > >>>>
> > > > > >> >> > >>>> The work has been split into 3 phases (HBASE-14030,
> > 14123,
> > > > > >> 14414)
> > > > > >> >> Two
> > > > > >> >> > >> first
> > > > > >> >> > >>>> are complete, third one is still in progress.
> > > > > >> >> > >>>>
> > > > > >> >> > >>>>
> > > > > >> >> > >>>> *** Summary of work HBASE-14123
> > > > > >> >> > >>>>
> > > > > >> >> > >>>> The new feature introduces new command-line extensions
> > to
> > > > the
> > > > > >> hbase
> > > > > >> >> > >> command
> > > > > >> >> > >>>> and, from the client side, is accessible through
> > > > command-line
> > > > > >> only
> > > > > >> >> > >>>> Operations:
> > > > > >> >> > >>>> * Create full backup on a list of tables or backup set
> > > > > >> >> > >>>> * Create incremental backup image for table list or
> > backup
> > > > set
> > > > > >> >> > >>>> * Restore list of tables from a given backup image
> > > > > >> >> > >>>> * Show current backup progress
> > > > > >> >> > >>>> * Delete backup image and all related images
> > > > > >> >> > >>>> * Show history of backups
> > > > > >> >> > >>>> * Backup set operations: create backup set, add/remove
> > > table
> > > > > >> >> to/from
> > > > > >> >> > >> backup
> > > > > >> >> > >>>> set, etc
> > > > > >> >> > >>>>
> > > > > >> >> > >>>> In the current implementation, the feature is already
> > > > usable,
> > > > > >> >> meaning
> > > > > >> >> > >> that
> > > > > >> >> > >>>> users can backup tables and restore them using
> provided
> > > > > >> >> command-line
> > > > > >> >> > >> tools.
> > > > > >> >> > >>>> Both: full and incremental backups are supported.
> > > > > >> >> > >>>> This work is based on original work of IBM team
> > > > (HBASE-7912).
> > > > > >> The
> > > > > >> >> full
> > > > > >> >> > >> list
> > > > > >> >> > >>>> of JIRAs included in this mega patch can be found in
> > three
> > > > > >> umbrella
> > > > > >> >> > >> JIRAs:
> > > > > >> >> > >>>> HBASE-14030 (Phase 1), HBASE-14123 (Phase 2) and
> > > HBASE-14414
> > > > > >> >> (Phase 3
> > > > > >> >> > -
> > > > > >> >> > >> all
> > > > > >> >> > >>>> resolved ones made it into the patch)
> > > > > >> >> > >>>>
> > > > > >> >> > >>>> *** What are the remaining work items
> > > > > >> >> > >>>>
> > > > > >> >> > >>>> All remaining items can be found in Phase 3 umbrella
> > JIRA:
> > > > > >> >> > HBASE-14414.
> > > > > >> >> > >>>> They are split into 3 groups: BLOCKER, CRITICAL, MAJOR
> > > > > >> >> > >>>> Only BLOCKERs and CRITICALs are guaranteed for HBase
> 2.0
> > > > > >> release.
> > > > > >> >> > >>>>
> > > > > >> >> > >>>> ***** BLOCKER
> > > > > >> >> > >>>>
> > > > > >> >> > >>>> * HBASE-14417 Incremental backup and bulk loading (
> > Patch
> > > > > >> >> available)
> > > > > >> >> > >>>> * HBASE-14135 HBase Backup/Restore Phase 3: Merge
> backup
> > > > > images
> > > > > >> >> > >>>> * HBASE-14141 HBase Backup/Restore Phase 3: Filter
> WALs
> > on
> > > > > >> backup
> > > > > >> >> to
> > > > > >> >> > >>>> include only edits from backup tables (Patch
> available)
> > > > > >> >> > >>>> * HBASE-17133 Backup documentation
> > > > > >> >> > >>>> * HBASE-15227 Fault tolerance support
> > > > > >> >> > >>>>
> > > > > >> >> > >>>> ***** CRITICAL
> > > > > >> >> > >>>>
> > > > > >> >> > >>>> * HBASE-16465 Disable split/merges during backup
> > > > > >> >> > >>>>
> > > > > >> >> > >>>> We have umbrella JIRA (HBASE-14414) to track all the
> > > > remaining
> > > > > >> work
> > > > > >> >> > >>>> All the BLOCKER and CRITICAL JIRAs currently in open
> > state
> > > > > will
> > > > > >> be
> > > > > >> >> > >>>> implemented by 2.0 release time. Some MAJOR too, but
> it
> > > > > depends
> > > > > >> on
> > > > > >> >> > >> resource
> > > > > >> >> > >>>> availability
> > > > > >> >> > >>>> The former development branch (HBASE-7912) is obsolete
> > and
> > > > > will
> > > > > >> be
> > > > > >> >> > >>>> closed/deleted after the merge.
> > > > > >> >> > >>>> We want backup to be a GA feature in 2.0
> > > > > >> >> > >>>> We are going to support full backward compatibility
> for
> > > > backup
> > > > > >> >> tool in
> > > > > >> >> > >> 2.0
> > > > > >> >> > >>>> and onwards.
> > > > > >> >> > >>>>
> > > > > >> >> > >>>> **** Configuration
> > > > > >> >> > >>>>
> > > > > >> >> > >>>> Backup is disabled, by default. To enable it, the
> > > following
> > > > > >> >> > >> configuration
> > > > > >> >> > >>>> properties must be added to hbase-site.xml:
> > > > > >> >> > >>>>
> > > > > >> >> > >>>> hbase.backup.enable=true
> > > > > >> >> > >>>> hbase.master.logcleaner.plugins=YOUR_PLUGINS,org.
> > > > > >> >> > >>>> apache.hadoop.hbase.backup.master.BackupLogCleaner
> > > > > >> >> > >>>> hbase.procedure.master.classes=YOUR_CLASSES,org.
> > > > > >> >> > >>>> apache.hadoop.hbase.backup.master.
> > > > > LogRollMasterProcedureManager
> > > > > >> >> > >>>> hbase.procedure.regionserver.
> classes=YOUR_CLASSES,org.
> > > > > >> >> > >>>> apache.hadoop.hbase.backup.regionserver.
> > > > > >> >> > LogRollRegionServerProcedureMa
> > > > > >> >> > >>>> nager
> > > > > >> >> > >>>>
> > > > > >> >> > >>>>
> > > > > >> >> > >>>> I would like to thank IBM team and Jerry He for
> original
> > > > work,
> > > > > >> >> > >>>>
> > > > > >> >> > >>>> Enis, Ted, Stack, Matteo, Jerry for time spent on code
> > > > reviews
> > > > > >> >> > >>>>
> > > > > >> >> > >>>> Special thanks to Ted Yu for his co-development work.
> > > > > >> >> > >>>>
> > > > > >> >> > >>>> References:
> > > > > >> >> > >>>>
> > > > > >> >> > >>>> https://issues.apache.org/jira/browse/HBASE-7912
> > > (original
> > > > > IBM,
> > > > > >> >> > >> contains
> > > > > >> >> > >>>> design doc)
> > > > > >> >> > >>>> https://issues.apache.org/jira/browse/HBASE-14030
> > (Phase
> > > 1)
> > > > > >> >> > >>>> https://issues.apache.org/jira/browse/HBASE-14123
> > (Phase
> > > 2)
> > > > > >> >> > >>>> https://issues.apache.org/jira/browse/HBASE-14414
> > (Phase
> > > 3)
> > > > > >> >> > >>>>
> > > > > >> >> > >>>> Please vote +1/-1 by midnight Pacific Time (00:00
> > > > > >> >> > >>>> -0800 GMT) on March 11th on whether or not we should
> > > merge
> > > > > >> this
> > > > > >> >> into
> > > > > >> >> > >> the
> > > > > >> >> > >>>> current master.
> > > > > >> >> > >>>>
> > > > > >> >> > >>>> -Vladimir Rodionov
> > > > > >> >> > >>>>
> > > > > >> >> > >>>
> > > > > >> >> > >>>
> > > > > >> >> > >>>
> > > > > >> >> > >>> --
> > > > > >> >> > >>> Best regards,
> > > > > >> >> > >>>
> > > > > >> >> > >>> - Andy
> > > > > >> >> > >>>
> > > > > >> >> > >>> If you are given a choice, you believe you have acted
> > > > freely. -
> > > > > >> >> Raymond
> > > > > >> >> > >>> Teller (via Peter Watts)
> > > > > >> >> > >>
> > > > > >> >> > >
> > > > > >> >> > >
> > > > > >> >> > >
> > > > > >> >> > > --
> > > > > >> >> > > Best regards,
> > > > > >> >> > >
> > > > > >> >> > > - Andy
> > > > > >> >> > >
> > > > > >> >> > > If you are given a choice, you believe you have acted
> > > freely. -
> > > > > >> >> Raymond
> > > > > >> >> > > Teller (via Peter Watts)
> > > > > >> >> >
> > > > > >> >>
> > > > > >> >>
> > > > > >> >>
> > > > > >> >> --
> > > > > >> >> Best regards,
> > > > > >> >>
> > > > > >> >> - Andy
> > > > > >> >>
> > > > > >> >> If you are given a choice, you believe you have acted
> freely. -
> > > > > Raymond
> > > > > >> >> Teller (via Peter Watts)
> > > > > >> >>
> > > > > >> >
> > > > > >> >
> > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
>
>
> --
> Best regards,
>
> - Andy
>
> If you are given a choice, you believe you have acted freely. - Raymond
> Teller (via Peter Watts)
>
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
Posted by Andrew Purtell <ap...@apache.org>.
That's because this was pushed with a different name. It's gone now.
apurtell@onyx:~/src/hbase$ git branch -a | grep 14123
remotes/origin/14123
apurtell@onyx:~/src/hbase$ git push origin :14123
Username for 'https://git-wip-us.apache.org': apurtell
Password for 'https://apurtell@git-wip-us.apache.org':
To https://git-wip-us.apache.org/repos/asf/hbase.git
- [deleted] 14123
On Mon, Mar 13, 2017 at 4:13 PM, Ted Yu <yu...@gmail.com> wrote:
> I tried to delete the HBASE-14123 branch using commands I found on
> http://stackoverflow.com/questions/2003505/how-to-
> delete-a-git-branch-both-locally-and-remotely
>
> Not sure if there is lag on github side:
>
> $ git push origin :origin/HBASE-14123
> error: unable to delete 'origin/HBASE-14123': remote ref does not exist
> error: failed to push some refs to '
> https://git-wip-us.apache.org/repos/asf/hbase.git'
>
> FYI
>
> On Mon, Mar 13, 2017 at 4:05 PM, Enis Söztutar <en...@apache.org> wrote:
>
> > I think there is some misconception of using the term "blockers" for
> > referring to those jiras. My understanding is that those three jiras are
> > blockers for the backup functionality to be more mature and more usable.
> > But they are not release blockers. Let's say we merged the code in, and
> for
> > some reason those did not get addressed in time. We can still do the 2.0
> > release without having to wait for the commits. We can instead mark the
> > "backup" feature as experimental with known issues and go on with the
> > release. In that sense they are not real release 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
> > luxury of having to wait another couple of months and doing yet another
> > giant round of reviews because the code base is a moving target.
> >
> > Enis
> >
> > On Mon, Mar 13, 2017 at 3:46 PM, Devaraj Das <dd...@hortonworks.com>
> 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 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 to make the list of remaining work more complete by
> > citing
> > > that as pending work.
> > > ________________________________________
> > > From: Vladimir Rodionov <vl...@gmail.com>
> > > 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 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 (including moving backup/restore
> > out
> > > of
> > > >> core to live in its own module).
> > >
> > > For those who were not following our lengthy conversation on a review
> > > board, separation of a backup code into a separate module has been
> > > done last year, but has been reverted back by request of a reviewer.
> > >
> > >
> > > -Vladimir
> > >
> > > On Mon, Mar 13, 2017 at 2:23 PM, Stack <st...@duboce.net> wrote:
> > >
> > > > On Fri, Mar 10, 2017 at 9:09 PM, Stack <st...@duboce.net> wrote:
> > > >
> > > > > On Fri, Mar 10, 2017 at 6:01 PM, Ted Yu <yu...@gmail.com>
> 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 burned a bunch of dev resource).
> > > > >
> > > > > The patch as is is now in a state where it is too big for our
> infra;
> > rb
> > > > > and JIRA are creaking under the size and # of iterations.
> > > > >
> > > > > Adding finish of new JIRAs to this merge implies a new round of
> > review
> > > > and
> > > > > test of an already massive patch. Who is going to do this work?
> > > > >
> > > > > Going back to a new branch seems wrong route to take.
> > > > >
> > > > > St.Ack
> > > > >
> > > > >
> > > > >
> > > > To be more explicit, this patch was developed on a branch and then a
> > > bunch
> > > > of dev resources were burned getting it into a state where it could
> be
> > > > merged to master. Going back to a branch to bulk up the merge so it
> > > > includes more JIRAs than the many it already incorporates is the
> wrong
> > > > direction for us to be headed in. It ignores the feedback given and
> the
> > > > work done by Vladimir slimming down an already over-broad scope. It
> is
> > > also
> > > > predicated on abundant review and testing resource being on tap to
> > cycle
> > > on
> > > > a feature that is useful, but non-core.
> > > >
> > > > The patch is ready for merge IMO. Geoffrey makes a nice list of what
> is
> > > > still to do though IIRC, the list is incomplete because a bunch of
> > > > follow-ons came of the review cycle (including moving backup/restore
> > out
> > > of
> > > > core to live in its own module).
> > > >
> > > > The patch needs three votes to merge. I am not against merge but I am
> > not
> > > > voting for the patch because I do have any more time to spend on this
> > > > non-core feature and feel that a vote will have me assume a
> > > responsibility
> > > > I will not shirk.
> > > >
> > > > S
> > > >
> > > >
> > > >
> > > > >
> > > > >
> > > > >
> > > > >> FYI
> > > > >>
> > > > >> On Fri, Mar 10, 2017 at 3:30 PM, Ted Yu <yu...@gmail.com>
> > 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 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,
> > > we
> > > > >> > propose to community for merging into branch-2 (master branch,
> if
> > > > >> branch-2
> > > > >> > doesn't materialize for whatever reason) again
> > > > >> >
> > > > >> > Cheers
> > > > >> >
> > > > >> >
> > > > >> > On Fri, Mar 10, 2017 at 3:01 PM, Andrew Purtell <
> > > apurtell@apache.org>
> > > > >> > wrote:
> > > > >> >
> > > > >> >> 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 the documentation issue is important but not actually a
> > > > >> blocker.
> > > > >> >> That may be a controversial opinion, but documentation can be
> > > > >> back-filled
> > > > >> >> worst case. So take HBASE-17133 off the list.
> > > > >> >>
> > > > >> >> Remaining are effectively HBASE-14417, HBASE-14141, and
> > > HBASE-15227.
> > > > >> They
> > > > >> >> all have patches attached to the respective JIRAs so completing
> > > this
> > > > >> work
> > > > >> >> won't be onerous. Get these committed and I will lift my -1.
> The
> > > > others
> > > > >> >> who
> > > > >> >> voted +1 on this thread surely can help with that.
> > > > >> >>
> > > > >> >> Thanks.
> > > > >> >>
> > > > >> >>
> > > > >> >> On Fri, Mar 10, 2017 at 2:32 PM, Vladimir Rodionov <
> > > > >> >> vladrodionov@gmail.com>
> > > > >> >> wrote:
> > > > >> >>
> > > > >> >> > 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 <
> > > apurtell@apache.org
> > > > >
> > > > >> >> 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
> > > > >> 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 prevent that release because these blockers
> will
> > be
> > > > >> >> there. I
> > > > >> >> > am
> > > > >> >> > > inclined to veto. Probably we should not propose branch
> > merges
> > > > into
> > > > >> >> code
> > > > >> >> > we
> > > > >> >> > > are trying to get out the door with known blockers. Why not
> > do
> > > > that
> > > > >> >> work
> > > > >> >> > > first? It seems an obvious question. Perhaps I am missing
> > > > >> something.
> > > > >> >> > >
> > > > >> >> > > If we can branch for 2.0 now and then merge this, and not
> > into
> > > > the
> > > > >> 2.0
> > > > >> >> > > branch, I would vote +1 for branch merge even with known
> > > blockers
> > > > >> >> > pending.
> > > > >> >> > >
> > > > >> >> > >
> > > > >> >> > > On Fri, Mar 10, 2017 at 1:42 PM, Vladimir Rodionov <
> > > > >> >> > vladrodionov@gmail.com>
> > > > >> >> > > wrote:
> > > > >> >> > >
> > > > >> >> > >> 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 <
> > > > apurtell@apache.org
> > > > >> >
> > > > >> >> > wrote:
> > > > >> >> > >>
> > > > >> >> > >>>> 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 <
> > > > >> >> > >> vladrodionov@gmail.com>
> > > > >> >> > >>> wrote:
> > > > >> >> > >>>
> > > > >> >> > >>>> 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
> reviews
> > > and
> > > > >> has
> > > > >> >> > >> probably
> > > > >> >> > >>>> the most lengthy discussion thread on Apache JIRA
> > > > (HBASE-14123)
> > > > >> :)
> > > > >> >> > >>>>
> > > > >> >> > >>>> The work has been split into 3 phases (HBASE-14030,
> 14123,
> > > > >> 14414)
> > > > >> >> Two
> > > > >> >> > >> first
> > > > >> >> > >>>> are complete, third one is still in progress.
> > > > >> >> > >>>>
> > > > >> >> > >>>>
> > > > >> >> > >>>> *** Summary of work HBASE-14123
> > > > >> >> > >>>>
> > > > >> >> > >>>> The new feature introduces new command-line extensions
> to
> > > the
> > > > >> hbase
> > > > >> >> > >> command
> > > > >> >> > >>>> and, from the client side, is accessible through
> > > command-line
> > > > >> only
> > > > >> >> > >>>> Operations:
> > > > >> >> > >>>> * Create full backup on a list of tables or backup set
> > > > >> >> > >>>> * Create incremental backup image for table list or
> backup
> > > set
> > > > >> >> > >>>> * Restore list of tables from a given backup image
> > > > >> >> > >>>> * Show current backup progress
> > > > >> >> > >>>> * Delete backup image and all related images
> > > > >> >> > >>>> * Show history of backups
> > > > >> >> > >>>> * Backup set operations: create backup set, add/remove
> > table
> > > > >> >> to/from
> > > > >> >> > >> backup
> > > > >> >> > >>>> set, etc
> > > > >> >> > >>>>
> > > > >> >> > >>>> In the current implementation, the feature is already
> > > usable,
> > > > >> >> meaning
> > > > >> >> > >> that
> > > > >> >> > >>>> users can backup tables and restore them using provided
> > > > >> >> command-line
> > > > >> >> > >> tools.
> > > > >> >> > >>>> Both: full and incremental backups are supported.
> > > > >> >> > >>>> This work is based on original work of IBM team
> > > (HBASE-7912).
> > > > >> The
> > > > >> >> full
> > > > >> >> > >> list
> > > > >> >> > >>>> of JIRAs included in this mega patch can be found in
> three
> > > > >> umbrella
> > > > >> >> > >> JIRAs:
> > > > >> >> > >>>> HBASE-14030 (Phase 1), HBASE-14123 (Phase 2) and
> > HBASE-14414
> > > > >> >> (Phase 3
> > > > >> >> > -
> > > > >> >> > >> all
> > > > >> >> > >>>> resolved ones made it into the patch)
> > > > >> >> > >>>>
> > > > >> >> > >>>> *** What are the remaining work items
> > > > >> >> > >>>>
> > > > >> >> > >>>> All remaining items can be found in Phase 3 umbrella
> JIRA:
> > > > >> >> > HBASE-14414.
> > > > >> >> > >>>> They are split into 3 groups: BLOCKER, CRITICAL, MAJOR
> > > > >> >> > >>>> Only BLOCKERs and CRITICALs are guaranteed for HBase 2.0
> > > > >> release.
> > > > >> >> > >>>>
> > > > >> >> > >>>> ***** BLOCKER
> > > > >> >> > >>>>
> > > > >> >> > >>>> * HBASE-14417 Incremental backup and bulk loading (
> Patch
> > > > >> >> available)
> > > > >> >> > >>>> * HBASE-14135 HBase Backup/Restore Phase 3: Merge backup
> > > > images
> > > > >> >> > >>>> * HBASE-14141 HBase Backup/Restore Phase 3: Filter WALs
> on
> > > > >> backup
> > > > >> >> to
> > > > >> >> > >>>> include only edits from backup tables (Patch available)
> > > > >> >> > >>>> * HBASE-17133 Backup documentation
> > > > >> >> > >>>> * HBASE-15227 Fault tolerance support
> > > > >> >> > >>>>
> > > > >> >> > >>>> ***** CRITICAL
> > > > >> >> > >>>>
> > > > >> >> > >>>> * HBASE-16465 Disable split/merges during backup
> > > > >> >> > >>>>
> > > > >> >> > >>>> We have umbrella JIRA (HBASE-14414) to track all the
> > > remaining
> > > > >> work
> > > > >> >> > >>>> All the BLOCKER and CRITICAL JIRAs currently in open
> state
> > > > will
> > > > >> be
> > > > >> >> > >>>> implemented by 2.0 release time. Some MAJOR too, but it
> > > > depends
> > > > >> on
> > > > >> >> > >> resource
> > > > >> >> > >>>> availability
> > > > >> >> > >>>> The former development branch (HBASE-7912) is obsolete
> and
> > > > will
> > > > >> be
> > > > >> >> > >>>> closed/deleted after the merge.
> > > > >> >> > >>>> We want backup to be a GA feature in 2.0
> > > > >> >> > >>>> We are going to support full backward compatibility for
> > > backup
> > > > >> >> tool in
> > > > >> >> > >> 2.0
> > > > >> >> > >>>> and onwards.
> > > > >> >> > >>>>
> > > > >> >> > >>>> **** Configuration
> > > > >> >> > >>>>
> > > > >> >> > >>>> Backup is disabled, by default. To enable it, the
> > following
> > > > >> >> > >> configuration
> > > > >> >> > >>>> properties must be added to hbase-site.xml:
> > > > >> >> > >>>>
> > > > >> >> > >>>> hbase.backup.enable=true
> > > > >> >> > >>>> hbase.master.logcleaner.plugins=YOUR_PLUGINS,org.
> > > > >> >> > >>>> apache.hadoop.hbase.backup.master.BackupLogCleaner
> > > > >> >> > >>>> hbase.procedure.master.classes=YOUR_CLASSES,org.
> > > > >> >> > >>>> apache.hadoop.hbase.backup.master.
> > > > LogRollMasterProcedureManager
> > > > >> >> > >>>> hbase.procedure.regionserver.classes=YOUR_CLASSES,org.
> > > > >> >> > >>>> apache.hadoop.hbase.backup.regionserver.
> > > > >> >> > LogRollRegionServerProcedureMa
> > > > >> >> > >>>> nager
> > > > >> >> > >>>>
> > > > >> >> > >>>>
> > > > >> >> > >>>> I would like to thank IBM team and Jerry He for original
> > > work,
> > > > >> >> > >>>>
> > > > >> >> > >>>> Enis, Ted, Stack, Matteo, Jerry for time spent on code
> > > reviews
> > > > >> >> > >>>>
> > > > >> >> > >>>> Special thanks to Ted Yu for his co-development work.
> > > > >> >> > >>>>
> > > > >> >> > >>>> References:
> > > > >> >> > >>>>
> > > > >> >> > >>>> https://issues.apache.org/jira/browse/HBASE-7912
> > (original
> > > > IBM,
> > > > >> >> > >> contains
> > > > >> >> > >>>> design doc)
> > > > >> >> > >>>> https://issues.apache.org/jira/browse/HBASE-14030
> (Phase
> > 1)
> > > > >> >> > >>>> https://issues.apache.org/jira/browse/HBASE-14123
> (Phase
> > 2)
> > > > >> >> > >>>> https://issues.apache.org/jira/browse/HBASE-14414
> (Phase
> > 3)
> > > > >> >> > >>>>
> > > > >> >> > >>>> Please vote +1/-1 by midnight Pacific Time (00:00
> > > > >> >> > >>>> -0800 GMT) on March 11th on whether or not we should
> > merge
> > > > >> this
> > > > >> >> into
> > > > >> >> > >> the
> > > > >> >> > >>>> current master.
> > > > >> >> > >>>>
> > > > >> >> > >>>> -Vladimir Rodionov
> > > > >> >> > >>>>
> > > > >> >> > >>>
> > > > >> >> > >>>
> > > > >> >> > >>>
> > > > >> >> > >>> --
> > > > >> >> > >>> Best regards,
> > > > >> >> > >>>
> > > > >> >> > >>> - Andy
> > > > >> >> > >>>
> > > > >> >> > >>> If you are given a choice, you believe you have acted
> > > freely. -
> > > > >> >> Raymond
> > > > >> >> > >>> Teller (via Peter Watts)
> > > > >> >> > >>
> > > > >> >> > >
> > > > >> >> > >
> > > > >> >> > >
> > > > >> >> > > --
> > > > >> >> > > Best regards,
> > > > >> >> > >
> > > > >> >> > > - Andy
> > > > >> >> > >
> > > > >> >> > > If you are given a choice, you believe you have acted
> > freely. -
> > > > >> >> Raymond
> > > > >> >> > > Teller (via Peter Watts)
> > > > >> >> >
> > > > >> >>
> > > > >> >>
> > > > >> >>
> > > > >> >> --
> > > > >> >> Best regards,
> > > > >> >>
> > > > >> >> - Andy
> > > > >> >>
> > > > >> >> If you are given a choice, you believe you have acted freely. -
> > > > Raymond
> > > > >> >> Teller (via Peter Watts)
> > > > >> >>
> > > > >> >
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>
--
Best regards,
- Andy
If you are given a choice, you believe you have acted freely. - Raymond
Teller (via Peter Watts)
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
Posted by Ted Yu <yu...@gmail.com>.
I tried to delete the HBASE-14123 branch using commands I found on
http://stackoverflow.com/questions/2003505/how-to-delete-a-git-branch-both-locally-and-remotely
Not sure if there is lag on github side:
$ git push origin :origin/HBASE-14123
error: unable to delete 'origin/HBASE-14123': remote ref does not exist
error: failed to push some refs to '
https://git-wip-us.apache.org/repos/asf/hbase.git'
FYI
On Mon, Mar 13, 2017 at 4:05 PM, Enis Söztutar <en...@apache.org> wrote:
> I think there is some misconception of using the term "blockers" for
> referring to those jiras. My understanding is that those three jiras are
> blockers for the backup functionality to be more mature and more usable.
> But they are not release blockers. Let's say we merged the code in, and for
> some reason those did not get addressed in time. We can still do the 2.0
> release without having to wait for the commits. We can instead mark the
> "backup" feature as experimental with known issues and go on with the
> release. In that sense they are not real release 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
> luxury of having to wait another couple of months and doing yet another
> giant round of reviews because the code base is a moving target.
>
> Enis
>
> On Mon, Mar 13, 2017 at 3:46 PM, Devaraj Das <dd...@hortonworks.com> 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 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 to make the list of remaining work more complete by
> citing
> > that as pending work.
> > ________________________________________
> > From: Vladimir Rodionov <vl...@gmail.com>
> > 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 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 (including moving backup/restore
> out
> > of
> > >> core to live in its own module).
> >
> > For those who were not following our lengthy conversation on a review
> > board, separation of a backup code into a separate module has been
> > done last year, but has been reverted back by request of a reviewer.
> >
> >
> > -Vladimir
> >
> > On Mon, Mar 13, 2017 at 2:23 PM, Stack <st...@duboce.net> wrote:
> >
> > > On Fri, Mar 10, 2017 at 9:09 PM, Stack <st...@duboce.net> wrote:
> > >
> > > > On Fri, Mar 10, 2017 at 6:01 PM, Ted Yu <yu...@gmail.com> 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 burned a bunch of dev resource).
> > > >
> > > > The patch as is is now in a state where it is too big for our infra;
> rb
> > > > and JIRA are creaking under the size and # of iterations.
> > > >
> > > > Adding finish of new JIRAs to this merge implies a new round of
> review
> > > and
> > > > test of an already massive patch. Who is going to do this work?
> > > >
> > > > Going back to a new branch seems wrong route to take.
> > > >
> > > > St.Ack
> > > >
> > > >
> > > >
> > > To be more explicit, this patch was developed on a branch and then a
> > bunch
> > > of dev resources were burned getting it into a state where it could be
> > > merged to master. Going back to a branch to bulk up the merge so it
> > > includes more JIRAs than the many it already incorporates is the wrong
> > > direction for us to be headed in. It ignores the feedback given and the
> > > work done by Vladimir slimming down an already over-broad scope. It is
> > also
> > > predicated on abundant review and testing resource being on tap to
> cycle
> > on
> > > a feature that is useful, but non-core.
> > >
> > > The patch is ready for merge IMO. Geoffrey makes a nice list of what is
> > > still to do though IIRC, the list is incomplete because a bunch of
> > > follow-ons came of the review cycle (including moving backup/restore
> out
> > of
> > > core to live in its own module).
> > >
> > > The patch needs three votes to merge. I am not against merge but I am
> not
> > > voting for the patch because I do have any more time to spend on this
> > > non-core feature and feel that a vote will have me assume a
> > responsibility
> > > I will not shirk.
> > >
> > > S
> > >
> > >
> > >
> > > >
> > > >
> > > >
> > > >> FYI
> > > >>
> > > >> On Fri, Mar 10, 2017 at 3:30 PM, Ted Yu <yu...@gmail.com>
> 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 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,
> > we
> > > >> > propose to community for merging into branch-2 (master branch, if
> > > >> branch-2
> > > >> > doesn't materialize for whatever reason) again
> > > >> >
> > > >> > Cheers
> > > >> >
> > > >> >
> > > >> > On Fri, Mar 10, 2017 at 3:01 PM, Andrew Purtell <
> > apurtell@apache.org>
> > > >> > wrote:
> > > >> >
> > > >> >> 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 the documentation issue is important but not actually a
> > > >> blocker.
> > > >> >> That may be a controversial opinion, but documentation can be
> > > >> back-filled
> > > >> >> worst case. So take HBASE-17133 off the list.
> > > >> >>
> > > >> >> Remaining are effectively HBASE-14417, HBASE-14141, and
> > HBASE-15227.
> > > >> They
> > > >> >> all have patches attached to the respective JIRAs so completing
> > this
> > > >> work
> > > >> >> won't be onerous. Get these committed and I will lift my -1. The
> > > others
> > > >> >> who
> > > >> >> voted +1 on this thread surely can help with that.
> > > >> >>
> > > >> >> Thanks.
> > > >> >>
> > > >> >>
> > > >> >> On Fri, Mar 10, 2017 at 2:32 PM, Vladimir Rodionov <
> > > >> >> vladrodionov@gmail.com>
> > > >> >> wrote:
> > > >> >>
> > > >> >> > 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 <
> > apurtell@apache.org
> > > >
> > > >> >> 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
> > > >> 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 prevent that release because these blockers will
> be
> > > >> >> there. I
> > > >> >> > am
> > > >> >> > > inclined to veto. Probably we should not propose branch
> merges
> > > into
> > > >> >> code
> > > >> >> > we
> > > >> >> > > are trying to get out the door with known blockers. Why not
> do
> > > that
> > > >> >> work
> > > >> >> > > first? It seems an obvious question. Perhaps I am missing
> > > >> something.
> > > >> >> > >
> > > >> >> > > If we can branch for 2.0 now and then merge this, and not
> into
> > > the
> > > >> 2.0
> > > >> >> > > branch, I would vote +1 for branch merge even with known
> > blockers
> > > >> >> > pending.
> > > >> >> > >
> > > >> >> > >
> > > >> >> > > On Fri, Mar 10, 2017 at 1:42 PM, Vladimir Rodionov <
> > > >> >> > vladrodionov@gmail.com>
> > > >> >> > > wrote:
> > > >> >> > >
> > > >> >> > >> 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 <
> > > apurtell@apache.org
> > > >> >
> > > >> >> > wrote:
> > > >> >> > >>
> > > >> >> > >>>> 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 <
> > > >> >> > >> vladrodionov@gmail.com>
> > > >> >> > >>> wrote:
> > > >> >> > >>>
> > > >> >> > >>>> 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 reviews
> > and
> > > >> has
> > > >> >> > >> probably
> > > >> >> > >>>> the most lengthy discussion thread on Apache JIRA
> > > (HBASE-14123)
> > > >> :)
> > > >> >> > >>>>
> > > >> >> > >>>> The work has been split into 3 phases (HBASE-14030, 14123,
> > > >> 14414)
> > > >> >> Two
> > > >> >> > >> first
> > > >> >> > >>>> are complete, third one is still in progress.
> > > >> >> > >>>>
> > > >> >> > >>>>
> > > >> >> > >>>> *** Summary of work HBASE-14123
> > > >> >> > >>>>
> > > >> >> > >>>> The new feature introduces new command-line extensions to
> > the
> > > >> hbase
> > > >> >> > >> command
> > > >> >> > >>>> and, from the client side, is accessible through
> > command-line
> > > >> only
> > > >> >> > >>>> Operations:
> > > >> >> > >>>> * Create full backup on a list of tables or backup set
> > > >> >> > >>>> * Create incremental backup image for table list or backup
> > set
> > > >> >> > >>>> * Restore list of tables from a given backup image
> > > >> >> > >>>> * Show current backup progress
> > > >> >> > >>>> * Delete backup image and all related images
> > > >> >> > >>>> * Show history of backups
> > > >> >> > >>>> * Backup set operations: create backup set, add/remove
> table
> > > >> >> to/from
> > > >> >> > >> backup
> > > >> >> > >>>> set, etc
> > > >> >> > >>>>
> > > >> >> > >>>> In the current implementation, the feature is already
> > usable,
> > > >> >> meaning
> > > >> >> > >> that
> > > >> >> > >>>> users can backup tables and restore them using provided
> > > >> >> command-line
> > > >> >> > >> tools.
> > > >> >> > >>>> Both: full and incremental backups are supported.
> > > >> >> > >>>> This work is based on original work of IBM team
> > (HBASE-7912).
> > > >> The
> > > >> >> full
> > > >> >> > >> list
> > > >> >> > >>>> of JIRAs included in this mega patch can be found in three
> > > >> umbrella
> > > >> >> > >> JIRAs:
> > > >> >> > >>>> HBASE-14030 (Phase 1), HBASE-14123 (Phase 2) and
> HBASE-14414
> > > >> >> (Phase 3
> > > >> >> > -
> > > >> >> > >> all
> > > >> >> > >>>> resolved ones made it into the patch)
> > > >> >> > >>>>
> > > >> >> > >>>> *** What are the remaining work items
> > > >> >> > >>>>
> > > >> >> > >>>> All remaining items can be found in Phase 3 umbrella JIRA:
> > > >> >> > HBASE-14414.
> > > >> >> > >>>> They are split into 3 groups: BLOCKER, CRITICAL, MAJOR
> > > >> >> > >>>> Only BLOCKERs and CRITICALs are guaranteed for HBase 2.0
> > > >> release.
> > > >> >> > >>>>
> > > >> >> > >>>> ***** BLOCKER
> > > >> >> > >>>>
> > > >> >> > >>>> * HBASE-14417 Incremental backup and bulk loading ( Patch
> > > >> >> available)
> > > >> >> > >>>> * HBASE-14135 HBase Backup/Restore Phase 3: Merge backup
> > > images
> > > >> >> > >>>> * HBASE-14141 HBase Backup/Restore Phase 3: Filter WALs on
> > > >> backup
> > > >> >> to
> > > >> >> > >>>> include only edits from backup tables (Patch available)
> > > >> >> > >>>> * HBASE-17133 Backup documentation
> > > >> >> > >>>> * HBASE-15227 Fault tolerance support
> > > >> >> > >>>>
> > > >> >> > >>>> ***** CRITICAL
> > > >> >> > >>>>
> > > >> >> > >>>> * HBASE-16465 Disable split/merges during backup
> > > >> >> > >>>>
> > > >> >> > >>>> We have umbrella JIRA (HBASE-14414) to track all the
> > remaining
> > > >> work
> > > >> >> > >>>> All the BLOCKER and CRITICAL JIRAs currently in open state
> > > will
> > > >> be
> > > >> >> > >>>> implemented by 2.0 release time. Some MAJOR too, but it
> > > depends
> > > >> on
> > > >> >> > >> resource
> > > >> >> > >>>> availability
> > > >> >> > >>>> The former development branch (HBASE-7912) is obsolete and
> > > will
> > > >> be
> > > >> >> > >>>> closed/deleted after the merge.
> > > >> >> > >>>> We want backup to be a GA feature in 2.0
> > > >> >> > >>>> We are going to support full backward compatibility for
> > backup
> > > >> >> tool in
> > > >> >> > >> 2.0
> > > >> >> > >>>> and onwards.
> > > >> >> > >>>>
> > > >> >> > >>>> **** Configuration
> > > >> >> > >>>>
> > > >> >> > >>>> Backup is disabled, by default. To enable it, the
> following
> > > >> >> > >> configuration
> > > >> >> > >>>> properties must be added to hbase-site.xml:
> > > >> >> > >>>>
> > > >> >> > >>>> hbase.backup.enable=true
> > > >> >> > >>>> hbase.master.logcleaner.plugins=YOUR_PLUGINS,org.
> > > >> >> > >>>> apache.hadoop.hbase.backup.master.BackupLogCleaner
> > > >> >> > >>>> hbase.procedure.master.classes=YOUR_CLASSES,org.
> > > >> >> > >>>> apache.hadoop.hbase.backup.master.
> > > LogRollMasterProcedureManager
> > > >> >> > >>>> hbase.procedure.regionserver.classes=YOUR_CLASSES,org.
> > > >> >> > >>>> apache.hadoop.hbase.backup.regionserver.
> > > >> >> > LogRollRegionServerProcedureMa
> > > >> >> > >>>> nager
> > > >> >> > >>>>
> > > >> >> > >>>>
> > > >> >> > >>>> I would like to thank IBM team and Jerry He for original
> > work,
> > > >> >> > >>>>
> > > >> >> > >>>> Enis, Ted, Stack, Matteo, Jerry for time spent on code
> > reviews
> > > >> >> > >>>>
> > > >> >> > >>>> Special thanks to Ted Yu for his co-development work.
> > > >> >> > >>>>
> > > >> >> > >>>> References:
> > > >> >> > >>>>
> > > >> >> > >>>> https://issues.apache.org/jira/browse/HBASE-7912
> (original
> > > IBM,
> > > >> >> > >> contains
> > > >> >> > >>>> design doc)
> > > >> >> > >>>> https://issues.apache.org/jira/browse/HBASE-14030 (Phase
> 1)
> > > >> >> > >>>> https://issues.apache.org/jira/browse/HBASE-14123 (Phase
> 2)
> > > >> >> > >>>> https://issues.apache.org/jira/browse/HBASE-14414 (Phase
> 3)
> > > >> >> > >>>>
> > > >> >> > >>>> Please vote +1/-1 by midnight Pacific Time (00:00
> > > >> >> > >>>> -0800 GMT) on March 11th on whether or not we should
> merge
> > > >> this
> > > >> >> into
> > > >> >> > >> the
> > > >> >> > >>>> current master.
> > > >> >> > >>>>
> > > >> >> > >>>> -Vladimir Rodionov
> > > >> >> > >>>>
> > > >> >> > >>>
> > > >> >> > >>>
> > > >> >> > >>>
> > > >> >> > >>> --
> > > >> >> > >>> Best regards,
> > > >> >> > >>>
> > > >> >> > >>> - Andy
> > > >> >> > >>>
> > > >> >> > >>> If you are given a choice, you believe you have acted
> > freely. -
> > > >> >> Raymond
> > > >> >> > >>> Teller (via Peter Watts)
> > > >> >> > >>
> > > >> >> > >
> > > >> >> > >
> > > >> >> > >
> > > >> >> > > --
> > > >> >> > > Best regards,
> > > >> >> > >
> > > >> >> > > - Andy
> > > >> >> > >
> > > >> >> > > If you are given a choice, you believe you have acted
> freely. -
> > > >> >> Raymond
> > > >> >> > > Teller (via Peter Watts)
> > > >> >> >
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >> --
> > > >> >> Best regards,
> > > >> >>
> > > >> >> - Andy
> > > >> >>
> > > >> >> If you are given a choice, you believe you have acted freely. -
> > > Raymond
> > > >> >> Teller (via Peter Watts)
> > > >> >>
> > > >> >
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
>
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
Posted by Vladimir Rodionov <vl...@gmail.com>.
>> How would a user recover from such a state
User will need to run full backup for every table. No, we have not
encountered this issue during testing, but, of course, it is possible,
especially on a large cluster.
-Vlad
On Tue, Mar 14, 2017 at 2:36 PM, Josh Elser <el...@apache.org> wrote:
> Thanks for quick reply, Vlad!
>
> How would a user recover from such a state with the backup table in a
> broken state? Have you encountered such a scenario in your testing?
>
> The docs issue seems to be pretty minor too. I remember walking through
> the original patch (HBASE-16574) and it was pretty thorough.
>
>
> Vladimir Rodionov wrote:
>
>> Josh,
>>
>> On a doc side we have a very good manual:
>>
>> https://issues.apache.org/jira/secure/attachment/12829269/
>> Backup-and-Restore-Apache_19Sep2016.pdf
>>
>> The only thing what was changed is the command-line tools args format, but
>> you can start from there - just type command w/o args.
>>
>> In the current implementation the worst thing which could happen is a
>> failure during backup, which will leave backup system table in incomplete
>> state (read - broken). This won't affect cluster operations but may
>> prevent
>> further backup operations (will require full backup for all table to reset
>> broken system table).
>>
>> I am currently starting working on HBASE-15227. It will probably take a
>> week or two to finish.
>>
>> On a doc side, as I already mention we will need to update command-line
>> tool section in the doc I posted above.
>>
>>
>> -Vlad
>>
>>
>>
>>
>> On Tue, Mar 14, 2017 at 1:57 PM, Josh Elser<el...@apache.org> wrote:
>>
>> I took a moment to read through the "blockers" as originally identified by
>>> Vlad, and (to echo Enis' take) I read the majority of them as being
>>> blockers not for the next release, but for a "full-fledged feature". I'm
>>> going to intentional avoid addressing the discussion of shipping partial
>>> features (related, but not relevant at the moment).
>>>
>>> HBASE-15227 is actually the one that bothers me the most, with
>>> HBASE-17133
>>> coming in close behind. Vlad, is there any documentation you can point me
>>> to about what the current issues are with the current implementation? For
>>> example, what happens now if the system has some kind of "partial
>>> completion state"?
>>>
>>> Documentation is one of those that is really hard to judge. We want to
>>> get
>>> this code out for people to use (and to free up our strained dev
>>> resources), but what good is some feature if the docs are
>>> missing/incomplete?
>>>
>>> I think I could stomach the docs being inaccurate (with a clear
>>> disclaimer
>>> that the chapter is incomplete -- that's a 5min task). But, I think I
>>> need
>>> an answer about how the feature handles our common dist-sys category of
>>> problems 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
>>> problem as an (ignorant) user ;)
>>>
>>>
>>> Andrew Purtell wrote:
>>>
>>> I don't like that issues were identified as "blockers" but now there is
>>>> an
>>>> attempt to walk that back.
>>>>
>>>> I don't like that development of this feature has lingered for a long
>>>> time
>>>> in this unfinished state when this work could have been done by now, now
>>>> 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 look at the current state and be nonplussed. This will be yet
>>>> another half finished thing in 2.0 when this merge happens. Promises to
>>>> finish the unfinished work are nice but not 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 2.0 release to slip
>>>> further.
>>>>
>>>> Also, marking something experimental should be done on the merits of
>>>> that
>>>> evaluation, not simply to justify dropping unfinished work into a
>>>> release
>>>> branch.
>>>>
>>>> I will change my vote to -0.
>>>>
>>>>
>>>> On Mon, Mar 13, 2017 at 4:05 PM, Enis Söztutar<en...@apache.org>
>>>> wrote:
>>>>
>>>> I think there is some misconception of using the term "blockers" for
>>>>
>>>>> referring to those jiras. My understanding is that those three jiras
>>>>> are
>>>>> blockers for the backup functionality to be more mature and more
>>>>> usable.
>>>>> But they are not release blockers. Let's say we merged the code in, and
>>>>> for
>>>>> some reason those did not get addressed in time. We can still do the
>>>>> 2.0
>>>>> release without having to wait for the commits. We can instead mark the
>>>>> "backup" feature as experimental with known issues and go on with the
>>>>> release. In that sense they are not real release 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
>>>>> luxury of having to wait another couple of months and doing yet another
>>>>> giant round of reviews because the code base is a moving target.
>>>>>
>>>>> Enis
>>>>>
>>>>> On Mon, Mar 13, 2017 at 3:46 PM, Devaraj Das<dd...@hortonworks.com>
>>>>> 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 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 to make the list of remaining work more complete by
>>>>>>
>>>>>> citing
>>>>>
>>>>> that as pending work.
>>>>>> ________________________________________
>>>>>> From: Vladimir Rodionov<vl...@gmail.com>
>>>>>> 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 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 (including moving backup/restore
>>>>>>>>
>>>>>>>> out
>>>>>>>
>>>>>> of
>>>>>>
>>>>>> core to live in its own module).
>>>>>>> For those who were not following our lengthy conversation on a review
>>>>>>>
>>>>>> board, separation of a backup code into a separate module has been
>>>>>> done last year, but has been reverted back by request of a reviewer.
>>>>>>
>>>>>>
>>>>>> -Vladimir
>>>>>>
>>>>>> On Mon, Mar 13, 2017 at 2:23 PM, Stack<st...@duboce.net> wrote:
>>>>>>
>>>>>> On Fri, Mar 10, 2017 at 9:09 PM, Stack<st...@duboce.net> wrote:
>>>>>>
>>>>>>> On Fri, Mar 10, 2017 at 6:01 PM, Ted Yu<yu...@gmail.com>
>>>>>>> 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 burned a bunch of dev resource).
>>>>>>>>
>>>>>>>> The patch as is is now in a state where it is too big for our infra;
>>>>>>>>
>>>>>>>> rb
>>>>>>>
>>>>>> and JIRA are creaking under the size and # of iterations.
>>>>>>
>>>>>>> Adding finish of new JIRAs to this merge implies a new round of
>>>>>>>>
>>>>>>>> review
>>>>>>>
>>>>>> and
>>>>>>
>>>>>>> test of an already massive patch. Who is going to do this work?
>>>>>>>>
>>>>>>>> Going back to a new branch seems wrong route to take.
>>>>>>>>
>>>>>>>> St.Ack
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> To be more explicit, this patch was developed on a branch and then a
>>>>>>>>
>>>>>>> bunch
>>>>>>
>>>>>> of dev resources were burned getting it into a state where it could be
>>>>>>> merged to master. Going back to a branch to bulk up the merge so it
>>>>>>> includes more JIRAs than the many it already incorporates is the
>>>>>>> wrong
>>>>>>> direction for us to be headed in. It ignores the feedback given and
>>>>>>> the
>>>>>>> work done by Vladimir slimming down an already over-broad scope. It
>>>>>>> is
>>>>>>>
>>>>>>> also
>>>>>>
>>>>>> predicated on abundant review and testing resource being on tap to
>>>>>>>
>>>>>>> cycle
>>>>>> on
>>>>>>
>>>>>> a feature that is useful, but non-core.
>>>>>>>
>>>>>>> The patch is ready for merge IMO. Geoffrey makes a nice list of what
>>>>>>> is
>>>>>>> still to do though IIRC, the list is incomplete because a bunch of
>>>>>>> follow-ons came of the review cycle (including moving backup/restore
>>>>>>>
>>>>>>> out
>>>>>> of
>>>>>>
>>>>>> core to live in its own module).
>>>>>>>
>>>>>>> The patch needs three votes to merge. I am not against merge but I am
>>>>>>>
>>>>>>> not
>>>>>> voting for the patch because I do have any more time to spend on this
>>>>>>
>>>>>>> non-core feature and feel that a vote will have me assume a
>>>>>>>
>>>>>>> responsibility
>>>>>>
>>>>>> I will not shirk.
>>>>>>>
>>>>>>> S
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> FYI
>>>>>>>>
>>>>>>>>> On Fri, Mar 10, 2017 at 3:30 PM, Ted Yu<yu...@gmail.com>
>>>>>>>>>
>>>>>>>>> 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 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,
>>>>>>>>>
>>>>>>>> we
>>>>>>
>>>>>> propose to community for merging into branch-2 (master branch, if
>>>>>>>
>>>>>>>> branch-2
>>>>>>>>>
>>>>>>>>> doesn't materialize for whatever reason) again
>>>>>>>>>>
>>>>>>>>>> Cheers
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Mar 10, 2017 at 3:01 PM, Andrew Purtell<
>>>>>>>>>>
>>>>>>>>>> apurtell@apache.org>
>>>>>>>>>
>>>>>>>> wrote:
>>>>>>>
>>>>>>>> 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 the documentation issue is important but not actually a
>>>>>>>>>>>
>>>>>>>>>>> blocker.
>>>>>>>>>> That may be a controversial opinion, but documentation can be
>>>>>>>>>> back-filled
>>>>>>>>>> worst case. So take HBASE-17133 off the list.
>>>>>>>>>>
>>>>>>>>>>> Remaining are effectively HBASE-14417, HBASE-14141, and
>>>>>>>>>>>
>>>>>>>>>>> HBASE-15227.
>>>>>>>>>>
>>>>>>>>> They
>>>>>>>
>>>>>>>> all have patches attached to the respective JIRAs so completing
>>>>>>>>>> this
>>>>>>>>>>
>>>>>>>>> work
>>>>>>>
>>>>>>>> won't be onerous. Get these committed and I will lift my -1. The
>>>>>>>>>> others
>>>>>>>>>>
>>>>>>>>> who
>>>>>>>>
>>>>>>>>> voted +1 on this thread surely can help with that.
>>>>>>>>>>>
>>>>>>>>>>> Thanks.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Mar 10, 2017 at 2:32 PM, Vladimir Rodionov<
>>>>>>>>>>> vladrodionov@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> 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<
>>>>>>>>>>>> apurtell@apache.org
>>>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>> 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 prevent that release because these blockers will
>>>>>>>
>>>>>>>> be
>>>>>>>>>>>>
>>>>>>>>>>> there. I
>>>>>>
>>>>>>> am
>>>>>>>>>>>>
>>>>>>>>>>>> inclined to veto. Probably we should not propose branch
>>>>>>>>>>>>>
>>>>>>>>>>>>> merges
>>>>>>>>>>>>
>>>>>>>>>>> into
>>>>>>
>>>>>>> code
>>>>>>>>
>>>>>>>>> we
>>>>>>>>>>>>
>>>>>>>>>>>> are trying to get out the door with known blockers. Why not
>>>>>>>>>>>>>
>>>>>>>>>>>>> do
>>>>>>>>>>>>
>>>>>>>>>>> that
>>>>>>
>>>>>>> work
>>>>>>>>
>>>>>>>>> first? It seems an obvious question. Perhaps I am missing
>>>>>>>>>>>> something.
>>>>>>>>>>>>
>>>>>>>>>>> If we can branch for 2.0 now and then merge this, and not
>>>>>>>>>>
>>>>>>>>>>> into
>>>>>>>>>>>>
>>>>>>>>>>> the
>>>>>>
>>>>>>> 2.0
>>>>>>>>
>>>>>>>>> branch, I would vote +1 for branch merge even with known
>>>>>>>>>>
>>>>>>>>>>> blockers
>>>>>>>>>>>>
>>>>>>>>>>> pending.
>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, Mar 10, 2017 at 1:42 PM, Vladimir Rodionov<
>>>>>>>>>>>>>
>>>>>>>>>>>>> vladrodionov@gmail.com>
>>>>>>>>>>>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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<
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> apurtell@apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> 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<
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> vladrodionov@gmail.com>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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 reviews
>>>>>>>>>>>>>
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> has
>>>>>>>
>>>>>>>> probably
>>>>>>>>>>
>>>>>>>>>>> the most lengthy discussion thread on Apache JIRA
>>>>>>>>>>>>>>> (HBASE-14123)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> :)
>>>>>>>>
>>>>>>>>> The work has been split into 3 phases (HBASE-14030, 14123,
>>>>>>>>>>
>>>>>>>>>>> 14414)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Two
>>>>>>>>>>
>>>>>>>>>>> first
>>>>>>>>>>>>
>>>>>>>>>>>>> are complete, third one is still in progress.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> *** Summary of work HBASE-14123
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The new feature introduces new command-line extensions to
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> hbase
>>>>>>>
>>>>>>>> command
>>>>>>>>>>
>>>>>>>>>>> and, from the client side, is accessible through
>>>>>>>>>>>>>>> command-line
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> only
>>>>>>>
>>>>>>>> Operations:
>>>>>>>>>>
>>>>>>>>>>> * Create full backup on a list of tables or backup set
>>>>>>>>>>>>>>>> * Create incremental backup image for table list or backup
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> set
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> * Restore list of tables from a given backup image
>>>>>>>
>>>>>>>> * Show current backup progress
>>>>>>>>>>>>>>>> * Delete backup image and all related images
>>>>>>>>>>>>>>>> * Show history of backups
>>>>>>>>>>>>>>>> * Backup set operations: create backup set, add/remove
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> table
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> to/from
>>>>>>
>>>>>>> backup
>>>>>>>>>>>>
>>>>>>>>>>>>> set, etc
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> In the current implementation, the feature is already
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> usable,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> meaning
>>>>>>>
>>>>>>>> that
>>>>>>>>>>>>
>>>>>>>>>>>>> users can backup tables and restore them using provided
>>>>>>>>>>>>>>> command-line
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> tools.
>>>>>>>>>>>>
>>>>>>>>>>>>> Both: full and incremental backups are supported.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This work is based on original work of IBM team
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> (HBASE-7912).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The
>>>>>>>
>>>>>>>> full
>>>>>>>>>>
>>>>>>>>>>> list
>>>>>>>>>>>>
>>>>>>>>>>>>> of JIRAs included in this mega patch can be found in three
>>>>>>>>>>>>>>> umbrella
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> JIRAs:
>>>>>>>>>>
>>>>>>>>>>> HBASE-14030 (Phase 1), HBASE-14123 (Phase 2) and
>>>>>>>>>>>>>>> HBASE-14414
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> (Phase 3
>>>>>>
>>>>>>> -
>>>>>>>>>>>>
>>>>>>>>>>>> all
>>>>>>>>>>>>>
>>>>>>>>>>>>>> resolved ones made it into the patch)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> *** What are the remaining work items
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> All remaining items can be found in Phase 3 umbrella JIRA:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> HBASE-14414.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> They are split into 3 groups: BLOCKER, CRITICAL, MAJOR
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Only BLOCKERs and CRITICALs are guaranteed for HBase 2.0
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ***** BLOCKER
>>>>>>>>>>
>>>>>>>>>>> * HBASE-14417 Incremental backup and bulk loading ( Patch
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> available)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> * HBASE-14135 HBase Backup/Restore Phase 3: Merge backup
>>>>>>>>>>>>
>>>>>>>>>>>>> images
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> * HBASE-14141 HBase Backup/Restore Phase 3: Filter WALs on
>>>>>>>>
>>>>>>>>> backup
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> to
>>>>>>>>>>
>>>>>>>>>>> include only edits from backup tables (Patch available)
>>>>>>>>>>>>
>>>>>>>>>>>>> * HBASE-17133 Backup documentation
>>>>>>>>>>>>>>>> * HBASE-15227 Fault tolerance support
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ***** CRITICAL
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> * HBASE-16465 Disable split/merges during backup
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> We have umbrella JIRA (HBASE-14414) to track all the
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> remaining
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> work
>>>>>>>
>>>>>>>> All the BLOCKER and CRITICAL JIRAs currently in open state
>>>>>>>>>>
>>>>>>>>>>> will
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> be
>>>>>>>>
>>>>>>>>> implemented by 2.0 release time. Some MAJOR too, but it
>>>>>>>>>>
>>>>>>>>>>> depends
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> on
>>>>>>>>
>>>>>>>>> resource
>>>>>>>>>>
>>>>>>>>>>> availability
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The former development branch (HBASE-7912) is obsolete and
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> be
>>>>>>>>
>>>>>>>>> closed/deleted after the merge.
>>>>>>>>>>
>>>>>>>>>>> We want backup to be a GA feature in 2.0
>>>>>>>>>>>>>>>> We are going to support full backward compatibility for
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> backup
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> tool in
>>>>>>>
>>>>>>>> 2.0
>>>>>>>>>>>>
>>>>>>>>>>>>> and onwards.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> **** Configuration
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Backup is disabled, by default. To enable it, the
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> following
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> configuration
>>>>>>
>>>>>>> properties must be added to hbase-site.xml:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> hbase.backup.enable=true
>>>>>>>>>>>>>>>> hbase.master.logcleaner.plugins=YOUR_PLUGINS,org.
>>>>>>>>>>>>>>>> apache.hadoop.hbase.backup.master.BackupLogCleaner
>>>>>>>>>>>>>>>> hbase.procedure.master.classes=YOUR_CLASSES,org.
>>>>>>>>>>>>>>>> apache.hadoop.hbase.backup.master.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> LogRollMasterProcedureManager
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> hbase.procedure.regionserver.classes=YOUR_CLASSES,org.
>>>>>>>>
>>>>>>>>> apache.hadoop.hbase.backup.regionserver.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> LogRollRegionServerProcedureMa
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> nager
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I would like to thank IBM team and Jerry He for original
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> work,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Enis, Ted, Stack, Matteo, Jerry for time spent on code
>>>>>>>
>>>>>>>> reviews
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Special thanks to Ted Yu for his co-development work.
>>>>>>>
>>>>>>>> References:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-7912
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> (original
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> IBM,
>>>>>>
>>>>>>> contains
>>>>>>>>
>>>>>>>>> design doc)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-14030 (Phase
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 1)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-14123 (Phase
>>>>>>
>>>>>>> 2)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-14414 (Phase
>>>>>>
>>>>>>> 3)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please vote +1/-1 by midnight Pacific Time (00:00
>>>>>>
>>>>>>> -0800 GMT) on March 11th on whether or not we should
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> merge
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> this
>>>>>>
>>>>>>> into
>>>>>>>>>>
>>>>>>>>>>> the
>>>>>>>>>>>>
>>>>>>>>>>>>> current master.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -Vladimir Rodionov
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - Andy
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If you are given a choice, you believe you have acted
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> freely. -
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Raymond
>>>>>>>
>>>>>>>> Teller (via Peter Watts)
>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Andy
>>>>>>>>>>>>>
>>>>>>>>>>>>> If you are given a choice, you believe you have acted
>>>>>>>>>>>>>
>>>>>>>>>>>>> freely. -
>>>>>>>>>>>>
>>>>>>>>>>> Raymond
>>>>>>
>>>>>>> Teller (via Peter Watts)
>>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Best regards,
>>>>>>>>>>>
>>>>>>>>>>> - Andy
>>>>>>>>>>>
>>>>>>>>>>> If you are given a choice, you believe you have acted freely. -
>>>>>>>>>>>
>>>>>>>>>>> Raymond
>>>>>>>>>>
>>>>>>>>> Teller (via Peter Watts)
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>
>>>>
>>>>
>>
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
Posted by Josh Elser <el...@apache.org>.
Thanks for quick reply, Vlad!
How would a user recover from such a state with the backup table in a
broken state? Have you encountered such a scenario in your testing?
The docs issue seems to be pretty minor too. I remember walking through
the original patch (HBASE-16574) and it was pretty thorough.
Vladimir Rodionov wrote:
> Josh,
>
> On a doc side we have a very good manual:
>
> https://issues.apache.org/jira/secure/attachment/12829269/Backup-and-Restore-Apache_19Sep2016.pdf
>
> The only thing what was changed is the command-line tools args format, but
> you can start from there - just type command w/o args.
>
> In the current implementation the worst thing which could happen is a
> failure during backup, which will leave backup system table in incomplete
> state (read - broken). This won't affect cluster operations but may prevent
> further backup operations (will require full backup for all table to reset
> broken system table).
>
> I am currently starting working on HBASE-15227. It will probably take a
> week or two to finish.
>
> On a doc side, as I already mention we will need to update command-line
> tool section in the doc I posted above.
>
>
> -Vlad
>
>
>
>
> On Tue, Mar 14, 2017 at 1:57 PM, Josh Elser<el...@apache.org> wrote:
>
>> I took a moment to read through the "blockers" as originally identified by
>> Vlad, and (to echo Enis' take) I read the majority of them as being
>> blockers not for the next release, but for a "full-fledged feature". I'm
>> going to intentional avoid addressing the discussion of shipping partial
>> features (related, but not relevant at the moment).
>>
>> HBASE-15227 is actually the one that bothers me the most, with HBASE-17133
>> coming in close behind. Vlad, is there any documentation you can point me
>> to about what the current issues are with the current implementation? For
>> example, what happens now if the system has some kind of "partial
>> completion state"?
>>
>> Documentation is one of those that is really hard to judge. We want to get
>> this code out for people to use (and to free up our strained dev
>> resources), but what good is some feature if the docs are
>> missing/incomplete?
>>
>> I think I could stomach the docs being inaccurate (with a clear disclaimer
>> that the chapter is incomplete -- that's a 5min task). But, I think I need
>> an answer about how the feature handles our common dist-sys category of
>> problems 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
>> problem as an (ignorant) user ;)
>>
>>
>> Andrew Purtell wrote:
>>
>>> I don't like that issues were identified as "blockers" but now there is an
>>> attempt to walk that back.
>>>
>>> I don't like that development of this feature has lingered for a long time
>>> in this unfinished state when this work could have been done by now, now
>>> 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 look at the current state and be nonplussed. This will be yet
>>> another half finished thing in 2.0 when this merge happens. Promises to
>>> finish the unfinished work are nice but not 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 2.0 release to slip
>>> further.
>>>
>>> Also, marking something experimental should be done on the merits of that
>>> evaluation, not simply to justify dropping unfinished work into a release
>>> branch.
>>>
>>> I will change my vote to -0.
>>>
>>>
>>> On Mon, Mar 13, 2017 at 4:05 PM, Enis S�ztutar<en...@apache.org> wrote:
>>>
>>> I think there is some misconception of using the term "blockers" for
>>>> referring to those jiras. My understanding is that those three jiras are
>>>> blockers for the backup functionality to be more mature and more usable.
>>>> But they are not release blockers. Let's say we merged the code in, and
>>>> for
>>>> some reason those did not get addressed in time. We can still do the 2.0
>>>> release without having to wait for the commits. We can instead mark the
>>>> "backup" feature as experimental with known issues and go on with the
>>>> release. In that sense they are not real release 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
>>>> luxury of having to wait another couple of months and doing yet another
>>>> giant round of reviews because the code base is a moving target.
>>>>
>>>> Enis
>>>>
>>>> On Mon, Mar 13, 2017 at 3:46 PM, Devaraj Das<dd...@hortonworks.com>
>>>> 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 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 to make the list of remaining work more complete by
>>>>>
>>>> citing
>>>>
>>>>> that as pending work.
>>>>> ________________________________________
>>>>> From: Vladimir Rodionov<vl...@gmail.com>
>>>>> 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 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 (including moving backup/restore
>>>>>>>
>>>>>> out
>>>>> of
>>>>>
>>>>>> core to live in its own module).
>>>>>> For those who were not following our lengthy conversation on a review
>>>>> board, separation of a backup code into a separate module has been
>>>>> done last year, but has been reverted back by request of a reviewer.
>>>>>
>>>>>
>>>>> -Vladimir
>>>>>
>>>>> On Mon, Mar 13, 2017 at 2:23 PM, Stack<st...@duboce.net> wrote:
>>>>>
>>>>> On Fri, Mar 10, 2017 at 9:09 PM, Stack<st...@duboce.net> wrote:
>>>>>> On Fri, Mar 10, 2017 at 6:01 PM, Ted Yu<yu...@gmail.com> 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 burned a bunch of dev resource).
>>>>>>>
>>>>>>> The patch as is is now in a state where it is too big for our infra;
>>>>>>>
>>>>>> rb
>>>>> and JIRA are creaking under the size and # of iterations.
>>>>>>> Adding finish of new JIRAs to this merge implies a new round of
>>>>>>>
>>>>>> review
>>>>> and
>>>>>>> test of an already massive patch. Who is going to do this work?
>>>>>>>
>>>>>>> Going back to a new branch seems wrong route to take.
>>>>>>>
>>>>>>> St.Ack
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> To be more explicit, this patch was developed on a branch and then a
>>>>> bunch
>>>>>
>>>>>> of dev resources were burned getting it into a state where it could be
>>>>>> merged to master. Going back to a branch to bulk up the merge so it
>>>>>> includes more JIRAs than the many it already incorporates is the wrong
>>>>>> direction for us to be headed in. It ignores the feedback given and the
>>>>>> work done by Vladimir slimming down an already over-broad scope. It is
>>>>>>
>>>>> also
>>>>>
>>>>>> predicated on abundant review and testing resource being on tap to
>>>>>>
>>>>> cycle
>>>>> on
>>>>>
>>>>>> a feature that is useful, but non-core.
>>>>>>
>>>>>> The patch is ready for merge IMO. Geoffrey makes a nice list of what is
>>>>>> still to do though IIRC, the list is incomplete because a bunch of
>>>>>> follow-ons came of the review cycle (including moving backup/restore
>>>>>>
>>>>> out
>>>>> of
>>>>>
>>>>>> core to live in its own module).
>>>>>>
>>>>>> The patch needs three votes to merge. I am not against merge but I am
>>>>>>
>>>>> not
>>>>> voting for the patch because I do have any more time to spend on this
>>>>>> non-core feature and feel that a vote will have me assume a
>>>>>>
>>>>> responsibility
>>>>>
>>>>>> I will not shirk.
>>>>>>
>>>>>> S
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> FYI
>>>>>>>> On Fri, Mar 10, 2017 at 3:30 PM, Ted Yu<yu...@gmail.com>
>>>>>>>>
>>>>>>> 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 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,
>>>>> we
>>>>>
>>>>>> propose to community for merging into branch-2 (master branch, if
>>>>>>>> branch-2
>>>>>>>>
>>>>>>>>> doesn't materialize for whatever reason) again
>>>>>>>>>
>>>>>>>>> Cheers
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Mar 10, 2017 at 3:01 PM, Andrew Purtell<
>>>>>>>>>
>>>>>>>> apurtell@apache.org>
>>>>>> wrote:
>>>>>>>>> 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 the documentation issue is important but not actually a
>>>>>>>>>>
>>>>>>>>> blocker.
>>>>>>>>> That may be a controversial opinion, but documentation can be
>>>>>>>>> back-filled
>>>>>>>>> worst case. So take HBASE-17133 off the list.
>>>>>>>>>> Remaining are effectively HBASE-14417, HBASE-14141, and
>>>>>>>>>>
>>>>>>>>> HBASE-15227.
>>>>>> They
>>>>>>>>> all have patches attached to the respective JIRAs so completing
>>>>>>>>> this
>>>>>> work
>>>>>>>>> won't be onerous. Get these committed and I will lift my -1. The
>>>>>>>>> others
>>>>>>> who
>>>>>>>>>> voted +1 on this thread surely can help with that.
>>>>>>>>>>
>>>>>>>>>> Thanks.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Mar 10, 2017 at 2:32 PM, Vladimir Rodionov<
>>>>>>>>>> vladrodionov@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> No problem I will downgrade Blockers to Majors if it scares
>>>>>>>>>> you,
>>>>> Andrew
>>>>>>>>> \U0001f642
>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>
>>>>>>>>>>> On Mar 10, 2017, at 1:52 PM, Andrew Purtell<
>>>>>>>>>>> apurtell@apache.org
>>>>>> wrote:
>>>>>>>>>>> \u200bI 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 prevent that release because these blockers will
>>>>>>>>>>> be
>>>>> there. I
>>>>>>>>>>> am
>>>>>>>>>>>
>>>>>>>>>>>> inclined to veto. Probably we should not propose branch
>>>>>>>>>>>>
>>>>>>>>>>> merges
>>>>> into
>>>>>>> code
>>>>>>>>>>> we
>>>>>>>>>>>
>>>>>>>>>>>> are trying to get out the door with known blockers. Why not
>>>>>>>>>>>>
>>>>>>>>>>> do
>>>>> that
>>>>>>> work
>>>>>>>>>>> first? It seems an obvious question. Perhaps I am missing
>>>>>>>>>>> something.
>>>>>>>>> If we can branch for 2.0 now and then merge this, and not
>>>>>>>>>>> into
>>>>> the
>>>>>>> 2.0
>>>>>>>>> branch, I would vote +1 for branch merge even with known
>>>>>>>>>>> blockers
>>>>>> pending.
>>>>>>>>>>>> \u200b
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Mar 10, 2017 at 1:42 PM, Vladimir Rodionov<
>>>>>>>>>>>>
>>>>>>>>>>> vladrodionov@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> 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<
>>>>>>>>>>>>>
>>>>>>>>>>>> apurtell@apache.org
>>>>>>> wrote:
>>>>>>>>>>>> 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<
>>>>>>>>>>>>>>
>>>>>>>>>>>>> vladrodionov@gmail.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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 reviews
>>>>>>>>>>>>>> and
>>>>>> has
>>>>>>>>> probably
>>>>>>>>>>>>>> the most lengthy discussion thread on Apache JIRA
>>>>>>>>>>>>>> (HBASE-14123)
>>>>>>> :)
>>>>>>>>> The work has been split into 3 phases (HBASE-14030, 14123,
>>>>>>>>>>>>>> 14414)
>>>>>>>>> Two
>>>>>>>>>>> first
>>>>>>>>>>>>>> are complete, third one is still in progress.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *** Summary of work HBASE-14123
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The new feature introduces new command-line extensions to
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> the
>>>>>> hbase
>>>>>>>>> command
>>>>>>>>>>>>>> and, from the client side, is accessible through
>>>>>>>>>>>>>> command-line
>>>>>> only
>>>>>>>>> Operations:
>>>>>>>>>>>>>>> * Create full backup on a list of tables or backup set
>>>>>>>>>>>>>>> * Create incremental backup image for table list or backup
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> set
>>>>>> * Restore list of tables from a given backup image
>>>>>>>>>>>>>>> * Show current backup progress
>>>>>>>>>>>>>>> * Delete backup image and all related images
>>>>>>>>>>>>>>> * Show history of backups
>>>>>>>>>>>>>>> * Backup set operations: create backup set, add/remove
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> table
>>>>> to/from
>>>>>>>>>>> backup
>>>>>>>>>>>>>> set, etc
>>>>>>>>>>>>>>> In the current implementation, the feature is already
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> usable,
>>>>>> meaning
>>>>>>>>>>> that
>>>>>>>>>>>>>> users can backup tables and restore them using provided
>>>>>>>>>>>>>> command-line
>>>>>>>>>>> tools.
>>>>>>>>>>>>>> Both: full and incremental backups are supported.
>>>>>>>>>>>>>>> This work is based on original work of IBM team
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> (HBASE-7912).
>>>>>> The
>>>>>>>>> full
>>>>>>>>>>> list
>>>>>>>>>>>>>> of JIRAs included in this mega patch can be found in three
>>>>>>>>>>>>>> umbrella
>>>>>>>>> JIRAs:
>>>>>>>>>>>>>> HBASE-14030 (Phase 1), HBASE-14123 (Phase 2) and
>>>>>>>>>>>>>> HBASE-14414
>>>>> (Phase 3
>>>>>>>>>>> -
>>>>>>>>>>>
>>>>>>>>>>>> all
>>>>>>>>>>>>>> resolved ones made it into the patch)
>>>>>>>>>>>>>>> *** What are the remaining work items
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> All remaining items can be found in Phase 3 umbrella JIRA:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> HBASE-14414.
>>>>>>>>>>>> They are split into 3 groups: BLOCKER, CRITICAL, MAJOR
>>>>>>>>>>>>>>> Only BLOCKERs and CRITICALs are guaranteed for HBase 2.0
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> release.
>>>>>>>>> ***** BLOCKER
>>>>>>>>>>>>>>> * HBASE-14417 Incremental backup and bulk loading ( Patch
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> available)
>>>>>>>>>>> * HBASE-14135 HBase Backup/Restore Phase 3: Merge backup
>>>>>>>>>>>>>> images
>>>>>>> * HBASE-14141 HBase Backup/Restore Phase 3: Filter WALs on
>>>>>>>>>>>>>> backup
>>>>>>>>> to
>>>>>>>>>>> include only edits from backup tables (Patch available)
>>>>>>>>>>>>>>> * HBASE-17133 Backup documentation
>>>>>>>>>>>>>>> * HBASE-15227 Fault tolerance support
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ***** CRITICAL
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> * HBASE-16465 Disable split/merges during backup
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We have umbrella JIRA (HBASE-14414) to track all the
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> remaining
>>>>>> work
>>>>>>>>> All the BLOCKER and CRITICAL JIRAs currently in open state
>>>>>>>>>>>>>> will
>>>>>>> be
>>>>>>>>> implemented by 2.0 release time. Some MAJOR too, but it
>>>>>>>>>>>>>> depends
>>>>>>> on
>>>>>>>>> resource
>>>>>>>>>>>>>> availability
>>>>>>>>>>>>>>> The former development branch (HBASE-7912) is obsolete and
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> will
>>>>>>> be
>>>>>>>>> closed/deleted after the merge.
>>>>>>>>>>>>>>> We want backup to be a GA feature in 2.0
>>>>>>>>>>>>>>> We are going to support full backward compatibility for
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> backup
>>>>>> tool in
>>>>>>>>>>> 2.0
>>>>>>>>>>>>>> and onwards.
>>>>>>>>>>>>>>> **** Configuration
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Backup is disabled, by default. To enable it, the
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> following
>>>>> configuration
>>>>>>>>>>>>>> properties must be added to hbase-site.xml:
>>>>>>>>>>>>>>> hbase.backup.enable=true
>>>>>>>>>>>>>>> hbase.master.logcleaner.plugins=YOUR_PLUGINS,org.
>>>>>>>>>>>>>>> apache.hadoop.hbase.backup.master.BackupLogCleaner
>>>>>>>>>>>>>>> hbase.procedure.master.classes=YOUR_CLASSES,org.
>>>>>>>>>>>>>>> apache.hadoop.hbase.backup.master.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> LogRollMasterProcedureManager
>>>>>>> hbase.procedure.regionserver.classes=YOUR_CLASSES,org.
>>>>>>>>>>>>>>> apache.hadoop.hbase.backup.regionserver.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> LogRollRegionServerProcedureMa
>>>>>>>>>>>> nager
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I would like to thank IBM team and Jerry He for original
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> work,
>>>>>> Enis, Ted, Stack, Matteo, Jerry for time spent on code
>>>>>>>>>>>>>> reviews
>>>>>> Special thanks to Ted Yu for his co-development work.
>>>>>>>>>>>>>>> References:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-7912
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> (original
>>>>> IBM,
>>>>>>> contains
>>>>>>>>>>>>>> design doc)
>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-14030 (Phase
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1)
>>>>> https://issues.apache.org/jira/browse/HBASE-14123 (Phase
>>>>>>>>>>>>>> 2)
>>>>> https://issues.apache.org/jira/browse/HBASE-14414 (Phase
>>>>>>>>>>>>>> 3)
>>>>> Please vote +1/-1 by midnight Pacific Time (00:00
>>>>>>>>>>>>>>> -0800 GMT) on March 11th \u200bon whether or not we should
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> merge
>>>>> this
>>>>>>>>> into
>>>>>>>>>>> the
>>>>>>>>>>>>>> current master.
>>>>>>>>>>>>>>> -Vladimir Rodionov
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - Andy
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If you are given a choice, you believe you have acted
>>>>>>>>>>>>>>
>>>>>>>>>>>>> freely. -
>>>>>> Raymond
>>>>>>>>>>> Teller (via Peter Watts)
>>>>>>>>>>>> --
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>
>>>>>>>>>>>> - Andy
>>>>>>>>>>>>
>>>>>>>>>>>> If you are given a choice, you believe you have acted
>>>>>>>>>>>>
>>>>>>>>>>> freely. -
>>>>> Raymond
>>>>>>>>>>> Teller (via Peter Watts)
>>>>>>>>>> --
>>>>>>>>>> Best regards,
>>>>>>>>>>
>>>>>>>>>> - Andy
>>>>>>>>>>
>>>>>>>>>> If you are given a choice, you believe you have acted freely. -
>>>>>>>>>>
>>>>>>>>> Raymond
>>>>>>> Teller (via Peter Watts)
>>>>>>>>>>
>>>
>>>
>
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
Posted by Ted Yu <yu...@gmail.com>.
Clarification:
Due to the divergence of HBASE-7912 branch from master branch, I think the
conclusion of this vote means that mega patch v61 on HBASE-14123 would be
integrated to master branch directly (with credit to people who
contributed).
On Wed, Mar 15, 2017 at 5:51 PM, Ted Yu <yu...@gmail.com> wrote:
> Thanks for the vote, Josh.
>
> So far there have been 3 +1's (Enis', mine and Josh's)
>
> Should we start another thread on the procedure of merging or use this
> thread ?
> Background:
> HBASE-7912 branch is way out of date.
> Latest rounds of mega patch were based on then-current master branch.
>
> Thanks
>
> On Wed, Mar 15, 2017 at 4:22 PM, Josh Elser <el...@apache.org> wrote:
>
>> Spent the day playing around with this on 6 nodes.
>>
>> I've found some rough edges: some known (the docs blocker Vlad pointed
>> out) and some that I think are unknown (tooling is rough -- partially from
>> wrong help messages and, I think, changes in design like Master-submitted
>> MR jobs).
>>
>> But, Stack's assessment (and Andrew's reminder) that further tweaking
>> would just throw us back into another review cycle is a real concern. It's
>> unfortunate that this feature has lingered so long aside of master to get
>> to this point, but I don't see any realistic resolution to this problem
>> than a merge. In the future, this is something we'll have to try harder to
>> avoid letting happen (looking in the mirror with quota work...)
>>
>> Thankfully, I can help out with development/review on the outstanding
>> blockers (notably, the two I pruned from Vlad's original of five -- the
>> other three still seem to be improvements). In addition to these blockers,
>> I believe the documentation *must* be updated before a release to note that
>> this feature is still growing -- it does not feel like a quality feature
>> that I've come to expect from this community. This isn't a knock on Vlad
>> and company; this is a hard problem and one that I could not have done
>> better given time constraints, but it is also one that users will demand
>> simplicity and the utmost correctness around. To this end, I will also try
>> to help out to smooth out these issues in the following 2.x release.
>>
>> So, this leaves me to say: +1 to merge with the caveat that the docs are
>> updated to make sure that any known, user-pitfalls are clearly documented.
>> This vote also comes with as real of a promise that I can make to help
>> avoid any issues with this feature that would prevent a 2.0 release.
>>
>> Thanks to all the giants whose shoulders I'm standing on to be able to
>> make this vote.
>>
>> Andrew Purtell wrote:
>>
>>> Great, and I changed my vote to -0 because Stack made a good argument
>>> that
>>> making more changes would invalidate review up to this point, and I trust
>>> this will be resolved before release.
>>>
>>> On Tue, Mar 14, 2017 at 4:29 PM, Josh Elser<el...@apache.org> wrote:
>>>
>>> Sorry Andrew, let me clarify as that didn't come out right.
>>>>
>>>> I didn't mean that isn't a conversation worth having _now_, just that I
>>>> was intentionally avoiding it in my previous email because I didn't
>>>> understand the scope of those issues that Vlad had identified. I wanted
>>>> to
>>>> better understand what they were really meant for a user before coming
>>>> to
>>>> my own decision about whether or not I think they are blockers.
>>>>
>>>> That aside, I would agree with you that HBASE-15227 sounds like a real
>>>> blocker. Forcing a new full backup for every table sounds really bad --
>>>> that's not the kind of experience we'd want a user to have.
>>>>
>>>> Andrew Purtell wrote:
>>>>
>>>> I'm going to intentional avoid addressing the discussion of shipping
>>>>> partial features (related, but not relevant at the moment).
>>>>>
>>>>> Then we are not having the same conversation, because it is precisely
>>>>> because this is a vote for this feature to go into 2.0, which is
>>>>> already
>>>>> overdue, so should be released yesterday, that I took mention of
>>>>> "blocker"
>>>>> at face value. At least one of them seems to certainly approach this
>>>>> definition. It will be not user friendly, to say the least, to use
>>>>> this in
>>>>> a large scale deployment with HBASE-15227 unfinished. HBASE-15227
>>>>> currently
>>>>> has a severity of BLOCKER. Despite what is going on in our politics,
>>>>> words
>>>>> matter and we do not get to redefine them for convenience.
>>>>>
>>>>> Once this work is merged in, how is HBASE-15227 not a blocker for 2.0?
>>>>> Because Vlad offered to reduce its severity to make me feel better?
>>>>> Currently the description on the issue is "System must be tolerant to
>>>>> faults. Backup operations MUST be atomic (no partial completion state
>>>>> in
>>>>> system table)" Sounds like a blocker to me, indeed. It is an honest
>>>>> assessment and I don't think anyone is doing the community a favor by
>>>>> trying to walk that back.
>>>>>
>>>>>
>>>>> On Tue, Mar 14, 2017 at 1:57 PM, Josh Elser<el...@apache.org>
>>>>> wrote:
>>>>>
>>>>> I took a moment to read through the "blockers" as originally
>>>>> identified by
>>>>>
>>>>>> Vlad, and (to echo Enis' take) I read the majority of them as being
>>>>>> blockers not for the next release, but for a "full-fledged feature".
>>>>>> I'm
>>>>>> going to intentional avoid addressing the discussion of shipping
>>>>>> partial
>>>>>> features (related, but not relevant at the moment).
>>>>>>
>>>>>> HBASE-15227 is actually the one that bothers me the most, with
>>>>>> HBASE-17133
>>>>>> coming in close behind. Vlad, is there any documentation you can
>>>>>> point me
>>>>>> to about what the current issues are with the current implementation?
>>>>>> For
>>>>>> example, what happens now if the system has some kind of "partial
>>>>>> completion state"?
>>>>>>
>>>>>> Documentation is one of those that is really hard to judge. We want to
>>>>>> get
>>>>>> this code out for people to use (and to free up our strained dev
>>>>>> resources), but what good is some feature if the docs are
>>>>>> missing/incomplete?
>>>>>>
>>>>>> I think I could stomach the docs being inaccurate (with a clear
>>>>>> disclaimer
>>>>>> that the chapter is incomplete -- that's a 5min task). But, I think I
>>>>>> need
>>>>>> an answer about how the feature handles our common dist-sys category
>>>>>> of
>>>>>> problems 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
>>>>>> problem as an (ignorant) user ;)
>>>>>>
>>>>>>
>>>>>> Andrew Purtell wrote:
>>>>>>
>>>>>> I don't like that issues were identified as "blockers" but now there
>>>>>> is
>>>>>>
>>>>>>> an
>>>>>>> attempt to walk that back.
>>>>>>>
>>>>>>> I don't like that development of this feature has lingered for a long
>>>>>>> time
>>>>>>> in this unfinished state when this work could have been done by now,
>>>>>>> now
>>>>>>> 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 look at the current state and be nonplussed. This will be
>>>>>>> yet
>>>>>>> another half finished thing in 2.0 when this merge happens. Promises
>>>>>>> to
>>>>>>> finish the unfinished work are nice but not 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 2.0 release to slip
>>>>>>> further.
>>>>>>>
>>>>>>> Also, marking something experimental should be done on the merits of
>>>>>>> that
>>>>>>> evaluation, not simply to justify dropping unfinished work into a
>>>>>>> release
>>>>>>> branch.
>>>>>>>
>>>>>>> I will change my vote to -0.
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Mar 13, 2017 at 4:05 PM, Enis Söztutar<en...@apache.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>> I think there is some misconception of using the term "blockers" for
>>>>>>>
>>>>>>> referring to those jiras. My understanding is that those three jiras
>>>>>>>> are
>>>>>>>> blockers for the backup functionality to be more mature and more
>>>>>>>> usable.
>>>>>>>> But they are not release blockers. Let's say we merged the code in,
>>>>>>>> and
>>>>>>>> for
>>>>>>>> some reason those did not get addressed in time. We can still do the
>>>>>>>> 2.0
>>>>>>>> release without having to wait for the commits. We can instead mark
>>>>>>>> the
>>>>>>>> "backup" feature as experimental with known issues and go on with
>>>>>>>> the
>>>>>>>> release. In that sense they are not real release 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
>>>>>>>> luxury of having to wait another couple of months and doing yet
>>>>>>>> another
>>>>>>>> giant round of reviews because the code base is a moving target.
>>>>>>>>
>>>>>>>> Enis
>>>>>>>>
>>>>>>>> On Mon, Mar 13, 2017 at 3:46 PM, Devaraj Das<dd...@hortonworks.com>
>>>>>>>> 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 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 to make the list of remaining work more complete by
>>>>>>>>
>>>>>>>>> citing
>>>>>>>>>
>>>>>>>> that as pending work.
>>>>>>>>
>>>>>>>>> ________________________________________
>>>>>>>>> From: Vladimir Rodionov<vl...@gmail.com>
>>>>>>>>> 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 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 (including moving
>>>>>>>>>> backup/restore
>>>>>>>>>>
>>>>>>>>>>> out
>>>>>>>>>>>
>>>>>>>>>> of
>>>>>>>>>
>>>>>>>>> core to live in its own module).
>>>>>>>>>
>>>>>>>>>> For those who were not following our lengthy conversation on a
>>>>>>>>>> review
>>>>>>>>>>
>>>>>>>>>> board, separation of a backup code into a separate module has been
>>>>>>>>> done last year, but has been reverted back by request of a
>>>>>>>>> reviewer.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -Vladimir
>>>>>>>>>
>>>>>>>>> On Mon, Mar 13, 2017 at 2:23 PM, Stack<st...@duboce.net> wrote:
>>>>>>>>>
>>>>>>>>> On Fri, Mar 10, 2017 at 9:09 PM, Stack<st...@duboce.net> wrote:
>>>>>>>>>
>>>>>>>>> On Fri, Mar 10, 2017 at 6:01 PM, Ted Yu<yu...@gmail.com>
>>>>>>>>>> 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 burned a bunch of dev resource).
>>>>>>>>>>
>>>>>>>>>>> The patch as is is now in a state where it is too big for our
>>>>>>>>>>> infra;
>>>>>>>>>>>
>>>>>>>>>>> rb
>>>>>>>>>>>
>>>>>>>>>> and JIRA are creaking under the size and # of iterations.
>>>>>>>>>
>>>>>>>>> Adding finish of new JIRAs to this merge implies a new round of
>>>>>>>>>>
>>>>>>>>>>> review
>>>>>>>>>>>
>>>>>>>>>> and
>>>>>>>>>
>>>>>>>>> test of an already massive patch. Who is going to do this work?
>>>>>>>>>>
>>>>>>>>>>> Going back to a new branch seems wrong route to take.
>>>>>>>>>>>
>>>>>>>>>>> St.Ack
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> To be more explicit, this patch was developed on a branch and
>>>>>>>>>>> then a
>>>>>>>>>>>
>>>>>>>>>>> bunch
>>>>>>>>>>
>>>>>>>>> of dev resources were burned getting it into a state where it
>>>>>>>>> could be
>>>>>>>>>
>>>>>>>>>> merged to master. Going back to a branch to bulk up the merge so
>>>>>>>>>> it
>>>>>>>>>> includes more JIRAs than the many it already incorporates is the
>>>>>>>>>> wrong
>>>>>>>>>> direction for us to be headed in. It ignores the feedback given
>>>>>>>>>> and
>>>>>>>>>> the
>>>>>>>>>> work done by Vladimir slimming down an already over-broad scope.
>>>>>>>>>> It
>>>>>>>>>> is
>>>>>>>>>>
>>>>>>>>>> also
>>>>>>>>>>
>>>>>>>>> predicated on abundant review and testing resource being on tap to
>>>>>>>>>
>>>>>>>>>> cycle
>>>>>>>>>>
>>>>>>>>> on
>>>>>>>>>
>>>>>>>>> a feature that is useful, but non-core.
>>>>>>>>>
>>>>>>>>>> The patch is ready for merge IMO. Geoffrey makes a nice list of
>>>>>>>>>> what
>>>>>>>>>> is
>>>>>>>>>> still to do though IIRC, the list is incomplete because a bunch of
>>>>>>>>>> follow-ons came of the review cycle (including moving
>>>>>>>>>> backup/restore
>>>>>>>>>>
>>>>>>>>>> out
>>>>>>>>>>
>>>>>>>>> of
>>>>>>>>>
>>>>>>>>> core to live in its own module).
>>>>>>>>>
>>>>>>>>>> The patch needs three votes to merge. I am not against merge but
>>>>>>>>>> I am
>>>>>>>>>>
>>>>>>>>>> not
>>>>>>>>>>
>>>>>>>>> voting for the patch because I do have any more time to spend on
>>>>>>>>> this
>>>>>>>>>
>>>>>>>>> non-core feature and feel that a vote will have me assume a
>>>>>>>>>>
>>>>>>>>>> responsibility
>>>>>>>>>>
>>>>>>>>> I will not shirk.
>>>>>>>>>
>>>>>>>>>> S
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> FYI
>>>>>>>>>>
>>>>>>>>>>> On Fri, Mar 10, 2017 at 3:30 PM, Ted Yu<yu...@gmail.com>
>>>>>>>>>>>>
>>>>>>>>>>>> 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 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,
>>>>>>>>>>>>>
>>>>>>>>>>>> we
>>>>>>>>>>>
>>>>>>>>>> propose to community for merging into branch-2 (master branch, if
>>>>>>>>>
>>>>>>>>>> branch-2
>>>>>>>>>>>
>>>>>>>>>>>> doesn't materialize for whatever reason) again
>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, Mar 10, 2017 at 3:01 PM, Andrew Purtell<
>>>>>>>>>>>>>
>>>>>>>>>>>>> apurtell@apache.org>
>>>>>>>>>>>>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>> 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 the documentation issue is important but not actually a
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> blocker.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> That may be a controversial opinion, but documentation can be
>>>>>>>>>>>>> back-filled
>>>>>>>>>>>>> worst case. So take HBASE-17133 off the list.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Remaining are effectively HBASE-14417, HBASE-14141, and
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> HBASE-15227.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> They
>>>>>>>>>>>>
>>>>>>>>>>> all have patches attached to the respective JIRAs so completing
>>>>>>>>>>>
>>>>>>>>>>>> this
>>>>>>>>>>>>>
>>>>>>>>>>>>> work
>>>>>>>>>>>>
>>>>>>>>>>> won't be onerous. Get these committed and I will lift my -1. The
>>>>>>>>>>>
>>>>>>>>>>>> others
>>>>>>>>>>>>>
>>>>>>>>>>>>> who
>>>>>>>>>>>> voted +1 on this thread surely can help with that.
>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, Mar 10, 2017 at 2:32 PM, Vladimir Rodionov<
>>>>>>>>>>>>>> vladrodionov@gmail.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No problem I will downgrade Blockers to Majors if it scares
>>>>>>>>>>>>>> you,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Andrew
>>>>>>>>>>>>>
>>>>>>>>>>>> [image: [image: 🙂]]
>>>>>>>>>>
>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mar 10, 2017, at 1:52 PM, Andrew Purtell<
>>>>>>>>>>>>>>> apurtell@apache.org
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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 prevent that release because these blockers will
>>>>>>>>>>>>>>
>>>>>>>>>>>>> be
>>>>>>>>>>>
>>>>>>>>>>>> there. I
>>>>>>>>>>>>>>
>>>>>>>>>>>>> am
>>>>>>>>>>
>>>>>>>>>>> inclined to veto. Probably we should not propose branch
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> merges
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> into
>>>>>>>>>>>>>>
>>>>>>>>>>>>> code
>>>>>>>>>>
>>>>>>>>>>> we
>>>>>>>>>>>>
>>>>>>>>>>>>> are trying to get out the door with known blockers. Why not
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> do
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>
>>>>>>>>>>>>> work
>>>>>>>>>>
>>>>>>>>>>> first? It seems an obvious question. Perhaps I am missing
>>>>>>>>>>>>
>>>>>>>>>>>>> something.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If we can branch for 2.0 now and then merge this, and not
>>>>>>>>>>>>>> into
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>
>>>>>>>>>>>>> 2.0
>>>>>>>>>>
>>>>>>>>>>> branch, I would vote +1 for branch merge even with known
>>>>>>>>>>>>
>>>>>>>>>>>>> blockers
>>>>>>>>>>>>>> pending.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Mar 10, 2017 at 1:42 PM, Vladimir Rodionov<
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> vladrodionov@gmail.com>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 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<
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> apurtell@apache.org
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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<
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> vladrodionov@gmail.com>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 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 reviews
>>>>>>>>>>>>
>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>> has
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> probably
>>>>>>>>>>>
>>>>>>>>>>>> the most lengthy discussion thread on Apache JIRA
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> (HBASE-14123)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> :)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The work has been split into 3 phases (HBASE-14030, 14123,
>>>>>>>>>>>>
>>>>>>>>>>>>> 14414)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Two
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> first
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> are complete, third one is still in progress.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> *** Summary of work HBASE-14123
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The new feature introduces new command-line extensions to
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> hbase
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> command
>>>>>>>>>>>
>>>>>>>>>>>> and, from the client side, is accessible through
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> command-line
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Operations:
>>>>>>>>>>>
>>>>>>>>>>>> * Create full backup on a list of tables or backup set
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> * Create incremental backup image for table list or backup
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> set
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> * Restore list of tables from a given backup image
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> * Show current backup progress
>>>>>>>>>>>
>>>>>>>>>>>> * Delete backup image and all related images
>>>>>>>>>>>>>>>>>>> * Show history of backups
>>>>>>>>>>>>>>>>>>> * Backup set operations: create backup set, add/remove
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> table
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> to/from
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> backup
>>>>>>>>>>
>>>>>>>>>>> set, etc
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> In the current implementation, the feature is already
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> usable,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> meaning
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> that
>>>>>>>>>>>
>>>>>>>>>>>> users can backup tables and restore them using provided
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> command-line
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> tools.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Both: full and incremental backups are supported.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This work is based on original work of IBM team
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> (HBASE-7912).
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> full
>>>>>>>>>>>
>>>>>>>>>>>> list
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> of JIRAs included in this mega patch can be found in three
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> umbrella
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> JIRAs:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> HBASE-14030 (Phase 1), HBASE-14123 (Phase 2) and
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> HBASE-14414
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> (Phase 3
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -
>>>>>>>>>>
>>>>>>>>>>> all
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> resolved ones made it into the patch)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> *** What are the remaining work items
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> All remaining items can be found in Phase 3 umbrella
>>>>>>>>>>>>>>>>>>> JIRA:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> HBASE-14414.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> They are split into 3 groups: BLOCKER, CRITICAL, MAJOR
>>>>>>>>>>>>>>>>> Only BLOCKERs and CRITICALs are guaranteed for HBase 2.0
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ***** BLOCKER
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> * HBASE-14417 Incremental backup and bulk loading ( Patch
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> available)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> * HBASE-14135 HBase Backup/Restore Phase 3: Merge backup
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> images
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> * HBASE-14141 HBase Backup/Restore Phase 3: Filter WALs on
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> backup
>>>>>>>>>>>>
>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> include only edits from backup tables (Patch available)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> * HBASE-17133 Backup documentation
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> * HBASE-15227 Fault tolerance support
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ***** CRITICAL
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> * HBASE-16465 Disable split/merges during backup
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> We have umbrella JIRA (HBASE-14414) to track all the
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> remaining
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> work
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> All the BLOCKER and CRITICAL JIRAs currently in open state
>>>>>>>>>>>
>>>>>>>>>>>> will
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> implemented by 2.0 release time. Some MAJOR too, but it
>>>>>>>>>>>>
>>>>>>>>>>>>> depends
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> resource
>>>>>>>>>>>>
>>>>>>>>>>>>> availability
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The former development branch (HBASE-7912) is obsolete and
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> closed/deleted after the merge.
>>>>>>>>>>>>
>>>>>>>>>>>>> We want backup to be a GA feature in 2.0
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We are going to support full backward compatibility for
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> backup
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> tool in
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2.0
>>>>>>>>>>>
>>>>>>>>>>>> and onwards.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> **** Configuration
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Backup is disabled, by default. To enable it, the
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> following
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> configuration
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> properties must be added to hbase-site.xml:
>>>>>>>>>>
>>>>>>>>>>> hbase.backup.enable=true
>>>>>>>>>>>>>>>>>>> hbase.master.logcleaner.plugins=YOUR_PLUGINS,org.
>>>>>>>>>>>>>>>>>>> apache.hadoop.hbase.backup.master.BackupLogCleaner
>>>>>>>>>>>>>>>>>>> hbase.procedure.master.classes=YOUR_CLASSES,org.
>>>>>>>>>>>>>>>>>>> apache.hadoop.hbase.backup.master.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> LogRollMasterProcedureManager
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> hbase.procedure.regionserver.classes=YOUR_CLASSES,org.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> apache.hadoop.hbase.backup.regionserver.
>>>>>>>>>>>>
>>>>>>>>>>>>> LogRollRegionServerProcedureMa
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> nager
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I would like to thank IBM team and Jerry He for original
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> work,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Enis, Ted, Stack, Matteo, Jerry for time spent on code
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> reviews
>>>>>>>>>>>
>>>>>>>>>>>> Special thanks to Ted Yu for his co-development work.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> References:
>>>>>>>>>>>
>>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-7912
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> (original
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> IBM,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> contains
>>>>>>>>>>
>>>>>>>>>>> design doc)
>>>>>>>>>>>>
>>>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-14030 (Phase
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 1)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-14123 (Phase
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2)
>>>>>>>>>>
>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-14414 (Phase
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 3)
>>>>>>>>>>
>>>>>>>>>>> Please vote +1/-1 by midnight Pacific Time (00:00
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -0800 GMT) on March 11th on whether or not we should
>>>>>>>>>>
>>>>>>>>>>> merge
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> into
>>>>>>>>>>
>>>>>>>>>>> the
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> current master.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> -Vladimir Rodionov
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> - Andy
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> If you are given a choice, you believe you have acted
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> freely. -
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Raymond
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Teller (via Peter Watts)
>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> - Andy
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If you are given a choice, you believe you have acted
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> freely. -
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Raymond
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Teller (via Peter Watts)
>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - Andy
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If you are given a choice, you believe you have acted freely.
>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Raymond
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Teller (via Peter Watts)
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>
>>>>>
>>>
>>>
>
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
Posted by Vladimir Rodionov <vl...@gmail.com>.
OK,
The VOTE is CLOSED successfully with 3 +1s (Enis, Ted, Josh) and the patch
will be committed to the master. All the remaining work will continue
against the master code.
Thanks, everyone
-Vlad
On Thu, Mar 16, 2017 at 10:13 PM, Stack <st...@duboce.net> wrote:
> On Thu, Mar 16, 2017 at 10:01 AM, Vladimir Rodionov <
> vladrodionov@gmail.com>
> wrote:
>
> > v61 is against current master.
> >
> >
> It was what I thought. I got confused by the hijacker.
> St.Ack
>
>
>
> > On Thu, Mar 16, 2017 at 7:18 AM, Stack <st...@duboce.net> wrote:
> >
> > > On Wed, Mar 15, 2017 at 11:38 PM, Vladimir Rodionov <
> > > vladrodionov@gmail.com>
> > > wrote:
> > >
> > > > >> I thought I was reviewing a patch that was against master
> > > >
> > > > Yes, it was against master. We used to develop in HBASE-7912 branch,
> > but
> > > it
> > > > was abandoned 6-8 mo ago.
> > > > This is why the only way to merge backup is to apply v61 directly to
> > > master
> > > > branch.
> > > >
> > > >
> > > If you are saying that v61 is against a master of 6-8 months ago, then
> > I'd
> > > think this VOTE is premature. Don't you have a mountain of rebasing to
> do
> > > before you can put your patch up for a vote?
> > >
> > > St.Ack
> > >
> > >
> > >
> > > > -Vlad
> > > >
> > > >
> > > > On Wed, Mar 15, 2017 at 9:17 PM, Stack <st...@duboce.net> wrote:
> > > >
> > > > > On Wed, Mar 15, 2017 at 5:51 PM, Ted Yu <yu...@gmail.com>
> wrote:
> > > > >
> > > > > > Thanks for the vote, Josh.
> > > > > >
> > > > > > So far there have been 3 +1's (Enis', mine and Josh's)
> > > > > >
> > > > > > Should we start another thread on the procedure of merging or use
> > > this
> > > > > > thread ?
> > > > > > Background:
> > > > > > HBASE-7912 branch is way out of date.
> > > > > > Latest rounds of mega patch were based on then-current master
> > branch.
> > > > > >
> > > > > >
> > > > > 1. Vlad is running this VOTE, not you.
> > > > > 2. Don't you need 3 PMC votes to merge? I count 2.
> > > > > 3. You almost derailed the merge with your earlier interjection
> > rushing
> > > > to
> > > > > take us in the wrong direction; you'd think you'd learn from your
> > past
> > > > > experience but here you are again w/ haste and rash summary.
> > > > > 4. This vote has been awkward. Josh's note is considered and
> careful.
> > > > You'd
> > > > > think it could hang out there a while to see if draws a response
> > rather
> > > > > than rush to close.
> > > > >
> > > > > I thought I was reviewing a patch that was against master, not some
> > > > version
> > > > > of master from eons ago. Thats a problem. When was the last rebase?
> > > > >
> > > > > St.Ack
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > > Thanks
> > > > > >
> > > > > > On Wed, Mar 15, 2017 at 4:22 PM, Josh Elser <el...@apache.org>
> > > wrote:
> > > > > >
> > > > > > > Spent the day playing around with this on 6 nodes.
> > > > > > >
> > > > > > > I've found some rough edges: some known (the docs blocker Vlad
> > > > pointed
> > > > > > > out) and some that I think are unknown (tooling is rough --
> > > partially
> > > > > > from
> > > > > > > wrong help messages and, I think, changes in design like
> > > > > Master-submitted
> > > > > > > MR jobs).
> > > > > > >
> > > > > > > But, Stack's assessment (and Andrew's reminder) that further
> > > tweaking
> > > > > > > would just throw us back into another review cycle is a real
> > > concern.
> > > > > > It's
> > > > > > > unfortunate that this feature has lingered so long aside of
> > master
> > > to
> > > > > get
> > > > > > > to this point, but I don't see any realistic resolution to this
> > > > problem
> > > > > > > than a merge. In the future, this is something we'll have to
> try
> > > > harder
> > > > > > to
> > > > > > > avoid letting happen (looking in the mirror with quota work...)
> > > > > > >
> > > > > > > Thankfully, I can help out with development/review on the
> > > outstanding
> > > > > > > blockers (notably, the two I pruned from Vlad's original of
> five
> > --
> > > > the
> > > > > > > other three still seem to be improvements). In addition to
> these
> > > > > > blockers,
> > > > > > > I believe the documentation *must* be updated before a release
> to
> > > > note
> > > > > > that
> > > > > > > this feature is still growing -- it does not feel like a
> quality
> > > > > feature
> > > > > > > that I've come to expect from this community. This isn't a
> knock
> > on
> > > > > Vlad
> > > > > > > and company; this is a hard problem and one that I could not
> have
> > > > done
> > > > > > > better given time constraints, but it is also one that users
> will
> > > > > demand
> > > > > > > simplicity and the utmost correctness around. To this end, I
> will
> > > > also
> > > > > > try
> > > > > > > to help out to smooth out these issues in the following 2.x
> > > release.
> > > > > > >
> > > > > > > So, this leaves me to say: +1 to merge with the caveat that the
> > > docs
> > > > > are
> > > > > > > updated to make sure that any known, user-pitfalls are clearly
> > > > > > documented.
> > > > > > > This vote also comes with as real of a promise that I can make
> to
> > > > help
> > > > > > > avoid any issues with this feature that would prevent a 2.0
> > > release.
> > > > > > >
> > > > > > > Thanks to all the giants whose shoulders I'm standing on to be
> > able
> > > > to
> > > > > > > make this vote.
> > > > > > >
> > > > > > > Andrew Purtell wrote:
> > > > > > >
> > > > > > >> Great, and I changed my vote to -0 because Stack made a good
> > > > argument
> > > > > > that
> > > > > > >> making more changes would invalidate review up to this point,
> > and
> > > I
> > > > > > trust
> > > > > > >> this will be resolved before release.
> > > > > > >>
> > > > > > >> On Tue, Mar 14, 2017 at 4:29 PM, Josh Elser<elserj@apache.org
> >
> > > > > wrote:
> > > > > > >>
> > > > > > >> Sorry Andrew, let me clarify as that didn't come out right.
> > > > > > >>>
> > > > > > >>> I didn't mean that isn't a conversation worth having _now_,
> > just
> > > > > that I
> > > > > > >>> was intentionally avoiding it in my previous email because I
> > > didn't
> > > > > > >>> understand the scope of those issues that Vlad had
> identified.
> > I
> > > > > wanted
> > > > > > >>> to
> > > > > > >>> better understand what they were really meant for a user
> before
> > > > > coming
> > > > > > to
> > > > > > >>> my own decision about whether or not I think they are
> blockers.
> > > > > > >>>
> > > > > > >>> That aside, I would agree with you that HBASE-15227 sounds
> > like a
> > > > > real
> > > > > > >>> blocker. Forcing a new full backup for every table sounds
> > really
> > > > bad
> > > > > --
> > > > > > >>> that's not the kind of experience we'd want a user to have.
> > > > > > >>>
> > > > > > >>> Andrew Purtell wrote:
> > > > > > >>>
> > > > > > >>> I'm going to intentional avoid addressing the discussion of
> > > > shipping
> > > > > > >>>> partial features (related, but not relevant at the moment).
> > > > > > >>>>
> > > > > > >>>> Then we are not having the same conversation, because it is
> > > > > precisely
> > > > > > >>>> because this is a vote for this feature to go into 2.0,
> which
> > is
> > > > > > already
> > > > > > >>>> overdue, so should be released yesterday, that I took
> mention
> > of
> > > > > > >>>> "blocker"
> > > > > > >>>> at face value. At least one of them seems to certainly
> > approach
> > > > this
> > > > > > >>>> definition. It will be not user friendly, to say the least,
> to
> > > use
> > > > > > this
> > > > > > >>>> in
> > > > > > >>>> a large scale deployment with HBASE-15227 unfinished.
> > > HBASE-15227
> > > > > > >>>> currently
> > > > > > >>>> has a severity of BLOCKER. Despite what is going on in our
> > > > politics,
> > > > > > >>>> words
> > > > > > >>>> matter and we do not get to redefine them for convenience.
> > > > > > >>>>
> > > > > > >>>> Once this work is merged in, how is HBASE-15227 not a
> blocker
> > > for
> > > > > 2.0?
> > > > > > >>>> Because Vlad offered to reduce its severity to make me feel
> > > > better?
> > > > > > >>>> Currently the description on the issue is "System must be
> > > tolerant
> > > > > to
> > > > > > >>>> faults. Backup operations MUST be atomic (no partial
> > completion
> > > > > state
> > > > > > in
> > > > > > >>>> system table)" Sounds like a blocker to me, indeed. It is an
> > > > honest
> > > > > > >>>> assessment and I don't think anyone is doing the community a
> > > favor
> > > > > by
> > > > > > >>>> trying to walk that back.
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>> On Tue, Mar 14, 2017 at 1:57 PM, Josh Elser<
> elserj@apache.org
> > >
> > > > > > wrote:
> > > > > > >>>>
> > > > > > >>>> I took a moment to read through the "blockers" as originally
> > > > > > identified
> > > > > > >>>> by
> > > > > > >>>>
> > > > > > >>>>> Vlad, and (to echo Enis' take) I read the majority of them
> as
> > > > being
> > > > > > >>>>> blockers not for the next release, but for a "full-fledged
> > > > > feature".
> > > > > > >>>>> I'm
> > > > > > >>>>> going to intentional avoid addressing the discussion of
> > > shipping
> > > > > > >>>>> partial
> > > > > > >>>>> features (related, but not relevant at the moment).
> > > > > > >>>>>
> > > > > > >>>>> HBASE-15227 is actually the one that bothers me the most,
> > with
> > > > > > >>>>> HBASE-17133
> > > > > > >>>>> coming in close behind. Vlad, is there any documentation
> you
> > > can
> > > > > > point
> > > > > > >>>>> me
> > > > > > >>>>> to about what the current issues are with the current
> > > > > implementation?
> > > > > > >>>>> For
> > > > > > >>>>> example, what happens now if the system has some kind of
> > > "partial
> > > > > > >>>>> completion state"?
> > > > > > >>>>>
> > > > > > >>>>> Documentation is one of those that is really hard to judge.
> > We
> > > > want
> > > > > > to
> > > > > > >>>>> get
> > > > > > >>>>> this code out for people to use (and to free up our
> strained
> > > dev
> > > > > > >>>>> resources), but what good is some feature if the docs are
> > > > > > >>>>> missing/incomplete?
> > > > > > >>>>>
> > > > > > >>>>> I think I could stomach the docs being inaccurate (with a
> > clear
> > > > > > >>>>> disclaimer
> > > > > > >>>>> that the chapter is incomplete -- that's a 5min task).
> But, I
> > > > > think I
> > > > > > >>>>> need
> > > > > > >>>>> an answer about how the feature handles our common dist-sys
> > > > > category
> > > > > > of
> > > > > > >>>>> problems 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
> > > > > > >>>>> problem as an (ignorant) user ;)
> > > > > > >>>>>
> > > > > > >>>>>
> > > > > > >>>>> Andrew Purtell wrote:
> > > > > > >>>>>
> > > > > > >>>>> I don't like that issues were identified as "blockers" but
> > now
> > > > > there
> > > > > > is
> > > > > > >>>>>
> > > > > > >>>>>> an
> > > > > > >>>>>> attempt to walk that back.
> > > > > > >>>>>>
> > > > > > >>>>>> I don't like that development of this feature has lingered
> > > for a
> > > > > > long
> > > > > > >>>>>> time
> > > > > > >>>>>> in this unfinished state when this work could have been
> done
> > > by
> > > > > now,
> > > > > > >>>>>> now
> > > > > > >>>>>> 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 look at the current state and be nonplussed.
> This
> > > will
> > > > > be
> > > > > > >>>>>> yet
> > > > > > >>>>>> another half finished thing in 2.0 when this merge
> happens.
> > > > > Promises
> > > > > > >>>>>> to
> > > > > > >>>>>> finish the unfinished work are nice but not 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 2.0 release
> > to
> > > > slip
> > > > > > >>>>>> further.
> > > > > > >>>>>>
> > > > > > >>>>>> Also, marking something experimental should be done on the
> > > > merits
> > > > > of
> > > > > > >>>>>> that
> > > > > > >>>>>> evaluation, not simply to justify dropping unfinished work
> > > into
> > > > a
> > > > > > >>>>>> release
> > > > > > >>>>>> branch.
> > > > > > >>>>>>
> > > > > > >>>>>> I will change my vote to -0.
> > > > > > >>>>>>
> > > > > > >>>>>>
> > > > > > >>>>>> On Mon, Mar 13, 2017 at 4:05 PM, Enis Söztutar<
> > > enis@apache.org>
> > > > > > >>>>>> wrote:
> > > > > > >>>>>>
> > > > > > >>>>>> I think there is some misconception of using the term
> > > "blockers"
> > > > > for
> > > > > > >>>>>>
> > > > > > >>>>>> referring to those jiras. My understanding is that those
> > three
> > > > > jiras
> > > > > > >>>>>>> are
> > > > > > >>>>>>> blockers for the backup functionality to be more mature
> and
> > > > more
> > > > > > >>>>>>> usable.
> > > > > > >>>>>>> But they are not release blockers. Let's say we merged
> the
> > > code
> > > > > in,
> > > > > > >>>>>>> and
> > > > > > >>>>>>> for
> > > > > > >>>>>>> some reason those did not get addressed in time. We can
> > still
> > > > do
> > > > > > the
> > > > > > >>>>>>> 2.0
> > > > > > >>>>>>> release without having to wait for the commits. We can
> > > instead
> > > > > mark
> > > > > > >>>>>>> the
> > > > > > >>>>>>> "backup" feature as experimental with known issues and go
> > on
> > > > with
> > > > > > the
> > > > > > >>>>>>> release. In that sense they are not real release
> 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
> > > > > > >>>>>>> luxury of having to wait another couple of months and
> doing
> > > yet
> > > > > > >>>>>>> another
> > > > > > >>>>>>> giant round of reviews because the code base is a moving
> > > > target.
> > > > > > >>>>>>>
> > > > > > >>>>>>> Enis
> > > > > > >>>>>>>
> > > > > > >>>>>>> On Mon, Mar 13, 2017 at 3:46 PM, Devaraj Das<
> > > > > ddas@hortonworks.com>
> > > > > > >>>>>>> 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 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 to make the list of remaining work more
> > > > complete
> > > > > > by
> > > > > > >>>>>>>
> > > > > > >>>>>>>> citing
> > > > > > >>>>>>>>
> > > > > > >>>>>>> that as pending work.
> > > > > > >>>>>>>
> > > > > > >>>>>>>> ________________________________________
> > > > > > >>>>>>>> From: Vladimir Rodionov<vl...@gmail.com>
> > > > > > >>>>>>>> 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 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 (including moving
> > > > > > backup/restore
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>>> out
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>> of
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> core to live in its own module).
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>> For those who were not following our lengthy
> conversation
> > > on
> > > > a
> > > > > > >>>>>>>>> review
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> board, separation of a backup code into a separate
> module
> > > has
> > > > > > been
> > > > > > >>>>>>>> done last year, but has been reverted back by request
> of a
> > > > > > reviewer.
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> -Vladimir
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> On Mon, Mar 13, 2017 at 2:23 PM, Stack<stack@duboce.net
> >
> > > > > > wrote:
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> On Fri, Mar 10, 2017 at 9:09 PM, Stack<stack@duboce.net
> >
> > > > > > wrote:
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> On Fri, Mar 10, 2017 at 6:01 PM, Ted Yu<
> > yuzhihong@gmail.com
> > > >
> > > > > > >>>>>>>>> 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 burned a bunch of dev
> > > > > resource).
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>>> The patch as is is now in a state where it is too big
> > for
> > > > our
> > > > > > >>>>>>>>>> infra;
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>> rb
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>> and JIRA are creaking under the size and # of
> iterations.
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> Adding finish of new JIRAs to this merge implies a new
> > round
> > > > of
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>>> review
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>> and
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> test of an already massive patch. Who is going to do
> this
> > > > work?
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>>> Going back to a new branch seems wrong route to take.
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>> St.Ack
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>> To be more explicit, this patch was developed on a
> > branch
> > > > and
> > > > > > >>>>>>>>>> then a
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>> bunch
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>> of dev resources were burned getting it into a state
> where
> > > it
> > > > > > could
> > > > > > >>>>>>>> be
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>> merged to master. Going back to a branch to bulk up the
> > > merge
> > > > > so
> > > > > > it
> > > > > > >>>>>>>>> includes more JIRAs than the many it already
> incorporates
> > > is
> > > > > the
> > > > > > >>>>>>>>> wrong
> > > > > > >>>>>>>>> direction for us to be headed in. It ignores the
> feedback
> > > > given
> > > > > > and
> > > > > > >>>>>>>>> the
> > > > > > >>>>>>>>> work done by Vladimir slimming down an already
> over-broad
> > > > > scope.
> > > > > > It
> > > > > > >>>>>>>>> is
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> also
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>> predicated on abundant review and testing resource being
> > on
> > > > tap
> > > > > to
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>> cycle
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>> on
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> a feature that is useful, but non-core.
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>> The patch is ready for merge IMO. Geoffrey makes a nice
> > > list
> > > > of
> > > > > > >>>>>>>>> what
> > > > > > >>>>>>>>> is
> > > > > > >>>>>>>>> still to do though IIRC, the list is incomplete
> because a
> > > > bunch
> > > > > > of
> > > > > > >>>>>>>>> follow-ons came of the review cycle (including moving
> > > > > > >>>>>>>>> backup/restore
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> out
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>> of
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> core to live in its own module).
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>> The patch needs three votes to merge. I am not against
> > > merge
> > > > > but
> > > > > > I
> > > > > > >>>>>>>>> am
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> not
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>> voting for the patch because I do have any more time to
> > > spend
> > > > on
> > > > > > >>>>>>>> this
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> non-core feature and feel that a vote will have me
> assume
> > a
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> responsibility
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>> I will not shirk.
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>> S
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> FYI
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>>> On Fri, Mar 10, 2017 at 3:30 PM, Ted Yu<
> > > yuzhihong@gmail.com
> > > > >
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>> 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 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,
> > > > > > >>>>>>>>>>>>
> > > > > > >>>>>>>>>>> we
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>> propose to community for merging into branch-2 (master
> > > > branch,
> > > > > if
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>> branch-2
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>>> doesn't materialize for whatever reason) again
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>>> Cheers
> > > > > > >>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>
> > > > > > >>>>>>>>>>>> On Fri, Mar 10, 2017 at 3:01 PM, Andrew Purtell<
> > > > > > >>>>>>>>>>>>
> > > > > > >>>>>>>>>>>> apurtell@apache.org>
> > > > > > >>>>>>>>>>>>
> > > > > > >>>>>>>>>>> wrote:
> > > > > > >>>>>>>>>> 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 the documentation issue is important but not
> > > > > actually
> > > > > > a
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>> blocker.
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>> That may be a controversial opinion, but
> documentation
> > > can
> > > > > be
> > > > > > >>>>>>>>>>>> back-filled
> > > > > > >>>>>>>>>>>> worst case. So take HBASE-17133 off the list.
> > > > > > >>>>>>>>>>>>
> > > > > > >>>>>>>>>>>> Remaining are effectively HBASE-14417, HBASE-14141,
> > and
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>> HBASE-15227.
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>> They
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>> all have patches attached to the respective JIRAs so
> > > > > completing
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>>> this
> > > > > > >>>>>>>>>>>>
> > > > > > >>>>>>>>>>>> work
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>> won't be onerous. Get these committed and I will lift
> my
> > > -1.
> > > > > The
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>>> others
> > > > > > >>>>>>>>>>>>
> > > > > > >>>>>>>>>>>> who
> > > > > > >>>>>>>>>>> voted +1 on this thread surely can help with that.
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>>> Thanks.
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>> On Fri, Mar 10, 2017 at 2:32 PM, Vladimir Rodionov<
> > > > > > >>>>>>>>>>>>> vladrodionov@gmail.com>
> > > > > > >>>>>>>>>>>>> wrote:
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>> No problem I will downgrade Blockers to Majors if
> it
> > > > scares
> > > > > > >>>>>>>>>>>>> you,
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>> Andrew
> > > > > > >>>>>>>>>>>>
> > > > > > >>>>>>>>>>> [image: [image: 🙂]]
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> Sent from my iPhone
> > > > > > >>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>> On Mar 10, 2017, at 1:52 PM, Andrew Purtell<
> > > > > > >>>>>>>>>>>>>> apurtell@apache.org
> > > > > > >>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>> 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
> > > > > > >>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>> 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 prevent that release because these
> > > blockers
> > > > > will
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>> be
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>>> there. I
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>> am
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>>> inclined to veto. Probably we should not propose
> branch
> > > > > > >>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>> merges
> > > > > > >>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>> into
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>> code
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>>> we
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>>> are trying to get out the door with known blockers.
> > Why
> > > > not
> > > > > > >>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>> do
> > > > > > >>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>> that
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>> work
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>>> first? It seems an obvious question. Perhaps I am
> > missing
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>>> something.
> > > > > > >>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>> If we can branch for 2.0 now and then merge this,
> > and
> > > > not
> > > > > > >>>>>>>>>>>>> into
> > > > > > >>>>>>>>>>>>> the
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>> 2.0
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>>> branch, I would vote +1 for branch merge even with
> known
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>>> blockers
> > > > > > >>>>>>>>>>>>> pending.
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>>> On Fri, Mar 10, 2017 at 1:42 PM, Vladimir Rodionov<
> > > > > > >>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>> vladrodionov@gmail.com>
> > > > > > >>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>> wrote:
> > > > > > >>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>> 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<
> > > > > > >>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>> apurtell@apache.org
> > > > > > >>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>> wrote:
> > > > > > >>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>> 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<
> > > > > > >>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>> vladrodionov@gmail.com>
> > > > > > >>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>> wrote:
> > > > > > >>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>> 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
> > > > > reviews
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>>> and
> > > > > > >>>>>>>>>>>>>>>> has
> > > > > > >>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>> probably
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>>> the most lengthy discussion thread on Apache JIRA
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>> (HBASE-14123)
> > > > > > >>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>> :)
> > > > > > >>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>> The work has been split into 3 phases
> (HBASE-14030,
> > > > > 14123,
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>>> 14414)
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>> Two
> > > > > > >>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>> first
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>> are complete, third one is still in progress.
> > > > > > >>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>> *** Summary of work HBASE-14123
> > > > > > >>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>>> The new feature introduces new command-line
> > > > extensions
> > > > > > to
> > > > > > >>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>>> the
> > > > > > >>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>> hbase
> > > > > > >>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>> command
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>>> and, from the client side, is accessible through
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>> command-line
> > > > > > >>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>> only
> > > > > > >>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>> Operations:
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>>> * Create full backup on a list of tables or backup
> set
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>> * Create incremental backup image for table list
> or
> > > > backup
> > > > > > >>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>>> set
> > > > > > >>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>> * Restore list of tables from a given backup
> > image
> > > > > > >>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>> * Show current backup progress
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>>> * Delete backup image and all related images
> > > > > > >>>>>>>>>>>>>>>>>> * Show history of backups
> > > > > > >>>>>>>>>>>>>>>>>> * Backup set operations: create backup set,
> > > > add/remove
> > > > > > >>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>>> table
> > > > > > >>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>> to/from
> > > > > > >>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>> backup
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>>> set, etc
> > > > > > >>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>> In the current implementation, the feature is
> > > already
> > > > > > >>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>>> usable,
> > > > > > >>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>> meaning
> > > > > > >>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>> that
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>>> users can backup tables and restore them using
> provided
> > > > > > >>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>> command-line
> > > > > > >>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>> tools.
> > > > > > >>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>> Both: full and incremental backups are supported.
> > > > > > >>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>> This work is based on original work of IBM team
> > > > > > >>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>>> (HBASE-7912).
> > > > > > >>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>> The
> > > > > > >>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>> full
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>>> list
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>> of JIRAs included in this mega patch can be found
> in
> > > > three
> > > > > > >>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>> umbrella
> > > > > > >>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>> JIRAs:
> > > > > > >>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>> HBASE-14030 (Phase 1), HBASE-14123 (Phase 2) and
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>> HBASE-14414
> > > > > > >>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>> (Phase 3
> > > > > > >>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>> -
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>>> all
> > > > > > >>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>> resolved ones made it into the patch)
> > > > > > >>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>> *** What are the remaining work items
> > > > > > >>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>>> All remaining items can be found in Phase 3
> > > umbrella
> > > > > > JIRA:
> > > > > > >>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>>> HBASE-14414.
> > > > > > >>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>> They are split into 3 groups: BLOCKER,
> CRITICAL,
> > > > MAJOR
> > > > > > >>>>>>>>>>>>>>>> Only BLOCKERs and CRITICALs are guaranteed for
> > HBase
> > > > 2.0
> > > > > > >>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>> release.
> > > > > > >>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>> ***** BLOCKER
> > > > > > >>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>> * HBASE-14417 Incremental backup and bulk
> loading (
> > > > Patch
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>> available)
> > > > > > >>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>> * HBASE-14135 HBase Backup/Restore Phase 3:
> Merge
> > > > > backup
> > > > > > >>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>> images
> > > > > > >>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>> * HBASE-14141 HBase Backup/Restore Phase 3:
> Filter
> > > > WALs
> > > > > on
> > > > > > >>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>> backup
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>>> to
> > > > > > >>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>> include only edits from backup tables (Patch
> > > available)
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>> * HBASE-17133 Backup documentation
> > > > > > >>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>> * HBASE-15227 Fault tolerance support
> > > > > > >>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>>> ***** CRITICAL
> > > > > > >>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>>> * HBASE-16465 Disable split/merges during
> backup
> > > > > > >>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>>> We have umbrella JIRA (HBASE-14414) to track
> all
> > > the
> > > > > > >>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>>> remaining
> > > > > > >>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>> work
> > > > > > >>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>> All the BLOCKER and CRITICAL JIRAs currently in
> > open
> > > > > state
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>>> will
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>> be
> > > > > > >>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>> implemented by 2.0 release time. Some MAJOR too,
> > but
> > > it
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>>> depends
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>> on
> > > > > > >>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>> resource
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>>> availability
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>> The former development branch (HBASE-7912) is
> > obsolete
> > > > and
> > > > > > >>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>>> will
> > > > > > >>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>> be
> > > > > > >>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>> closed/deleted after the merge.
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>>> We want backup to be a GA feature in 2.0
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>> We are going to support full backward
> compatibility
> > > for
> > > > > > >>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>>> backup
> > > > > > >>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>> tool in
> > > > > > >>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>> 2.0
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>>> and onwards.
> > > > > > >>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>> **** Configuration
> > > > > > >>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>>> Backup is disabled, by default. To enable it,
> > the
> > > > > > >>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>>> following
> > > > > > >>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>> configuration
> > > > > > >>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>> properties must be added to hbase-site.xml:
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>>> hbase.backup.enable=true
> > > > > > >>>>>>>>>>>>>>>>>> hbase.master.logcleaner.
> > plugins=YOUR_PLUGINS,org.
> > > > > > >>>>>>>>>>>>>>>>>> apache.hadoop.hbase.backup.
> > > master.BackupLogCleaner
> > > > > > >>>>>>>>>>>>>>>>>> hbase.procedure.master.
> > classes=YOUR_CLASSES,org.
> > > > > > >>>>>>>>>>>>>>>>>> apache.hadoop.hbase.backup.master.
> > > > > > >>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>>> LogRollMasterProcedureManager
> > > > > > >>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>> hbase.procedure.regionserver.
> > > > classes=YOUR_CLASSES,org.
> > > > > > >>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>> apache.hadoop.hbase.backup.regionserver.
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>>> LogRollRegionServerProcedureMa
> > > > > > >>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>> nager
> > > > > > >>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>> I would like to thank IBM team and Jerry He for
> > > > > original
> > > > > > >>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>>> work,
> > > > > > >>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>> Enis, Ted, Stack, Matteo, Jerry for time spent
> on
> > > > code
> > > > > > >>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>> reviews
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>>> Special thanks to Ted Yu for his co-development work.
> > > > > > >>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>> References:
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-7912
> > > > > > >>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>>> (original
> > > > > > >>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>> IBM,
> > > > > > >>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>> contains
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>>> design doc)
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-14030
> > > (Phase
> > > > > > >>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>>> 1)
> > > > > > >>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>> https://issues.apache.org/
> > jira/browse/HBASE-14123
> > > > > (Phase
> > > > > > >>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>> 2)
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-14414
> > (Phase
> > > > > > >>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>> 3)
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>>> Please vote +1/-1 by midnight Pacific Time (00:00
> > > > > > >>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>> -0800 GMT) on March 11th on whether or not we
> > > should
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>>> merge
> > > > > > >>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>> this
> > > > > > >>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>> into
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>>> the
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>> current master.
> > > > > > >>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>> -Vladimir Rodionov
> > > > > > >>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>>> --
> > > > > > >>>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>> Best regards,
> > > > > > >>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>> - Andy
> > > > > > >>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>> If you are given a choice, you believe you have
> > > acted
> > > > > > >>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>>> freely. -
> > > > > > >>>>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>>> Raymond
> > > > > > >>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>> Teller (via Peter Watts)
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>>> --
> > > > > > >>>>>>>>>>>>>>> Best regards,
> > > > > > >>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>> - Andy
> > > > > > >>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>> If you are given a choice, you believe you have
> > acted
> > > > > > >>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>>> freely. -
> > > > > > >>>>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>> Raymond
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>> Teller (via Peter Watts)
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>>> --
> > > > > > >>>>>>>>>>>>> Best regards,
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>> - Andy
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>> If you are given a choice, you believe you have
> acted
> > > > > > freely. -
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>> Raymond
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>> Teller (via Peter Watts)
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>
> > > > > > >>>>
> > > > > > >>
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
Posted by Stack <st...@duboce.net>.
On Thu, Mar 16, 2017 at 10:01 AM, Vladimir Rodionov <vl...@gmail.com>
wrote:
> v61 is against current master.
>
>
It was what I thought. I got confused by the hijacker.
St.Ack
> On Thu, Mar 16, 2017 at 7:18 AM, Stack <st...@duboce.net> wrote:
>
> > On Wed, Mar 15, 2017 at 11:38 PM, Vladimir Rodionov <
> > vladrodionov@gmail.com>
> > wrote:
> >
> > > >> I thought I was reviewing a patch that was against master
> > >
> > > Yes, it was against master. We used to develop in HBASE-7912 branch,
> but
> > it
> > > was abandoned 6-8 mo ago.
> > > This is why the only way to merge backup is to apply v61 directly to
> > master
> > > branch.
> > >
> > >
> > If you are saying that v61 is against a master of 6-8 months ago, then
> I'd
> > think this VOTE is premature. Don't you have a mountain of rebasing to do
> > before you can put your patch up for a vote?
> >
> > St.Ack
> >
> >
> >
> > > -Vlad
> > >
> > >
> > > On Wed, Mar 15, 2017 at 9:17 PM, Stack <st...@duboce.net> wrote:
> > >
> > > > On Wed, Mar 15, 2017 at 5:51 PM, Ted Yu <yu...@gmail.com> wrote:
> > > >
> > > > > Thanks for the vote, Josh.
> > > > >
> > > > > So far there have been 3 +1's (Enis', mine and Josh's)
> > > > >
> > > > > Should we start another thread on the procedure of merging or use
> > this
> > > > > thread ?
> > > > > Background:
> > > > > HBASE-7912 branch is way out of date.
> > > > > Latest rounds of mega patch were based on then-current master
> branch.
> > > > >
> > > > >
> > > > 1. Vlad is running this VOTE, not you.
> > > > 2. Don't you need 3 PMC votes to merge? I count 2.
> > > > 3. You almost derailed the merge with your earlier interjection
> rushing
> > > to
> > > > take us in the wrong direction; you'd think you'd learn from your
> past
> > > > experience but here you are again w/ haste and rash summary.
> > > > 4. This vote has been awkward. Josh's note is considered and careful.
> > > You'd
> > > > think it could hang out there a while to see if draws a response
> rather
> > > > than rush to close.
> > > >
> > > > I thought I was reviewing a patch that was against master, not some
> > > version
> > > > of master from eons ago. Thats a problem. When was the last rebase?
> > > >
> > > > St.Ack
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > > Thanks
> > > > >
> > > > > On Wed, Mar 15, 2017 at 4:22 PM, Josh Elser <el...@apache.org>
> > wrote:
> > > > >
> > > > > > Spent the day playing around with this on 6 nodes.
> > > > > >
> > > > > > I've found some rough edges: some known (the docs blocker Vlad
> > > pointed
> > > > > > out) and some that I think are unknown (tooling is rough --
> > partially
> > > > > from
> > > > > > wrong help messages and, I think, changes in design like
> > > > Master-submitted
> > > > > > MR jobs).
> > > > > >
> > > > > > But, Stack's assessment (and Andrew's reminder) that further
> > tweaking
> > > > > > would just throw us back into another review cycle is a real
> > concern.
> > > > > It's
> > > > > > unfortunate that this feature has lingered so long aside of
> master
> > to
> > > > get
> > > > > > to this point, but I don't see any realistic resolution to this
> > > problem
> > > > > > than a merge. In the future, this is something we'll have to try
> > > harder
> > > > > to
> > > > > > avoid letting happen (looking in the mirror with quota work...)
> > > > > >
> > > > > > Thankfully, I can help out with development/review on the
> > outstanding
> > > > > > blockers (notably, the two I pruned from Vlad's original of five
> --
> > > the
> > > > > > other three still seem to be improvements). In addition to these
> > > > > blockers,
> > > > > > I believe the documentation *must* be updated before a release to
> > > note
> > > > > that
> > > > > > this feature is still growing -- it does not feel like a quality
> > > > feature
> > > > > > that I've come to expect from this community. This isn't a knock
> on
> > > > Vlad
> > > > > > and company; this is a hard problem and one that I could not have
> > > done
> > > > > > better given time constraints, but it is also one that users will
> > > > demand
> > > > > > simplicity and the utmost correctness around. To this end, I will
> > > also
> > > > > try
> > > > > > to help out to smooth out these issues in the following 2.x
> > release.
> > > > > >
> > > > > > So, this leaves me to say: +1 to merge with the caveat that the
> > docs
> > > > are
> > > > > > updated to make sure that any known, user-pitfalls are clearly
> > > > > documented.
> > > > > > This vote also comes with as real of a promise that I can make to
> > > help
> > > > > > avoid any issues with this feature that would prevent a 2.0
> > release.
> > > > > >
> > > > > > Thanks to all the giants whose shoulders I'm standing on to be
> able
> > > to
> > > > > > make this vote.
> > > > > >
> > > > > > Andrew Purtell wrote:
> > > > > >
> > > > > >> Great, and I changed my vote to -0 because Stack made a good
> > > argument
> > > > > that
> > > > > >> making more changes would invalidate review up to this point,
> and
> > I
> > > > > trust
> > > > > >> this will be resolved before release.
> > > > > >>
> > > > > >> On Tue, Mar 14, 2017 at 4:29 PM, Josh Elser<el...@apache.org>
> > > > wrote:
> > > > > >>
> > > > > >> Sorry Andrew, let me clarify as that didn't come out right.
> > > > > >>>
> > > > > >>> I didn't mean that isn't a conversation worth having _now_,
> just
> > > > that I
> > > > > >>> was intentionally avoiding it in my previous email because I
> > didn't
> > > > > >>> understand the scope of those issues that Vlad had identified.
> I
> > > > wanted
> > > > > >>> to
> > > > > >>> better understand what they were really meant for a user before
> > > > coming
> > > > > to
> > > > > >>> my own decision about whether or not I think they are blockers.
> > > > > >>>
> > > > > >>> That aside, I would agree with you that HBASE-15227 sounds
> like a
> > > > real
> > > > > >>> blocker. Forcing a new full backup for every table sounds
> really
> > > bad
> > > > --
> > > > > >>> that's not the kind of experience we'd want a user to have.
> > > > > >>>
> > > > > >>> Andrew Purtell wrote:
> > > > > >>>
> > > > > >>> I'm going to intentional avoid addressing the discussion of
> > > shipping
> > > > > >>>> partial features (related, but not relevant at the moment).
> > > > > >>>>
> > > > > >>>> Then we are not having the same conversation, because it is
> > > > precisely
> > > > > >>>> because this is a vote for this feature to go into 2.0, which
> is
> > > > > already
> > > > > >>>> overdue, so should be released yesterday, that I took mention
> of
> > > > > >>>> "blocker"
> > > > > >>>> at face value. At least one of them seems to certainly
> approach
> > > this
> > > > > >>>> definition. It will be not user friendly, to say the least, to
> > use
> > > > > this
> > > > > >>>> in
> > > > > >>>> a large scale deployment with HBASE-15227 unfinished.
> > HBASE-15227
> > > > > >>>> currently
> > > > > >>>> has a severity of BLOCKER. Despite what is going on in our
> > > politics,
> > > > > >>>> words
> > > > > >>>> matter and we do not get to redefine them for convenience.
> > > > > >>>>
> > > > > >>>> Once this work is merged in, how is HBASE-15227 not a blocker
> > for
> > > > 2.0?
> > > > > >>>> Because Vlad offered to reduce its severity to make me feel
> > > better?
> > > > > >>>> Currently the description on the issue is "System must be
> > tolerant
> > > > to
> > > > > >>>> faults. Backup operations MUST be atomic (no partial
> completion
> > > > state
> > > > > in
> > > > > >>>> system table)" Sounds like a blocker to me, indeed. It is an
> > > honest
> > > > > >>>> assessment and I don't think anyone is doing the community a
> > favor
> > > > by
> > > > > >>>> trying to walk that back.
> > > > > >>>>
> > > > > >>>>
> > > > > >>>> On Tue, Mar 14, 2017 at 1:57 PM, Josh Elser<elserj@apache.org
> >
> > > > > wrote:
> > > > > >>>>
> > > > > >>>> I took a moment to read through the "blockers" as originally
> > > > > identified
> > > > > >>>> by
> > > > > >>>>
> > > > > >>>>> Vlad, and (to echo Enis' take) I read the majority of them as
> > > being
> > > > > >>>>> blockers not for the next release, but for a "full-fledged
> > > > feature".
> > > > > >>>>> I'm
> > > > > >>>>> going to intentional avoid addressing the discussion of
> > shipping
> > > > > >>>>> partial
> > > > > >>>>> features (related, but not relevant at the moment).
> > > > > >>>>>
> > > > > >>>>> HBASE-15227 is actually the one that bothers me the most,
> with
> > > > > >>>>> HBASE-17133
> > > > > >>>>> coming in close behind. Vlad, is there any documentation you
> > can
> > > > > point
> > > > > >>>>> me
> > > > > >>>>> to about what the current issues are with the current
> > > > implementation?
> > > > > >>>>> For
> > > > > >>>>> example, what happens now if the system has some kind of
> > "partial
> > > > > >>>>> completion state"?
> > > > > >>>>>
> > > > > >>>>> Documentation is one of those that is really hard to judge.
> We
> > > want
> > > > > to
> > > > > >>>>> get
> > > > > >>>>> this code out for people to use (and to free up our strained
> > dev
> > > > > >>>>> resources), but what good is some feature if the docs are
> > > > > >>>>> missing/incomplete?
> > > > > >>>>>
> > > > > >>>>> I think I could stomach the docs being inaccurate (with a
> clear
> > > > > >>>>> disclaimer
> > > > > >>>>> that the chapter is incomplete -- that's a 5min task). But, I
> > > > think I
> > > > > >>>>> need
> > > > > >>>>> an answer about how the feature handles our common dist-sys
> > > > category
> > > > > of
> > > > > >>>>> problems 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
> > > > > >>>>> problem as an (ignorant) user ;)
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>> Andrew Purtell wrote:
> > > > > >>>>>
> > > > > >>>>> I don't like that issues were identified as "blockers" but
> now
> > > > there
> > > > > is
> > > > > >>>>>
> > > > > >>>>>> an
> > > > > >>>>>> attempt to walk that back.
> > > > > >>>>>>
> > > > > >>>>>> I don't like that development of this feature has lingered
> > for a
> > > > > long
> > > > > >>>>>> time
> > > > > >>>>>> in this unfinished state when this work could have been done
> > by
> > > > now,
> > > > > >>>>>> now
> > > > > >>>>>> 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 look at the current state and be nonplussed. This
> > will
> > > > be
> > > > > >>>>>> yet
> > > > > >>>>>> another half finished thing in 2.0 when this merge happens.
> > > > Promises
> > > > > >>>>>> to
> > > > > >>>>>> finish the unfinished work are nice but not 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 2.0 release
> to
> > > slip
> > > > > >>>>>> further.
> > > > > >>>>>>
> > > > > >>>>>> Also, marking something experimental should be done on the
> > > merits
> > > > of
> > > > > >>>>>> that
> > > > > >>>>>> evaluation, not simply to justify dropping unfinished work
> > into
> > > a
> > > > > >>>>>> release
> > > > > >>>>>> branch.
> > > > > >>>>>>
> > > > > >>>>>> I will change my vote to -0.
> > > > > >>>>>>
> > > > > >>>>>>
> > > > > >>>>>> On Mon, Mar 13, 2017 at 4:05 PM, Enis Söztutar<
> > enis@apache.org>
> > > > > >>>>>> wrote:
> > > > > >>>>>>
> > > > > >>>>>> I think there is some misconception of using the term
> > "blockers"
> > > > for
> > > > > >>>>>>
> > > > > >>>>>> referring to those jiras. My understanding is that those
> three
> > > > jiras
> > > > > >>>>>>> are
> > > > > >>>>>>> blockers for the backup functionality to be more mature and
> > > more
> > > > > >>>>>>> usable.
> > > > > >>>>>>> But they are not release blockers. Let's say we merged the
> > code
> > > > in,
> > > > > >>>>>>> and
> > > > > >>>>>>> for
> > > > > >>>>>>> some reason those did not get addressed in time. We can
> still
> > > do
> > > > > the
> > > > > >>>>>>> 2.0
> > > > > >>>>>>> release without having to wait for the commits. We can
> > instead
> > > > mark
> > > > > >>>>>>> the
> > > > > >>>>>>> "backup" feature as experimental with known issues and go
> on
> > > with
> > > > > the
> > > > > >>>>>>> release. In that sense they are not real release 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
> > > > > >>>>>>> luxury of having to wait another couple of months and doing
> > yet
> > > > > >>>>>>> another
> > > > > >>>>>>> giant round of reviews because the code base is a moving
> > > target.
> > > > > >>>>>>>
> > > > > >>>>>>> Enis
> > > > > >>>>>>>
> > > > > >>>>>>> On Mon, Mar 13, 2017 at 3:46 PM, Devaraj Das<
> > > > ddas@hortonworks.com>
> > > > > >>>>>>> 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 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 to make the list of remaining work more
> > > complete
> > > > > by
> > > > > >>>>>>>
> > > > > >>>>>>>> citing
> > > > > >>>>>>>>
> > > > > >>>>>>> that as pending work.
> > > > > >>>>>>>
> > > > > >>>>>>>> ________________________________________
> > > > > >>>>>>>> From: Vladimir Rodionov<vl...@gmail.com>
> > > > > >>>>>>>> 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 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 (including moving
> > > > > backup/restore
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>> out
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>> of
> > > > > >>>>>>>>
> > > > > >>>>>>>> core to live in its own module).
> > > > > >>>>>>>>
> > > > > >>>>>>>>> For those who were not following our lengthy conversation
> > on
> > > a
> > > > > >>>>>>>>> review
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> board, separation of a backup code into a separate module
> > has
> > > > > been
> > > > > >>>>>>>> done last year, but has been reverted back by request of a
> > > > > reviewer.
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>> -Vladimir
> > > > > >>>>>>>>
> > > > > >>>>>>>> On Mon, Mar 13, 2017 at 2:23 PM, Stack<st...@duboce.net>
> > > > > wrote:
> > > > > >>>>>>>>
> > > > > >>>>>>>> On Fri, Mar 10, 2017 at 9:09 PM, Stack<st...@duboce.net>
> > > > > wrote:
> > > > > >>>>>>>>
> > > > > >>>>>>>> On Fri, Mar 10, 2017 at 6:01 PM, Ted Yu<
> yuzhihong@gmail.com
> > >
> > > > > >>>>>>>>> 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 burned a bunch of dev
> > > > resource).
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>> The patch as is is now in a state where it is too big
> for
> > > our
> > > > > >>>>>>>>>> infra;
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>> rb
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>> and JIRA are creaking under the size and # of iterations.
> > > > > >>>>>>>>
> > > > > >>>>>>>> Adding finish of new JIRAs to this merge implies a new
> round
> > > of
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>> review
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>> and
> > > > > >>>>>>>>
> > > > > >>>>>>>> test of an already massive patch. Who is going to do this
> > > work?
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>> Going back to a new branch seems wrong route to take.
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>> St.Ack
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>> To be more explicit, this patch was developed on a
> branch
> > > and
> > > > > >>>>>>>>>> then a
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>> bunch
> > > > > >>>>>>>>>
> > > > > >>>>>>>> of dev resources were burned getting it into a state where
> > it
> > > > > could
> > > > > >>>>>>>> be
> > > > > >>>>>>>>
> > > > > >>>>>>>>> merged to master. Going back to a branch to bulk up the
> > merge
> > > > so
> > > > > it
> > > > > >>>>>>>>> includes more JIRAs than the many it already incorporates
> > is
> > > > the
> > > > > >>>>>>>>> wrong
> > > > > >>>>>>>>> direction for us to be headed in. It ignores the feedback
> > > given
> > > > > and
> > > > > >>>>>>>>> the
> > > > > >>>>>>>>> work done by Vladimir slimming down an already over-broad
> > > > scope.
> > > > > It
> > > > > >>>>>>>>> is
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> also
> > > > > >>>>>>>>>
> > > > > >>>>>>>> predicated on abundant review and testing resource being
> on
> > > tap
> > > > to
> > > > > >>>>>>>>
> > > > > >>>>>>>>> cycle
> > > > > >>>>>>>>>
> > > > > >>>>>>>> on
> > > > > >>>>>>>>
> > > > > >>>>>>>> a feature that is useful, but non-core.
> > > > > >>>>>>>>
> > > > > >>>>>>>>> The patch is ready for merge IMO. Geoffrey makes a nice
> > list
> > > of
> > > > > >>>>>>>>> what
> > > > > >>>>>>>>> is
> > > > > >>>>>>>>> still to do though IIRC, the list is incomplete because a
> > > bunch
> > > > > of
> > > > > >>>>>>>>> follow-ons came of the review cycle (including moving
> > > > > >>>>>>>>> backup/restore
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> out
> > > > > >>>>>>>>>
> > > > > >>>>>>>> of
> > > > > >>>>>>>>
> > > > > >>>>>>>> core to live in its own module).
> > > > > >>>>>>>>
> > > > > >>>>>>>>> The patch needs three votes to merge. I am not against
> > merge
> > > > but
> > > > > I
> > > > > >>>>>>>>> am
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> not
> > > > > >>>>>>>>>
> > > > > >>>>>>>> voting for the patch because I do have any more time to
> > spend
> > > on
> > > > > >>>>>>>> this
> > > > > >>>>>>>>
> > > > > >>>>>>>> non-core feature and feel that a vote will have me assume
> a
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> responsibility
> > > > > >>>>>>>>>
> > > > > >>>>>>>> I will not shirk.
> > > > > >>>>>>>>
> > > > > >>>>>>>>> S
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> FYI
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>> On Fri, Mar 10, 2017 at 3:30 PM, Ted Yu<
> > yuzhihong@gmail.com
> > > >
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>> 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 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,
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>> we
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>> propose to community for merging into branch-2 (master
> > > branch,
> > > > if
> > > > > >>>>>>>>
> > > > > >>>>>>>>> branch-2
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>>> doesn't materialize for whatever reason) again
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>>> Cheers
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>> On Fri, Mar 10, 2017 at 3:01 PM, Andrew Purtell<
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>> apurtell@apache.org>
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>> wrote:
> > > > > >>>>>>>>>> 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 the documentation issue is important but not
> > > > actually
> > > > > a
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>> blocker.
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>> That may be a controversial opinion, but documentation
> > can
> > > > be
> > > > > >>>>>>>>>>>> back-filled
> > > > > >>>>>>>>>>>> worst case. So take HBASE-17133 off the list.
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>> Remaining are effectively HBASE-14417, HBASE-14141,
> and
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>> HBASE-15227.
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>> They
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>> all have patches attached to the respective JIRAs so
> > > > completing
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>>> this
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>> work
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>> won't be onerous. Get these committed and I will lift my
> > -1.
> > > > The
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>>> others
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>> who
> > > > > >>>>>>>>>>> voted +1 on this thread surely can help with that.
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>>> Thanks.
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>> On Fri, Mar 10, 2017 at 2:32 PM, Vladimir Rodionov<
> > > > > >>>>>>>>>>>>> vladrodionov@gmail.com>
> > > > > >>>>>>>>>>>>> wrote:
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>> No problem I will downgrade Blockers to Majors if it
> > > scares
> > > > > >>>>>>>>>>>>> you,
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>> Andrew
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>> [image: [image: 🙂]]
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> Sent from my iPhone
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>>> On Mar 10, 2017, at 1:52 PM, Andrew Purtell<
> > > > > >>>>>>>>>>>>>> apurtell@apache.org
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> 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
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> 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 prevent that release because these
> > blockers
> > > > will
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>> be
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>>> there. I
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>> am
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>> inclined to veto. Probably we should not propose branch
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> merges
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> into
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>> code
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>> we
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>>> are trying to get out the door with known blockers.
> Why
> > > not
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> do
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> that
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>> work
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>> first? It seems an obvious question. Perhaps I am
> missing
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>>> something.
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> If we can branch for 2.0 now and then merge this,
> and
> > > not
> > > > > >>>>>>>>>>>>> into
> > > > > >>>>>>>>>>>>> the
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>> 2.0
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>> branch, I would vote +1 for branch merge even with known
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>>> blockers
> > > > > >>>>>>>>>>>>> pending.
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>>> On Fri, Mar 10, 2017 at 1:42 PM, Vladimir Rodionov<
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> vladrodionov@gmail.com>
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> wrote:
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> 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<
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>> apurtell@apache.org
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> wrote:
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>> 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<
> > > > > >>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>> vladrodionov@gmail.com>
> > > > > >>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>> wrote:
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>> 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
> > > > reviews
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>>> and
> > > > > >>>>>>>>>>>>>>>> has
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> probably
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>>> the most lengthy discussion thread on Apache JIRA
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> (HBASE-14123)
> > > > > >>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>> :)
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> The work has been split into 3 phases (HBASE-14030,
> > > > 14123,
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>>> 14414)
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> Two
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> first
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> are complete, third one is still in progress.
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>> *** Summary of work HBASE-14123
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>> The new feature introduces new command-line
> > > extensions
> > > > > to
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>> the
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>> hbase
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> command
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>>> and, from the client side, is accessible through
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> command-line
> > > > > >>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>> only
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> Operations:
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>>> * Create full backup on a list of tables or backup set
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> * Create incremental backup image for table list or
> > > backup
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>> set
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>> * Restore list of tables from a given backup
> image
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> * Show current backup progress
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>>> * Delete backup image and all related images
> > > > > >>>>>>>>>>>>>>>>>> * Show history of backups
> > > > > >>>>>>>>>>>>>>>>>> * Backup set operations: create backup set,
> > > add/remove
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>> table
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>> to/from
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> backup
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>> set, etc
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>> In the current implementation, the feature is
> > already
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>> usable,
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>> meaning
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> that
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>>> users can backup tables and restore them using provided
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>> command-line
> > > > > >>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>> tools.
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> Both: full and incremental backups are supported.
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>> This work is based on original work of IBM team
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>> (HBASE-7912).
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>> The
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> full
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>>> list
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> of JIRAs included in this mega patch can be found in
> > > three
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>> umbrella
> > > > > >>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>> JIRAs:
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> HBASE-14030 (Phase 1), HBASE-14123 (Phase 2) and
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> HBASE-14414
> > > > > >>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>> (Phase 3
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> -
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>> all
> > > > > >>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> resolved ones made it into the patch)
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>> *** What are the remaining work items
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>> All remaining items can be found in Phase 3
> > umbrella
> > > > > JIRA:
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>> HBASE-14414.
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>> They are split into 3 groups: BLOCKER, CRITICAL,
> > > MAJOR
> > > > > >>>>>>>>>>>>>>>> Only BLOCKERs and CRITICALs are guaranteed for
> HBase
> > > 2.0
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>> release.
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>> ***** BLOCKER
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> * HBASE-14417 Incremental backup and bulk loading (
> > > Patch
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> available)
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>> * HBASE-14135 HBase Backup/Restore Phase 3: Merge
> > > > backup
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> images
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>> * HBASE-14141 HBase Backup/Restore Phase 3: Filter
> > > WALs
> > > > on
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> backup
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>>> to
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> include only edits from backup tables (Patch
> > available)
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> * HBASE-17133 Backup documentation
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>> * HBASE-15227 Fault tolerance support
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>> ***** CRITICAL
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>> * HBASE-16465 Disable split/merges during backup
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>> We have umbrella JIRA (HBASE-14414) to track all
> > the
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>> remaining
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>> work
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> All the BLOCKER and CRITICAL JIRAs currently in
> open
> > > > state
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>>> will
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> be
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> implemented by 2.0 release time. Some MAJOR too,
> but
> > it
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>>> depends
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> on
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> resource
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>>> availability
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> The former development branch (HBASE-7912) is
> obsolete
> > > and
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>> will
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>> be
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> closed/deleted after the merge.
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>>> We want backup to be a GA feature in 2.0
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> We are going to support full backward compatibility
> > for
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>> backup
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>> tool in
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> 2.0
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>>> and onwards.
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>> **** Configuration
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>> Backup is disabled, by default. To enable it,
> the
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>> following
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>> configuration
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> properties must be added to hbase-site.xml:
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>> hbase.backup.enable=true
> > > > > >>>>>>>>>>>>>>>>>> hbase.master.logcleaner.
> plugins=YOUR_PLUGINS,org.
> > > > > >>>>>>>>>>>>>>>>>> apache.hadoop.hbase.backup.
> > master.BackupLogCleaner
> > > > > >>>>>>>>>>>>>>>>>> hbase.procedure.master.
> classes=YOUR_CLASSES,org.
> > > > > >>>>>>>>>>>>>>>>>> apache.hadoop.hbase.backup.master.
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>> LogRollMasterProcedureManager
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>> hbase.procedure.regionserver.
> > > classes=YOUR_CLASSES,org.
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> apache.hadoop.hbase.backup.regionserver.
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>>> LogRollRegionServerProcedureMa
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>> nager
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>> I would like to thank IBM team and Jerry He for
> > > > original
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>> work,
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>> Enis, Ted, Stack, Matteo, Jerry for time spent on
> > > code
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> reviews
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>>> Special thanks to Ted Yu for his co-development work.
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> References:
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-7912
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>> (original
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>> IBM,
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> contains
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>> design doc)
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-14030
> > (Phase
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>> 1)
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>> https://issues.apache.org/
> jira/browse/HBASE-14123
> > > > (Phase
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> 2)
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-14414
> (Phase
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> 3)
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>> Please vote +1/-1 by midnight Pacific Time (00:00
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> -0800 GMT) on March 11th on whether or not we
> > should
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>> merge
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>> this
> > > > > >>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> into
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>> the
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> current master.
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>> -Vladimir Rodionov
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>>> --
> > > > > >>>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>> Best regards,
> > > > > >>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>> - Andy
> > > > > >>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>> If you are given a choice, you believe you have
> > acted
> > > > > >>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>>> freely. -
> > > > > >>>>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>>> Raymond
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> Teller (via Peter Watts)
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>>> --
> > > > > >>>>>>>>>>>>>>> Best regards,
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> - Andy
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> If you are given a choice, you believe you have
> acted
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>>> freely. -
> > > > > >>>>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>>> Raymond
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>> Teller (via Peter Watts)
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>> --
> > > > > >>>>>>>>>>>>> Best regards,
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>> - Andy
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>> If you are given a choice, you believe you have acted
> > > > > freely. -
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>> Raymond
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>> Teller (via Peter Watts)
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>
> > > > > >>>>>>
> > > > > >>>>
> > > > > >>
> > > > > >>
> > > > >
> > > >
> > >
> >
>
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
Posted by Vladimir Rodionov <vl...@gmail.com>.
v61 is against current master.
On Thu, Mar 16, 2017 at 7:18 AM, Stack <st...@duboce.net> wrote:
> On Wed, Mar 15, 2017 at 11:38 PM, Vladimir Rodionov <
> vladrodionov@gmail.com>
> wrote:
>
> > >> I thought I was reviewing a patch that was against master
> >
> > Yes, it was against master. We used to develop in HBASE-7912 branch, but
> it
> > was abandoned 6-8 mo ago.
> > This is why the only way to merge backup is to apply v61 directly to
> master
> > branch.
> >
> >
> If you are saying that v61 is against a master of 6-8 months ago, then I'd
> think this VOTE is premature. Don't you have a mountain of rebasing to do
> before you can put your patch up for a vote?
>
> St.Ack
>
>
>
> > -Vlad
> >
> >
> > On Wed, Mar 15, 2017 at 9:17 PM, Stack <st...@duboce.net> wrote:
> >
> > > On Wed, Mar 15, 2017 at 5:51 PM, Ted Yu <yu...@gmail.com> wrote:
> > >
> > > > Thanks for the vote, Josh.
> > > >
> > > > So far there have been 3 +1's (Enis', mine and Josh's)
> > > >
> > > > Should we start another thread on the procedure of merging or use
> this
> > > > thread ?
> > > > Background:
> > > > HBASE-7912 branch is way out of date.
> > > > Latest rounds of mega patch were based on then-current master branch.
> > > >
> > > >
> > > 1. Vlad is running this VOTE, not you.
> > > 2. Don't you need 3 PMC votes to merge? I count 2.
> > > 3. You almost derailed the merge with your earlier interjection rushing
> > to
> > > take us in the wrong direction; you'd think you'd learn from your past
> > > experience but here you are again w/ haste and rash summary.
> > > 4. This vote has been awkward. Josh's note is considered and careful.
> > You'd
> > > think it could hang out there a while to see if draws a response rather
> > > than rush to close.
> > >
> > > I thought I was reviewing a patch that was against master, not some
> > version
> > > of master from eons ago. Thats a problem. When was the last rebase?
> > >
> > > St.Ack
> > >
> > >
> > >
> > >
> > >
> > > > Thanks
> > > >
> > > > On Wed, Mar 15, 2017 at 4:22 PM, Josh Elser <el...@apache.org>
> wrote:
> > > >
> > > > > Spent the day playing around with this on 6 nodes.
> > > > >
> > > > > I've found some rough edges: some known (the docs blocker Vlad
> > pointed
> > > > > out) and some that I think are unknown (tooling is rough --
> partially
> > > > from
> > > > > wrong help messages and, I think, changes in design like
> > > Master-submitted
> > > > > MR jobs).
> > > > >
> > > > > But, Stack's assessment (and Andrew's reminder) that further
> tweaking
> > > > > would just throw us back into another review cycle is a real
> concern.
> > > > It's
> > > > > unfortunate that this feature has lingered so long aside of master
> to
> > > get
> > > > > to this point, but I don't see any realistic resolution to this
> > problem
> > > > > than a merge. In the future, this is something we'll have to try
> > harder
> > > > to
> > > > > avoid letting happen (looking in the mirror with quota work...)
> > > > >
> > > > > Thankfully, I can help out with development/review on the
> outstanding
> > > > > blockers (notably, the two I pruned from Vlad's original of five --
> > the
> > > > > other three still seem to be improvements). In addition to these
> > > > blockers,
> > > > > I believe the documentation *must* be updated before a release to
> > note
> > > > that
> > > > > this feature is still growing -- it does not feel like a quality
> > > feature
> > > > > that I've come to expect from this community. This isn't a knock on
> > > Vlad
> > > > > and company; this is a hard problem and one that I could not have
> > done
> > > > > better given time constraints, but it is also one that users will
> > > demand
> > > > > simplicity and the utmost correctness around. To this end, I will
> > also
> > > > try
> > > > > to help out to smooth out these issues in the following 2.x
> release.
> > > > >
> > > > > So, this leaves me to say: +1 to merge with the caveat that the
> docs
> > > are
> > > > > updated to make sure that any known, user-pitfalls are clearly
> > > > documented.
> > > > > This vote also comes with as real of a promise that I can make to
> > help
> > > > > avoid any issues with this feature that would prevent a 2.0
> release.
> > > > >
> > > > > Thanks to all the giants whose shoulders I'm standing on to be able
> > to
> > > > > make this vote.
> > > > >
> > > > > Andrew Purtell wrote:
> > > > >
> > > > >> Great, and I changed my vote to -0 because Stack made a good
> > argument
> > > > that
> > > > >> making more changes would invalidate review up to this point, and
> I
> > > > trust
> > > > >> this will be resolved before release.
> > > > >>
> > > > >> On Tue, Mar 14, 2017 at 4:29 PM, Josh Elser<el...@apache.org>
> > > wrote:
> > > > >>
> > > > >> Sorry Andrew, let me clarify as that didn't come out right.
> > > > >>>
> > > > >>> I didn't mean that isn't a conversation worth having _now_, just
> > > that I
> > > > >>> was intentionally avoiding it in my previous email because I
> didn't
> > > > >>> understand the scope of those issues that Vlad had identified. I
> > > wanted
> > > > >>> to
> > > > >>> better understand what they were really meant for a user before
> > > coming
> > > > to
> > > > >>> my own decision about whether or not I think they are blockers.
> > > > >>>
> > > > >>> That aside, I would agree with you that HBASE-15227 sounds like a
> > > real
> > > > >>> blocker. Forcing a new full backup for every table sounds really
> > bad
> > > --
> > > > >>> that's not the kind of experience we'd want a user to have.
> > > > >>>
> > > > >>> Andrew Purtell wrote:
> > > > >>>
> > > > >>> I'm going to intentional avoid addressing the discussion of
> > shipping
> > > > >>>> partial features (related, but not relevant at the moment).
> > > > >>>>
> > > > >>>> Then we are not having the same conversation, because it is
> > > precisely
> > > > >>>> because this is a vote for this feature to go into 2.0, which is
> > > > already
> > > > >>>> overdue, so should be released yesterday, that I took mention of
> > > > >>>> "blocker"
> > > > >>>> at face value. At least one of them seems to certainly approach
> > this
> > > > >>>> definition. It will be not user friendly, to say the least, to
> use
> > > > this
> > > > >>>> in
> > > > >>>> a large scale deployment with HBASE-15227 unfinished.
> HBASE-15227
> > > > >>>> currently
> > > > >>>> has a severity of BLOCKER. Despite what is going on in our
> > politics,
> > > > >>>> words
> > > > >>>> matter and we do not get to redefine them for convenience.
> > > > >>>>
> > > > >>>> Once this work is merged in, how is HBASE-15227 not a blocker
> for
> > > 2.0?
> > > > >>>> Because Vlad offered to reduce its severity to make me feel
> > better?
> > > > >>>> Currently the description on the issue is "System must be
> tolerant
> > > to
> > > > >>>> faults. Backup operations MUST be atomic (no partial completion
> > > state
> > > > in
> > > > >>>> system table)" Sounds like a blocker to me, indeed. It is an
> > honest
> > > > >>>> assessment and I don't think anyone is doing the community a
> favor
> > > by
> > > > >>>> trying to walk that back.
> > > > >>>>
> > > > >>>>
> > > > >>>> On Tue, Mar 14, 2017 at 1:57 PM, Josh Elser<el...@apache.org>
> > > > wrote:
> > > > >>>>
> > > > >>>> I took a moment to read through the "blockers" as originally
> > > > identified
> > > > >>>> by
> > > > >>>>
> > > > >>>>> Vlad, and (to echo Enis' take) I read the majority of them as
> > being
> > > > >>>>> blockers not for the next release, but for a "full-fledged
> > > feature".
> > > > >>>>> I'm
> > > > >>>>> going to intentional avoid addressing the discussion of
> shipping
> > > > >>>>> partial
> > > > >>>>> features (related, but not relevant at the moment).
> > > > >>>>>
> > > > >>>>> HBASE-15227 is actually the one that bothers me the most, with
> > > > >>>>> HBASE-17133
> > > > >>>>> coming in close behind. Vlad, is there any documentation you
> can
> > > > point
> > > > >>>>> me
> > > > >>>>> to about what the current issues are with the current
> > > implementation?
> > > > >>>>> For
> > > > >>>>> example, what happens now if the system has some kind of
> "partial
> > > > >>>>> completion state"?
> > > > >>>>>
> > > > >>>>> Documentation is one of those that is really hard to judge. We
> > want
> > > > to
> > > > >>>>> get
> > > > >>>>> this code out for people to use (and to free up our strained
> dev
> > > > >>>>> resources), but what good is some feature if the docs are
> > > > >>>>> missing/incomplete?
> > > > >>>>>
> > > > >>>>> I think I could stomach the docs being inaccurate (with a clear
> > > > >>>>> disclaimer
> > > > >>>>> that the chapter is incomplete -- that's a 5min task). But, I
> > > think I
> > > > >>>>> need
> > > > >>>>> an answer about how the feature handles our common dist-sys
> > > category
> > > > of
> > > > >>>>> problems 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
> > > > >>>>> problem as an (ignorant) user ;)
> > > > >>>>>
> > > > >>>>>
> > > > >>>>> Andrew Purtell wrote:
> > > > >>>>>
> > > > >>>>> I don't like that issues were identified as "blockers" but now
> > > there
> > > > is
> > > > >>>>>
> > > > >>>>>> an
> > > > >>>>>> attempt to walk that back.
> > > > >>>>>>
> > > > >>>>>> I don't like that development of this feature has lingered
> for a
> > > > long
> > > > >>>>>> time
> > > > >>>>>> in this unfinished state when this work could have been done
> by
> > > now,
> > > > >>>>>> now
> > > > >>>>>> 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 look at the current state and be nonplussed. This
> will
> > > be
> > > > >>>>>> yet
> > > > >>>>>> another half finished thing in 2.0 when this merge happens.
> > > Promises
> > > > >>>>>> to
> > > > >>>>>> finish the unfinished work are nice but not 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 2.0 release to
> > slip
> > > > >>>>>> further.
> > > > >>>>>>
> > > > >>>>>> Also, marking something experimental should be done on the
> > merits
> > > of
> > > > >>>>>> that
> > > > >>>>>> evaluation, not simply to justify dropping unfinished work
> into
> > a
> > > > >>>>>> release
> > > > >>>>>> branch.
> > > > >>>>>>
> > > > >>>>>> I will change my vote to -0.
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>> On Mon, Mar 13, 2017 at 4:05 PM, Enis Söztutar<
> enis@apache.org>
> > > > >>>>>> wrote:
> > > > >>>>>>
> > > > >>>>>> I think there is some misconception of using the term
> "blockers"
> > > for
> > > > >>>>>>
> > > > >>>>>> referring to those jiras. My understanding is that those three
> > > jiras
> > > > >>>>>>> are
> > > > >>>>>>> blockers for the backup functionality to be more mature and
> > more
> > > > >>>>>>> usable.
> > > > >>>>>>> But they are not release blockers. Let's say we merged the
> code
> > > in,
> > > > >>>>>>> and
> > > > >>>>>>> for
> > > > >>>>>>> some reason those did not get addressed in time. We can still
> > do
> > > > the
> > > > >>>>>>> 2.0
> > > > >>>>>>> release without having to wait for the commits. We can
> instead
> > > mark
> > > > >>>>>>> the
> > > > >>>>>>> "backup" feature as experimental with known issues and go on
> > with
> > > > the
> > > > >>>>>>> release. In that sense they are not real release 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
> > > > >>>>>>> luxury of having to wait another couple of months and doing
> yet
> > > > >>>>>>> another
> > > > >>>>>>> giant round of reviews because the code base is a moving
> > target.
> > > > >>>>>>>
> > > > >>>>>>> Enis
> > > > >>>>>>>
> > > > >>>>>>> On Mon, Mar 13, 2017 at 3:46 PM, Devaraj Das<
> > > ddas@hortonworks.com>
> > > > >>>>>>> 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 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 to make the list of remaining work more
> > complete
> > > > by
> > > > >>>>>>>
> > > > >>>>>>>> citing
> > > > >>>>>>>>
> > > > >>>>>>> that as pending work.
> > > > >>>>>>>
> > > > >>>>>>>> ________________________________________
> > > > >>>>>>>> From: Vladimir Rodionov<vl...@gmail.com>
> > > > >>>>>>>> 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 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 (including moving
> > > > backup/restore
> > > > >>>>>>>>>
> > > > >>>>>>>>>> out
> > > > >>>>>>>>>>
> > > > >>>>>>>>> of
> > > > >>>>>>>>
> > > > >>>>>>>> core to live in its own module).
> > > > >>>>>>>>
> > > > >>>>>>>>> For those who were not following our lengthy conversation
> on
> > a
> > > > >>>>>>>>> review
> > > > >>>>>>>>>
> > > > >>>>>>>>> board, separation of a backup code into a separate module
> has
> > > > been
> > > > >>>>>>>> done last year, but has been reverted back by request of a
> > > > reviewer.
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>> -Vladimir
> > > > >>>>>>>>
> > > > >>>>>>>> On Mon, Mar 13, 2017 at 2:23 PM, Stack<st...@duboce.net>
> > > > wrote:
> > > > >>>>>>>>
> > > > >>>>>>>> On Fri, Mar 10, 2017 at 9:09 PM, Stack<st...@duboce.net>
> > > > wrote:
> > > > >>>>>>>>
> > > > >>>>>>>> On Fri, Mar 10, 2017 at 6:01 PM, Ted Yu<yuzhihong@gmail.com
> >
> > > > >>>>>>>>> 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 burned a bunch of dev
> > > resource).
> > > > >>>>>>>>>
> > > > >>>>>>>>>> The patch as is is now in a state where it is too big for
> > our
> > > > >>>>>>>>>> infra;
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> rb
> > > > >>>>>>>>>>
> > > > >>>>>>>>> and JIRA are creaking under the size and # of iterations.
> > > > >>>>>>>>
> > > > >>>>>>>> Adding finish of new JIRAs to this merge implies a new round
> > of
> > > > >>>>>>>>>
> > > > >>>>>>>>>> review
> > > > >>>>>>>>>>
> > > > >>>>>>>>> and
> > > > >>>>>>>>
> > > > >>>>>>>> test of an already massive patch. Who is going to do this
> > work?
> > > > >>>>>>>>>
> > > > >>>>>>>>>> Going back to a new branch seems wrong route to take.
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> St.Ack
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> To be more explicit, this patch was developed on a branch
> > and
> > > > >>>>>>>>>> then a
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> bunch
> > > > >>>>>>>>>
> > > > >>>>>>>> of dev resources were burned getting it into a state where
> it
> > > > could
> > > > >>>>>>>> be
> > > > >>>>>>>>
> > > > >>>>>>>>> merged to master. Going back to a branch to bulk up the
> merge
> > > so
> > > > it
> > > > >>>>>>>>> includes more JIRAs than the many it already incorporates
> is
> > > the
> > > > >>>>>>>>> wrong
> > > > >>>>>>>>> direction for us to be headed in. It ignores the feedback
> > given
> > > > and
> > > > >>>>>>>>> the
> > > > >>>>>>>>> work done by Vladimir slimming down an already over-broad
> > > scope.
> > > > It
> > > > >>>>>>>>> is
> > > > >>>>>>>>>
> > > > >>>>>>>>> also
> > > > >>>>>>>>>
> > > > >>>>>>>> predicated on abundant review and testing resource being on
> > tap
> > > to
> > > > >>>>>>>>
> > > > >>>>>>>>> cycle
> > > > >>>>>>>>>
> > > > >>>>>>>> on
> > > > >>>>>>>>
> > > > >>>>>>>> a feature that is useful, but non-core.
> > > > >>>>>>>>
> > > > >>>>>>>>> The patch is ready for merge IMO. Geoffrey makes a nice
> list
> > of
> > > > >>>>>>>>> what
> > > > >>>>>>>>> is
> > > > >>>>>>>>> still to do though IIRC, the list is incomplete because a
> > bunch
> > > > of
> > > > >>>>>>>>> follow-ons came of the review cycle (including moving
> > > > >>>>>>>>> backup/restore
> > > > >>>>>>>>>
> > > > >>>>>>>>> out
> > > > >>>>>>>>>
> > > > >>>>>>>> of
> > > > >>>>>>>>
> > > > >>>>>>>> core to live in its own module).
> > > > >>>>>>>>
> > > > >>>>>>>>> The patch needs three votes to merge. I am not against
> merge
> > > but
> > > > I
> > > > >>>>>>>>> am
> > > > >>>>>>>>>
> > > > >>>>>>>>> not
> > > > >>>>>>>>>
> > > > >>>>>>>> voting for the patch because I do have any more time to
> spend
> > on
> > > > >>>>>>>> this
> > > > >>>>>>>>
> > > > >>>>>>>> non-core feature and feel that a vote will have me assume a
> > > > >>>>>>>>>
> > > > >>>>>>>>> responsibility
> > > > >>>>>>>>>
> > > > >>>>>>>> I will not shirk.
> > > > >>>>>>>>
> > > > >>>>>>>>> S
> > > > >>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>> FYI
> > > > >>>>>>>>>
> > > > >>>>>>>>>> On Fri, Mar 10, 2017 at 3:30 PM, Ted Yu<
> yuzhihong@gmail.com
> > >
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> 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 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,
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>> we
> > > > >>>>>>>>>>
> > > > >>>>>>>>> propose to community for merging into branch-2 (master
> > branch,
> > > if
> > > > >>>>>>>>
> > > > >>>>>>>>> branch-2
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>> doesn't materialize for whatever reason) again
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>> Cheers
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> On Fri, Mar 10, 2017 at 3:01 PM, Andrew Purtell<
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> apurtell@apache.org>
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>> wrote:
> > > > >>>>>>>>>> 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 the documentation issue is important but not
> > > actually
> > > > a
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> blocker.
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>> That may be a controversial opinion, but documentation
> can
> > > be
> > > > >>>>>>>>>>>> back-filled
> > > > >>>>>>>>>>>> worst case. So take HBASE-17133 off the list.
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> Remaining are effectively HBASE-14417, HBASE-14141, and
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> HBASE-15227.
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>> They
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>> all have patches attached to the respective JIRAs so
> > > completing
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>> this
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> work
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>> won't be onerous. Get these committed and I will lift my
> -1.
> > > The
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>> others
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> who
> > > > >>>>>>>>>>> voted +1 on this thread surely can help with that.
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>> Thanks.
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> On Fri, Mar 10, 2017 at 2:32 PM, Vladimir Rodionov<
> > > > >>>>>>>>>>>>> vladrodionov@gmail.com>
> > > > >>>>>>>>>>>>> wrote:
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> No problem I will downgrade Blockers to Majors if it
> > scares
> > > > >>>>>>>>>>>>> you,
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> Andrew
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>> [image: [image: 🙂]]
> > > > >>>>>>>>>
> > > > >>>>>>>>> Sent from my iPhone
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>>> On Mar 10, 2017, at 1:52 PM, Andrew Purtell<
> > > > >>>>>>>>>>>>>> apurtell@apache.org
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> 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
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> 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 prevent that release because these
> blockers
> > > will
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>> be
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>> there. I
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>> am
> > > > >>>>>>>>>
> > > > >>>>>>>>>> inclined to veto. Probably we should not propose branch
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> merges
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> into
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>> code
> > > > >>>>>>>>>
> > > > >>>>>>>>>> we
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>> are trying to get out the door with known blockers. Why
> > not
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> do
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> that
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>> work
> > > > >>>>>>>>>
> > > > >>>>>>>>>> first? It seems an obvious question. Perhaps I am missing
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>> something.
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> If we can branch for 2.0 now and then merge this, and
> > not
> > > > >>>>>>>>>>>>> into
> > > > >>>>>>>>>>>>> the
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>> 2.0
> > > > >>>>>>>>>
> > > > >>>>>>>>>> branch, I would vote +1 for branch merge even with known
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>> blockers
> > > > >>>>>>>>>>>>> pending.
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>> On Fri, Mar 10, 2017 at 1:42 PM, Vladimir Rodionov<
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> vladrodionov@gmail.com>
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> wrote:
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> 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<
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> apurtell@apache.org
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> wrote:
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> 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<
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> vladrodionov@gmail.com>
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> wrote:
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> 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
> > > reviews
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>> and
> > > > >>>>>>>>>>>>>>>> has
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> probably
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>> the most lengthy discussion thread on Apache JIRA
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> (HBASE-14123)
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> :)
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> The work has been split into 3 phases (HBASE-14030,
> > > 14123,
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>> 14414)
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> Two
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> first
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> are complete, third one is still in progress.
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> *** Summary of work HBASE-14123
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>> The new feature introduces new command-line
> > extensions
> > > > to
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>> the
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> hbase
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> command
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>> and, from the client side, is accessible through
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> command-line
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> only
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> Operations:
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>> * Create full backup on a list of tables or backup set
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> * Create incremental backup image for table list or
> > backup
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>> set
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> * Restore list of tables from a given backup image
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> * Show current backup progress
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>> * Delete backup image and all related images
> > > > >>>>>>>>>>>>>>>>>> * Show history of backups
> > > > >>>>>>>>>>>>>>>>>> * Backup set operations: create backup set,
> > add/remove
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>> table
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> to/from
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> backup
> > > > >>>>>>>>>
> > > > >>>>>>>>>> set, etc
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> In the current implementation, the feature is
> already
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>> usable,
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> meaning
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> that
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>> users can backup tables and restore them using provided
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> command-line
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> tools.
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> Both: full and incremental backups are supported.
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> This work is based on original work of IBM team
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>> (HBASE-7912).
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> The
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> full
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>> list
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> of JIRAs included in this mega patch can be found in
> > three
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> umbrella
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> JIRAs:
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> HBASE-14030 (Phase 1), HBASE-14123 (Phase 2) and
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> HBASE-14414
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> (Phase 3
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> -
> > > > >>>>>>>>>
> > > > >>>>>>>>>> all
> > > > >>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> resolved ones made it into the patch)
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> *** What are the remaining work items
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>> All remaining items can be found in Phase 3
> umbrella
> > > > JIRA:
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>> HBASE-14414.
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> They are split into 3 groups: BLOCKER, CRITICAL,
> > MAJOR
> > > > >>>>>>>>>>>>>>>> Only BLOCKERs and CRITICALs are guaranteed for HBase
> > 2.0
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> release.
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> ***** BLOCKER
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> * HBASE-14417 Incremental backup and bulk loading (
> > Patch
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> available)
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> * HBASE-14135 HBase Backup/Restore Phase 3: Merge
> > > backup
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> images
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> * HBASE-14141 HBase Backup/Restore Phase 3: Filter
> > WALs
> > > on
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> backup
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>> to
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> include only edits from backup tables (Patch
> available)
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> * HBASE-17133 Backup documentation
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> * HBASE-15227 Fault tolerance support
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>> ***** CRITICAL
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>> * HBASE-16465 Disable split/merges during backup
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>> We have umbrella JIRA (HBASE-14414) to track all
> the
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>> remaining
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> work
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> All the BLOCKER and CRITICAL JIRAs currently in open
> > > state
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>> will
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> be
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> implemented by 2.0 release time. Some MAJOR too, but
> it
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>> depends
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> on
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> resource
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>> availability
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> The former development branch (HBASE-7912) is obsolete
> > and
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>> will
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> be
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> closed/deleted after the merge.
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>> We want backup to be a GA feature in 2.0
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> We are going to support full backward compatibility
> for
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>> backup
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> tool in
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> 2.0
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>> and onwards.
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> **** Configuration
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>> Backup is disabled, by default. To enable it, the
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>> following
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> configuration
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> properties must be added to hbase-site.xml:
> > > > >>>>>>>>>
> > > > >>>>>>>>>> hbase.backup.enable=true
> > > > >>>>>>>>>>>>>>>>>> hbase.master.logcleaner.plugins=YOUR_PLUGINS,org.
> > > > >>>>>>>>>>>>>>>>>> apache.hadoop.hbase.backup.
> master.BackupLogCleaner
> > > > >>>>>>>>>>>>>>>>>> hbase.procedure.master.classes=YOUR_CLASSES,org.
> > > > >>>>>>>>>>>>>>>>>> apache.hadoop.hbase.backup.master.
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>> LogRollMasterProcedureManager
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> hbase.procedure.regionserver.
> > classes=YOUR_CLASSES,org.
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> apache.hadoop.hbase.backup.regionserver.
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>> LogRollRegionServerProcedureMa
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> nager
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> I would like to thank IBM team and Jerry He for
> > > original
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>> work,
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> Enis, Ted, Stack, Matteo, Jerry for time spent on
> > code
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> reviews
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>> Special thanks to Ted Yu for his co-development work.
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> References:
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-7912
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>> (original
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> IBM,
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> contains
> > > > >>>>>>>>>
> > > > >>>>>>>>>> design doc)
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-14030
> (Phase
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>> 1)
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-14123
> > > (Phase
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> 2)
> > > > >>>>>>>>>
> > > > >>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-14414 (Phase
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> 3)
> > > > >>>>>>>>>
> > > > >>>>>>>>>> Please vote +1/-1 by midnight Pacific Time (00:00
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> -0800 GMT) on March 11th on whether or not we
> should
> > > > >>>>>>>>>
> > > > >>>>>>>>>> merge
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> this
> > > > >>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> into
> > > > >>>>>>>>>
> > > > >>>>>>>>>> the
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> current master.
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> -Vladimir Rodionov
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>>> --
> > > > >>>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> Best regards,
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> - Andy
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> If you are given a choice, you believe you have
> acted
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>>> freely. -
> > > > >>>>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>>> Raymond
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> Teller (via Peter Watts)
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>> --
> > > > >>>>>>>>>>>>>>> Best regards,
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> - Andy
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> If you are given a choice, you believe you have acted
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>>> freely. -
> > > > >>>>>>>>>>>>>>>
> > > > >>>>>>>>>>>>>> Raymond
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>> Teller (via Peter Watts)
> > > > >>>>>>>>>
> > > > >>>>>>>>>> --
> > > > >>>>>>>>>>>>> Best regards,
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> - Andy
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> If you are given a choice, you believe you have acted
> > > > freely. -
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>> Raymond
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>> Teller (via Peter Watts)
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>
> > > > >>>>
> > > > >>
> > > > >>
> > > >
> > >
> >
>
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
Posted by Stack <st...@duboce.net>.
On Wed, Mar 15, 2017 at 11:38 PM, Vladimir Rodionov <vl...@gmail.com>
wrote:
> >> I thought I was reviewing a patch that was against master
>
> Yes, it was against master. We used to develop in HBASE-7912 branch, but it
> was abandoned 6-8 mo ago.
> This is why the only way to merge backup is to apply v61 directly to master
> branch.
>
>
If you are saying that v61 is against a master of 6-8 months ago, then I'd
think this VOTE is premature. Don't you have a mountain of rebasing to do
before you can put your patch up for a vote?
St.Ack
> -Vlad
>
>
> On Wed, Mar 15, 2017 at 9:17 PM, Stack <st...@duboce.net> wrote:
>
> > On Wed, Mar 15, 2017 at 5:51 PM, Ted Yu <yu...@gmail.com> wrote:
> >
> > > Thanks for the vote, Josh.
> > >
> > > So far there have been 3 +1's (Enis', mine and Josh's)
> > >
> > > Should we start another thread on the procedure of merging or use this
> > > thread ?
> > > Background:
> > > HBASE-7912 branch is way out of date.
> > > Latest rounds of mega patch were based on then-current master branch.
> > >
> > >
> > 1. Vlad is running this VOTE, not you.
> > 2. Don't you need 3 PMC votes to merge? I count 2.
> > 3. You almost derailed the merge with your earlier interjection rushing
> to
> > take us in the wrong direction; you'd think you'd learn from your past
> > experience but here you are again w/ haste and rash summary.
> > 4. This vote has been awkward. Josh's note is considered and careful.
> You'd
> > think it could hang out there a while to see if draws a response rather
> > than rush to close.
> >
> > I thought I was reviewing a patch that was against master, not some
> version
> > of master from eons ago. Thats a problem. When was the last rebase?
> >
> > St.Ack
> >
> >
> >
> >
> >
> > > Thanks
> > >
> > > On Wed, Mar 15, 2017 at 4:22 PM, Josh Elser <el...@apache.org> wrote:
> > >
> > > > Spent the day playing around with this on 6 nodes.
> > > >
> > > > I've found some rough edges: some known (the docs blocker Vlad
> pointed
> > > > out) and some that I think are unknown (tooling is rough -- partially
> > > from
> > > > wrong help messages and, I think, changes in design like
> > Master-submitted
> > > > MR jobs).
> > > >
> > > > But, Stack's assessment (and Andrew's reminder) that further tweaking
> > > > would just throw us back into another review cycle is a real concern.
> > > It's
> > > > unfortunate that this feature has lingered so long aside of master to
> > get
> > > > to this point, but I don't see any realistic resolution to this
> problem
> > > > than a merge. In the future, this is something we'll have to try
> harder
> > > to
> > > > avoid letting happen (looking in the mirror with quota work...)
> > > >
> > > > Thankfully, I can help out with development/review on the outstanding
> > > > blockers (notably, the two I pruned from Vlad's original of five --
> the
> > > > other three still seem to be improvements). In addition to these
> > > blockers,
> > > > I believe the documentation *must* be updated before a release to
> note
> > > that
> > > > this feature is still growing -- it does not feel like a quality
> > feature
> > > > that I've come to expect from this community. This isn't a knock on
> > Vlad
> > > > and company; this is a hard problem and one that I could not have
> done
> > > > better given time constraints, but it is also one that users will
> > demand
> > > > simplicity and the utmost correctness around. To this end, I will
> also
> > > try
> > > > to help out to smooth out these issues in the following 2.x release.
> > > >
> > > > So, this leaves me to say: +1 to merge with the caveat that the docs
> > are
> > > > updated to make sure that any known, user-pitfalls are clearly
> > > documented.
> > > > This vote also comes with as real of a promise that I can make to
> help
> > > > avoid any issues with this feature that would prevent a 2.0 release.
> > > >
> > > > Thanks to all the giants whose shoulders I'm standing on to be able
> to
> > > > make this vote.
> > > >
> > > > Andrew Purtell wrote:
> > > >
> > > >> Great, and I changed my vote to -0 because Stack made a good
> argument
> > > that
> > > >> making more changes would invalidate review up to this point, and I
> > > trust
> > > >> this will be resolved before release.
> > > >>
> > > >> On Tue, Mar 14, 2017 at 4:29 PM, Josh Elser<el...@apache.org>
> > wrote:
> > > >>
> > > >> Sorry Andrew, let me clarify as that didn't come out right.
> > > >>>
> > > >>> I didn't mean that isn't a conversation worth having _now_, just
> > that I
> > > >>> was intentionally avoiding it in my previous email because I didn't
> > > >>> understand the scope of those issues that Vlad had identified. I
> > wanted
> > > >>> to
> > > >>> better understand what they were really meant for a user before
> > coming
> > > to
> > > >>> my own decision about whether or not I think they are blockers.
> > > >>>
> > > >>> That aside, I would agree with you that HBASE-15227 sounds like a
> > real
> > > >>> blocker. Forcing a new full backup for every table sounds really
> bad
> > --
> > > >>> that's not the kind of experience we'd want a user to have.
> > > >>>
> > > >>> Andrew Purtell wrote:
> > > >>>
> > > >>> I'm going to intentional avoid addressing the discussion of
> shipping
> > > >>>> partial features (related, but not relevant at the moment).
> > > >>>>
> > > >>>> Then we are not having the same conversation, because it is
> > precisely
> > > >>>> because this is a vote for this feature to go into 2.0, which is
> > > already
> > > >>>> overdue, so should be released yesterday, that I took mention of
> > > >>>> "blocker"
> > > >>>> at face value. At least one of them seems to certainly approach
> this
> > > >>>> definition. It will be not user friendly, to say the least, to use
> > > this
> > > >>>> in
> > > >>>> a large scale deployment with HBASE-15227 unfinished. HBASE-15227
> > > >>>> currently
> > > >>>> has a severity of BLOCKER. Despite what is going on in our
> politics,
> > > >>>> words
> > > >>>> matter and we do not get to redefine them for convenience.
> > > >>>>
> > > >>>> Once this work is merged in, how is HBASE-15227 not a blocker for
> > 2.0?
> > > >>>> Because Vlad offered to reduce its severity to make me feel
> better?
> > > >>>> Currently the description on the issue is "System must be tolerant
> > to
> > > >>>> faults. Backup operations MUST be atomic (no partial completion
> > state
> > > in
> > > >>>> system table)" Sounds like a blocker to me, indeed. It is an
> honest
> > > >>>> assessment and I don't think anyone is doing the community a favor
> > by
> > > >>>> trying to walk that back.
> > > >>>>
> > > >>>>
> > > >>>> On Tue, Mar 14, 2017 at 1:57 PM, Josh Elser<el...@apache.org>
> > > wrote:
> > > >>>>
> > > >>>> I took a moment to read through the "blockers" as originally
> > > identified
> > > >>>> by
> > > >>>>
> > > >>>>> Vlad, and (to echo Enis' take) I read the majority of them as
> being
> > > >>>>> blockers not for the next release, but for a "full-fledged
> > feature".
> > > >>>>> I'm
> > > >>>>> going to intentional avoid addressing the discussion of shipping
> > > >>>>> partial
> > > >>>>> features (related, but not relevant at the moment).
> > > >>>>>
> > > >>>>> HBASE-15227 is actually the one that bothers me the most, with
> > > >>>>> HBASE-17133
> > > >>>>> coming in close behind. Vlad, is there any documentation you can
> > > point
> > > >>>>> me
> > > >>>>> to about what the current issues are with the current
> > implementation?
> > > >>>>> For
> > > >>>>> example, what happens now if the system has some kind of "partial
> > > >>>>> completion state"?
> > > >>>>>
> > > >>>>> Documentation is one of those that is really hard to judge. We
> want
> > > to
> > > >>>>> get
> > > >>>>> this code out for people to use (and to free up our strained dev
> > > >>>>> resources), but what good is some feature if the docs are
> > > >>>>> missing/incomplete?
> > > >>>>>
> > > >>>>> I think I could stomach the docs being inaccurate (with a clear
> > > >>>>> disclaimer
> > > >>>>> that the chapter is incomplete -- that's a 5min task). But, I
> > think I
> > > >>>>> need
> > > >>>>> an answer about how the feature handles our common dist-sys
> > category
> > > of
> > > >>>>> problems 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
> > > >>>>> problem as an (ignorant) user ;)
> > > >>>>>
> > > >>>>>
> > > >>>>> Andrew Purtell wrote:
> > > >>>>>
> > > >>>>> I don't like that issues were identified as "blockers" but now
> > there
> > > is
> > > >>>>>
> > > >>>>>> an
> > > >>>>>> attempt to walk that back.
> > > >>>>>>
> > > >>>>>> I don't like that development of this feature has lingered for a
> > > long
> > > >>>>>> time
> > > >>>>>> in this unfinished state when this work could have been done by
> > now,
> > > >>>>>> now
> > > >>>>>> 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 look at the current state and be nonplussed. This will
> > be
> > > >>>>>> yet
> > > >>>>>> another half finished thing in 2.0 when this merge happens.
> > Promises
> > > >>>>>> to
> > > >>>>>> finish the unfinished work are nice but not 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 2.0 release to
> slip
> > > >>>>>> further.
> > > >>>>>>
> > > >>>>>> Also, marking something experimental should be done on the
> merits
> > of
> > > >>>>>> that
> > > >>>>>> evaluation, not simply to justify dropping unfinished work into
> a
> > > >>>>>> release
> > > >>>>>> branch.
> > > >>>>>>
> > > >>>>>> I will change my vote to -0.
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> On Mon, Mar 13, 2017 at 4:05 PM, Enis Söztutar<en...@apache.org>
> > > >>>>>> wrote:
> > > >>>>>>
> > > >>>>>> I think there is some misconception of using the term "blockers"
> > for
> > > >>>>>>
> > > >>>>>> referring to those jiras. My understanding is that those three
> > jiras
> > > >>>>>>> are
> > > >>>>>>> blockers for the backup functionality to be more mature and
> more
> > > >>>>>>> usable.
> > > >>>>>>> But they are not release blockers. Let's say we merged the code
> > in,
> > > >>>>>>> and
> > > >>>>>>> for
> > > >>>>>>> some reason those did not get addressed in time. We can still
> do
> > > the
> > > >>>>>>> 2.0
> > > >>>>>>> release without having to wait for the commits. We can instead
> > mark
> > > >>>>>>> the
> > > >>>>>>> "backup" feature as experimental with known issues and go on
> with
> > > the
> > > >>>>>>> release. In that sense they are not real release 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
> > > >>>>>>> luxury of having to wait another couple of months and doing yet
> > > >>>>>>> another
> > > >>>>>>> giant round of reviews because the code base is a moving
> target.
> > > >>>>>>>
> > > >>>>>>> Enis
> > > >>>>>>>
> > > >>>>>>> On Mon, Mar 13, 2017 at 3:46 PM, Devaraj Das<
> > ddas@hortonworks.com>
> > > >>>>>>> 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 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 to make the list of remaining work more
> complete
> > > by
> > > >>>>>>>
> > > >>>>>>>> citing
> > > >>>>>>>>
> > > >>>>>>> that as pending work.
> > > >>>>>>>
> > > >>>>>>>> ________________________________________
> > > >>>>>>>> From: Vladimir Rodionov<vl...@gmail.com>
> > > >>>>>>>> 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 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 (including moving
> > > backup/restore
> > > >>>>>>>>>
> > > >>>>>>>>>> out
> > > >>>>>>>>>>
> > > >>>>>>>>> of
> > > >>>>>>>>
> > > >>>>>>>> core to live in its own module).
> > > >>>>>>>>
> > > >>>>>>>>> For those who were not following our lengthy conversation on
> a
> > > >>>>>>>>> review
> > > >>>>>>>>>
> > > >>>>>>>>> board, separation of a backup code into a separate module has
> > > been
> > > >>>>>>>> done last year, but has been reverted back by request of a
> > > reviewer.
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> -Vladimir
> > > >>>>>>>>
> > > >>>>>>>> On Mon, Mar 13, 2017 at 2:23 PM, Stack<st...@duboce.net>
> > > wrote:
> > > >>>>>>>>
> > > >>>>>>>> On Fri, Mar 10, 2017 at 9:09 PM, Stack<st...@duboce.net>
> > > wrote:
> > > >>>>>>>>
> > > >>>>>>>> On Fri, Mar 10, 2017 at 6:01 PM, Ted Yu<yu...@gmail.com>
> > > >>>>>>>>> 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 burned a bunch of dev
> > resource).
> > > >>>>>>>>>
> > > >>>>>>>>>> The patch as is is now in a state where it is too big for
> our
> > > >>>>>>>>>> infra;
> > > >>>>>>>>>>
> > > >>>>>>>>>> rb
> > > >>>>>>>>>>
> > > >>>>>>>>> and JIRA are creaking under the size and # of iterations.
> > > >>>>>>>>
> > > >>>>>>>> Adding finish of new JIRAs to this merge implies a new round
> of
> > > >>>>>>>>>
> > > >>>>>>>>>> review
> > > >>>>>>>>>>
> > > >>>>>>>>> and
> > > >>>>>>>>
> > > >>>>>>>> test of an already massive patch. Who is going to do this
> work?
> > > >>>>>>>>>
> > > >>>>>>>>>> Going back to a new branch seems wrong route to take.
> > > >>>>>>>>>>
> > > >>>>>>>>>> St.Ack
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>> To be more explicit, this patch was developed on a branch
> and
> > > >>>>>>>>>> then a
> > > >>>>>>>>>>
> > > >>>>>>>>>> bunch
> > > >>>>>>>>>
> > > >>>>>>>> of dev resources were burned getting it into a state where it
> > > could
> > > >>>>>>>> be
> > > >>>>>>>>
> > > >>>>>>>>> merged to master. Going back to a branch to bulk up the merge
> > so
> > > it
> > > >>>>>>>>> includes more JIRAs than the many it already incorporates is
> > the
> > > >>>>>>>>> wrong
> > > >>>>>>>>> direction for us to be headed in. It ignores the feedback
> given
> > > and
> > > >>>>>>>>> the
> > > >>>>>>>>> work done by Vladimir slimming down an already over-broad
> > scope.
> > > It
> > > >>>>>>>>> is
> > > >>>>>>>>>
> > > >>>>>>>>> also
> > > >>>>>>>>>
> > > >>>>>>>> predicated on abundant review and testing resource being on
> tap
> > to
> > > >>>>>>>>
> > > >>>>>>>>> cycle
> > > >>>>>>>>>
> > > >>>>>>>> on
> > > >>>>>>>>
> > > >>>>>>>> a feature that is useful, but non-core.
> > > >>>>>>>>
> > > >>>>>>>>> The patch is ready for merge IMO. Geoffrey makes a nice list
> of
> > > >>>>>>>>> what
> > > >>>>>>>>> is
> > > >>>>>>>>> still to do though IIRC, the list is incomplete because a
> bunch
> > > of
> > > >>>>>>>>> follow-ons came of the review cycle (including moving
> > > >>>>>>>>> backup/restore
> > > >>>>>>>>>
> > > >>>>>>>>> out
> > > >>>>>>>>>
> > > >>>>>>>> of
> > > >>>>>>>>
> > > >>>>>>>> core to live in its own module).
> > > >>>>>>>>
> > > >>>>>>>>> The patch needs three votes to merge. I am not against merge
> > but
> > > I
> > > >>>>>>>>> am
> > > >>>>>>>>>
> > > >>>>>>>>> not
> > > >>>>>>>>>
> > > >>>>>>>> voting for the patch because I do have any more time to spend
> on
> > > >>>>>>>> this
> > > >>>>>>>>
> > > >>>>>>>> non-core feature and feel that a vote will have me assume a
> > > >>>>>>>>>
> > > >>>>>>>>> responsibility
> > > >>>>>>>>>
> > > >>>>>>>> I will not shirk.
> > > >>>>>>>>
> > > >>>>>>>>> S
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> FYI
> > > >>>>>>>>>
> > > >>>>>>>>>> On Fri, Mar 10, 2017 at 3:30 PM, Ted Yu<yuzhihong@gmail.com
> >
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> 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 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,
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>> we
> > > >>>>>>>>>>
> > > >>>>>>>>> propose to community for merging into branch-2 (master
> branch,
> > if
> > > >>>>>>>>
> > > >>>>>>>>> branch-2
> > > >>>>>>>>>>
> > > >>>>>>>>>>> doesn't materialize for whatever reason) again
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>> Cheers
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> On Fri, Mar 10, 2017 at 3:01 PM, Andrew Purtell<
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> apurtell@apache.org>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>> wrote:
> > > >>>>>>>>>> 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 the documentation issue is important but not
> > actually
> > > a
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> blocker.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>> That may be a controversial opinion, but documentation can
> > be
> > > >>>>>>>>>>>> back-filled
> > > >>>>>>>>>>>> worst case. So take HBASE-17133 off the list.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Remaining are effectively HBASE-14417, HBASE-14141, and
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> HBASE-15227.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>> They
> > > >>>>>>>>>>>
> > > >>>>>>>>>> all have patches attached to the respective JIRAs so
> > completing
> > > >>>>>>>>>>
> > > >>>>>>>>>>> this
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> work
> > > >>>>>>>>>>>
> > > >>>>>>>>>> won't be onerous. Get these committed and I will lift my -1.
> > The
> > > >>>>>>>>>>
> > > >>>>>>>>>>> others
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> who
> > > >>>>>>>>>>> voted +1 on this thread surely can help with that.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>> Thanks.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> On Fri, Mar 10, 2017 at 2:32 PM, Vladimir Rodionov<
> > > >>>>>>>>>>>>> vladrodionov@gmail.com>
> > > >>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> No problem I will downgrade Blockers to Majors if it
> scares
> > > >>>>>>>>>>>>> you,
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Andrew
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>> [image: [image: 🙂]]
> > > >>>>>>>>>
> > > >>>>>>>>> Sent from my iPhone
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>> On Mar 10, 2017, at 1:52 PM, Andrew Purtell<
> > > >>>>>>>>>>>>>> apurtell@apache.org
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> 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
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> 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 prevent that release because these blockers
> > will
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>> be
> > > >>>>>>>>>>
> > > >>>>>>>>>>> there. I
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>> am
> > > >>>>>>>>>
> > > >>>>>>>>>> inclined to veto. Probably we should not propose branch
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> merges
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> into
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>> code
> > > >>>>>>>>>
> > > >>>>>>>>>> we
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>> are trying to get out the door with known blockers. Why
> not
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> do
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> that
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>> work
> > > >>>>>>>>>
> > > >>>>>>>>>> first? It seems an obvious question. Perhaps I am missing
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>> something.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> If we can branch for 2.0 now and then merge this, and
> not
> > > >>>>>>>>>>>>> into
> > > >>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>> 2.0
> > > >>>>>>>>>
> > > >>>>>>>>>> branch, I would vote +1 for branch merge even with known
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>> blockers
> > > >>>>>>>>>>>>> pending.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>> On Fri, Mar 10, 2017 at 1:42 PM, Vladimir Rodionov<
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> vladrodionov@gmail.com>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> 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<
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> apurtell@apache.org
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>> 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<
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> vladrodionov@gmail.com>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> 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
> > reviews
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>> and
> > > >>>>>>>>>>>>>>>> has
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> probably
> > > >>>>>>>>>>
> > > >>>>>>>>>>> the most lengthy discussion thread on Apache JIRA
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> (HBASE-14123)
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> :)
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> The work has been split into 3 phases (HBASE-14030,
> > 14123,
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>> 14414)
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> Two
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> first
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> are complete, third one is still in progress.
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> *** Summary of work HBASE-14123
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> The new feature introduces new command-line
> extensions
> > > to
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> hbase
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> command
> > > >>>>>>>>>>
> > > >>>>>>>>>>> and, from the client side, is accessible through
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> command-line
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> only
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Operations:
> > > >>>>>>>>>>
> > > >>>>>>>>>>> * Create full backup on a list of tables or backup set
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> * Create incremental backup image for table list or
> backup
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> set
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> * Restore list of tables from a given backup image
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> * Show current backup progress
> > > >>>>>>>>>>
> > > >>>>>>>>>>> * Delete backup image and all related images
> > > >>>>>>>>>>>>>>>>>> * Show history of backups
> > > >>>>>>>>>>>>>>>>>> * Backup set operations: create backup set,
> add/remove
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> table
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> to/from
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> backup
> > > >>>>>>>>>
> > > >>>>>>>>>> set, etc
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> In the current implementation, the feature is already
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> usable,
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> meaning
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> that
> > > >>>>>>>>>>
> > > >>>>>>>>>>> users can backup tables and restore them using provided
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> command-line
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> tools.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Both: full and incremental backups are supported.
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> This work is based on original work of IBM team
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> (HBASE-7912).
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> The
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> full
> > > >>>>>>>>>>
> > > >>>>>>>>>>> list
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> of JIRAs included in this mega patch can be found in
> three
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> umbrella
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> JIRAs:
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> HBASE-14030 (Phase 1), HBASE-14123 (Phase 2) and
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> HBASE-14414
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> (Phase 3
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> -
> > > >>>>>>>>>
> > > >>>>>>>>>> all
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> resolved ones made it into the patch)
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> *** What are the remaining work items
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> All remaining items can be found in Phase 3 umbrella
> > > JIRA:
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> HBASE-14414.
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> They are split into 3 groups: BLOCKER, CRITICAL,
> MAJOR
> > > >>>>>>>>>>>>>>>> Only BLOCKERs and CRITICALs are guaranteed for HBase
> 2.0
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> release.
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> ***** BLOCKER
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> * HBASE-14417 Incremental backup and bulk loading (
> Patch
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> available)
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> * HBASE-14135 HBase Backup/Restore Phase 3: Merge
> > backup
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> images
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> * HBASE-14141 HBase Backup/Restore Phase 3: Filter
> WALs
> > on
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> backup
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>> to
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> include only edits from backup tables (Patch available)
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> * HBASE-17133 Backup documentation
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> * HBASE-15227 Fault tolerance support
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> ***** CRITICAL
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> * HBASE-16465 Disable split/merges during backup
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> We have umbrella JIRA (HBASE-14414) to track all the
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> remaining
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> work
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> All the BLOCKER and CRITICAL JIRAs currently in open
> > state
> > > >>>>>>>>>>
> > > >>>>>>>>>>> will
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> be
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> implemented by 2.0 release time. Some MAJOR too, but it
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>> depends
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> on
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> resource
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>> availability
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> The former development branch (HBASE-7912) is obsolete
> and
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> will
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> be
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> closed/deleted after the merge.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>> We want backup to be a GA feature in 2.0
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> We are going to support full backward compatibility for
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> backup
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> tool in
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> 2.0
> > > >>>>>>>>>>
> > > >>>>>>>>>>> and onwards.
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> **** Configuration
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> Backup is disabled, by default. To enable it, the
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> following
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> configuration
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> properties must be added to hbase-site.xml:
> > > >>>>>>>>>
> > > >>>>>>>>>> hbase.backup.enable=true
> > > >>>>>>>>>>>>>>>>>> hbase.master.logcleaner.plugins=YOUR_PLUGINS,org.
> > > >>>>>>>>>>>>>>>>>> apache.hadoop.hbase.backup.master.BackupLogCleaner
> > > >>>>>>>>>>>>>>>>>> hbase.procedure.master.classes=YOUR_CLASSES,org.
> > > >>>>>>>>>>>>>>>>>> apache.hadoop.hbase.backup.master.
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> LogRollMasterProcedureManager
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> hbase.procedure.regionserver.
> classes=YOUR_CLASSES,org.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> apache.hadoop.hbase.backup.regionserver.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>> LogRollRegionServerProcedureMa
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> nager
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> I would like to thank IBM team and Jerry He for
> > original
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> work,
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Enis, Ted, Stack, Matteo, Jerry for time spent on
> code
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> reviews
> > > >>>>>>>>>>
> > > >>>>>>>>>>> Special thanks to Ted Yu for his co-development work.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> References:
> > > >>>>>>>>>>
> > > >>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-7912
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> (original
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> IBM,
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> contains
> > > >>>>>>>>>
> > > >>>>>>>>>> design doc)
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-14030 (Phase
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> 1)
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-14123
> > (Phase
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> 2)
> > > >>>>>>>>>
> > > >>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-14414 (Phase
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> 3)
> > > >>>>>>>>>
> > > >>>>>>>>>> Please vote +1/-1 by midnight Pacific Time (00:00
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> -0800 GMT) on March 11th on whether or not we should
> > > >>>>>>>>>
> > > >>>>>>>>>> merge
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> this
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> into
> > > >>>>>>>>>
> > > >>>>>>>>>> the
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> current master.
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> -Vladimir Rodionov
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> --
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Best regards,
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> - Andy
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> If you are given a choice, you believe you have acted
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> freely. -
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Raymond
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> Teller (via Peter Watts)
> > > >>>>>>>>>>
> > > >>>>>>>>>>> --
> > > >>>>>>>>>>>>>>> Best regards,
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> - Andy
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> If you are given a choice, you believe you have acted
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> freely. -
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> Raymond
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>> Teller (via Peter Watts)
> > > >>>>>>>>>
> > > >>>>>>>>>> --
> > > >>>>>>>>>>>>> Best regards,
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> - Andy
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> If you are given a choice, you believe you have acted
> > > freely. -
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Raymond
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>> Teller (via Peter Watts)
> > > >>>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>
> > > >>>>
> > > >>
> > > >>
> > >
> >
>
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
Posted by Vladimir Rodionov <vl...@gmail.com>.
>> I thought I was reviewing a patch that was against master
Yes, it was against master. We used to develop in HBASE-7912 branch, but it
was abandoned 6-8 mo ago.
This is why the only way to merge backup is to apply v61 directly to master
branch.
-Vlad
On Wed, Mar 15, 2017 at 9:17 PM, Stack <st...@duboce.net> wrote:
> On Wed, Mar 15, 2017 at 5:51 PM, Ted Yu <yu...@gmail.com> wrote:
>
> > Thanks for the vote, Josh.
> >
> > So far there have been 3 +1's (Enis', mine and Josh's)
> >
> > Should we start another thread on the procedure of merging or use this
> > thread ?
> > Background:
> > HBASE-7912 branch is way out of date.
> > Latest rounds of mega patch were based on then-current master branch.
> >
> >
> 1. Vlad is running this VOTE, not you.
> 2. Don't you need 3 PMC votes to merge? I count 2.
> 3. You almost derailed the merge with your earlier interjection rushing to
> take us in the wrong direction; you'd think you'd learn from your past
> experience but here you are again w/ haste and rash summary.
> 4. This vote has been awkward. Josh's note is considered and careful. You'd
> think it could hang out there a while to see if draws a response rather
> than rush to close.
>
> I thought I was reviewing a patch that was against master, not some version
> of master from eons ago. Thats a problem. When was the last rebase?
>
> St.Ack
>
>
>
>
>
> > Thanks
> >
> > On Wed, Mar 15, 2017 at 4:22 PM, Josh Elser <el...@apache.org> wrote:
> >
> > > Spent the day playing around with this on 6 nodes.
> > >
> > > I've found some rough edges: some known (the docs blocker Vlad pointed
> > > out) and some that I think are unknown (tooling is rough -- partially
> > from
> > > wrong help messages and, I think, changes in design like
> Master-submitted
> > > MR jobs).
> > >
> > > But, Stack's assessment (and Andrew's reminder) that further tweaking
> > > would just throw us back into another review cycle is a real concern.
> > It's
> > > unfortunate that this feature has lingered so long aside of master to
> get
> > > to this point, but I don't see any realistic resolution to this problem
> > > than a merge. In the future, this is something we'll have to try harder
> > to
> > > avoid letting happen (looking in the mirror with quota work...)
> > >
> > > Thankfully, I can help out with development/review on the outstanding
> > > blockers (notably, the two I pruned from Vlad's original of five -- the
> > > other three still seem to be improvements). In addition to these
> > blockers,
> > > I believe the documentation *must* be updated before a release to note
> > that
> > > this feature is still growing -- it does not feel like a quality
> feature
> > > that I've come to expect from this community. This isn't a knock on
> Vlad
> > > and company; this is a hard problem and one that I could not have done
> > > better given time constraints, but it is also one that users will
> demand
> > > simplicity and the utmost correctness around. To this end, I will also
> > try
> > > to help out to smooth out these issues in the following 2.x release.
> > >
> > > So, this leaves me to say: +1 to merge with the caveat that the docs
> are
> > > updated to make sure that any known, user-pitfalls are clearly
> > documented.
> > > This vote also comes with as real of a promise that I can make to help
> > > avoid any issues with this feature that would prevent a 2.0 release.
> > >
> > > Thanks to all the giants whose shoulders I'm standing on to be able to
> > > make this vote.
> > >
> > > Andrew Purtell wrote:
> > >
> > >> Great, and I changed my vote to -0 because Stack made a good argument
> > that
> > >> making more changes would invalidate review up to this point, and I
> > trust
> > >> this will be resolved before release.
> > >>
> > >> On Tue, Mar 14, 2017 at 4:29 PM, Josh Elser<el...@apache.org>
> wrote:
> > >>
> > >> Sorry Andrew, let me clarify as that didn't come out right.
> > >>>
> > >>> I didn't mean that isn't a conversation worth having _now_, just
> that I
> > >>> was intentionally avoiding it in my previous email because I didn't
> > >>> understand the scope of those issues that Vlad had identified. I
> wanted
> > >>> to
> > >>> better understand what they were really meant for a user before
> coming
> > to
> > >>> my own decision about whether or not I think they are blockers.
> > >>>
> > >>> That aside, I would agree with you that HBASE-15227 sounds like a
> real
> > >>> blocker. Forcing a new full backup for every table sounds really bad
> --
> > >>> that's not the kind of experience we'd want a user to have.
> > >>>
> > >>> Andrew Purtell wrote:
> > >>>
> > >>> I'm going to intentional avoid addressing the discussion of shipping
> > >>>> partial features (related, but not relevant at the moment).
> > >>>>
> > >>>> Then we are not having the same conversation, because it is
> precisely
> > >>>> because this is a vote for this feature to go into 2.0, which is
> > already
> > >>>> overdue, so should be released yesterday, that I took mention of
> > >>>> "blocker"
> > >>>> at face value. At least one of them seems to certainly approach this
> > >>>> definition. It will be not user friendly, to say the least, to use
> > this
> > >>>> in
> > >>>> a large scale deployment with HBASE-15227 unfinished. HBASE-15227
> > >>>> currently
> > >>>> has a severity of BLOCKER. Despite what is going on in our politics,
> > >>>> words
> > >>>> matter and we do not get to redefine them for convenience.
> > >>>>
> > >>>> Once this work is merged in, how is HBASE-15227 not a blocker for
> 2.0?
> > >>>> Because Vlad offered to reduce its severity to make me feel better?
> > >>>> Currently the description on the issue is "System must be tolerant
> to
> > >>>> faults. Backup operations MUST be atomic (no partial completion
> state
> > in
> > >>>> system table)" Sounds like a blocker to me, indeed. It is an honest
> > >>>> assessment and I don't think anyone is doing the community a favor
> by
> > >>>> trying to walk that back.
> > >>>>
> > >>>>
> > >>>> On Tue, Mar 14, 2017 at 1:57 PM, Josh Elser<el...@apache.org>
> > wrote:
> > >>>>
> > >>>> I took a moment to read through the "blockers" as originally
> > identified
> > >>>> by
> > >>>>
> > >>>>> Vlad, and (to echo Enis' take) I read the majority of them as being
> > >>>>> blockers not for the next release, but for a "full-fledged
> feature".
> > >>>>> I'm
> > >>>>> going to intentional avoid addressing the discussion of shipping
> > >>>>> partial
> > >>>>> features (related, but not relevant at the moment).
> > >>>>>
> > >>>>> HBASE-15227 is actually the one that bothers me the most, with
> > >>>>> HBASE-17133
> > >>>>> coming in close behind. Vlad, is there any documentation you can
> > point
> > >>>>> me
> > >>>>> to about what the current issues are with the current
> implementation?
> > >>>>> For
> > >>>>> example, what happens now if the system has some kind of "partial
> > >>>>> completion state"?
> > >>>>>
> > >>>>> Documentation is one of those that is really hard to judge. We want
> > to
> > >>>>> get
> > >>>>> this code out for people to use (and to free up our strained dev
> > >>>>> resources), but what good is some feature if the docs are
> > >>>>> missing/incomplete?
> > >>>>>
> > >>>>> I think I could stomach the docs being inaccurate (with a clear
> > >>>>> disclaimer
> > >>>>> that the chapter is incomplete -- that's a 5min task). But, I
> think I
> > >>>>> need
> > >>>>> an answer about how the feature handles our common dist-sys
> category
> > of
> > >>>>> problems 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
> > >>>>> problem as an (ignorant) user ;)
> > >>>>>
> > >>>>>
> > >>>>> Andrew Purtell wrote:
> > >>>>>
> > >>>>> I don't like that issues were identified as "blockers" but now
> there
> > is
> > >>>>>
> > >>>>>> an
> > >>>>>> attempt to walk that back.
> > >>>>>>
> > >>>>>> I don't like that development of this feature has lingered for a
> > long
> > >>>>>> time
> > >>>>>> in this unfinished state when this work could have been done by
> now,
> > >>>>>> now
> > >>>>>> 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 look at the current state and be nonplussed. This will
> be
> > >>>>>> yet
> > >>>>>> another half finished thing in 2.0 when this merge happens.
> Promises
> > >>>>>> to
> > >>>>>> finish the unfinished work are nice but not 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 2.0 release to slip
> > >>>>>> further.
> > >>>>>>
> > >>>>>> Also, marking something experimental should be done on the merits
> of
> > >>>>>> that
> > >>>>>> evaluation, not simply to justify dropping unfinished work into a
> > >>>>>> release
> > >>>>>> branch.
> > >>>>>>
> > >>>>>> I will change my vote to -0.
> > >>>>>>
> > >>>>>>
> > >>>>>> On Mon, Mar 13, 2017 at 4:05 PM, Enis Söztutar<en...@apache.org>
> > >>>>>> wrote:
> > >>>>>>
> > >>>>>> I think there is some misconception of using the term "blockers"
> for
> > >>>>>>
> > >>>>>> referring to those jiras. My understanding is that those three
> jiras
> > >>>>>>> are
> > >>>>>>> blockers for the backup functionality to be more mature and more
> > >>>>>>> usable.
> > >>>>>>> But they are not release blockers. Let's say we merged the code
> in,
> > >>>>>>> and
> > >>>>>>> for
> > >>>>>>> some reason those did not get addressed in time. We can still do
> > the
> > >>>>>>> 2.0
> > >>>>>>> release without having to wait for the commits. We can instead
> mark
> > >>>>>>> the
> > >>>>>>> "backup" feature as experimental with known issues and go on with
> > the
> > >>>>>>> release. In that sense they are not real release 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
> > >>>>>>> luxury of having to wait another couple of months and doing yet
> > >>>>>>> another
> > >>>>>>> giant round of reviews because the code base is a moving target.
> > >>>>>>>
> > >>>>>>> Enis
> > >>>>>>>
> > >>>>>>> On Mon, Mar 13, 2017 at 3:46 PM, Devaraj Das<
> ddas@hortonworks.com>
> > >>>>>>> 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 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 to make the list of remaining work more complete
> > by
> > >>>>>>>
> > >>>>>>>> citing
> > >>>>>>>>
> > >>>>>>> that as pending work.
> > >>>>>>>
> > >>>>>>>> ________________________________________
> > >>>>>>>> From: Vladimir Rodionov<vl...@gmail.com>
> > >>>>>>>> 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 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 (including moving
> > backup/restore
> > >>>>>>>>>
> > >>>>>>>>>> out
> > >>>>>>>>>>
> > >>>>>>>>> of
> > >>>>>>>>
> > >>>>>>>> core to live in its own module).
> > >>>>>>>>
> > >>>>>>>>> For those who were not following our lengthy conversation on a
> > >>>>>>>>> review
> > >>>>>>>>>
> > >>>>>>>>> board, separation of a backup code into a separate module has
> > been
> > >>>>>>>> done last year, but has been reverted back by request of a
> > reviewer.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> -Vladimir
> > >>>>>>>>
> > >>>>>>>> On Mon, Mar 13, 2017 at 2:23 PM, Stack<st...@duboce.net>
> > wrote:
> > >>>>>>>>
> > >>>>>>>> On Fri, Mar 10, 2017 at 9:09 PM, Stack<st...@duboce.net>
> > wrote:
> > >>>>>>>>
> > >>>>>>>> On Fri, Mar 10, 2017 at 6:01 PM, Ted Yu<yu...@gmail.com>
> > >>>>>>>>> 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 burned a bunch of dev
> resource).
> > >>>>>>>>>
> > >>>>>>>>>> The patch as is is now in a state where it is too big for our
> > >>>>>>>>>> infra;
> > >>>>>>>>>>
> > >>>>>>>>>> rb
> > >>>>>>>>>>
> > >>>>>>>>> and JIRA are creaking under the size and # of iterations.
> > >>>>>>>>
> > >>>>>>>> Adding finish of new JIRAs to this merge implies a new round of
> > >>>>>>>>>
> > >>>>>>>>>> review
> > >>>>>>>>>>
> > >>>>>>>>> and
> > >>>>>>>>
> > >>>>>>>> test of an already massive patch. Who is going to do this work?
> > >>>>>>>>>
> > >>>>>>>>>> Going back to a new branch seems wrong route to take.
> > >>>>>>>>>>
> > >>>>>>>>>> St.Ack
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> To be more explicit, this patch was developed on a branch and
> > >>>>>>>>>> then a
> > >>>>>>>>>>
> > >>>>>>>>>> bunch
> > >>>>>>>>>
> > >>>>>>>> of dev resources were burned getting it into a state where it
> > could
> > >>>>>>>> be
> > >>>>>>>>
> > >>>>>>>>> merged to master. Going back to a branch to bulk up the merge
> so
> > it
> > >>>>>>>>> includes more JIRAs than the many it already incorporates is
> the
> > >>>>>>>>> wrong
> > >>>>>>>>> direction for us to be headed in. It ignores the feedback given
> > and
> > >>>>>>>>> the
> > >>>>>>>>> work done by Vladimir slimming down an already over-broad
> scope.
> > It
> > >>>>>>>>> is
> > >>>>>>>>>
> > >>>>>>>>> also
> > >>>>>>>>>
> > >>>>>>>> predicated on abundant review and testing resource being on tap
> to
> > >>>>>>>>
> > >>>>>>>>> cycle
> > >>>>>>>>>
> > >>>>>>>> on
> > >>>>>>>>
> > >>>>>>>> a feature that is useful, but non-core.
> > >>>>>>>>
> > >>>>>>>>> The patch is ready for merge IMO. Geoffrey makes a nice list of
> > >>>>>>>>> what
> > >>>>>>>>> is
> > >>>>>>>>> still to do though IIRC, the list is incomplete because a bunch
> > of
> > >>>>>>>>> follow-ons came of the review cycle (including moving
> > >>>>>>>>> backup/restore
> > >>>>>>>>>
> > >>>>>>>>> out
> > >>>>>>>>>
> > >>>>>>>> of
> > >>>>>>>>
> > >>>>>>>> core to live in its own module).
> > >>>>>>>>
> > >>>>>>>>> The patch needs three votes to merge. I am not against merge
> but
> > I
> > >>>>>>>>> am
> > >>>>>>>>>
> > >>>>>>>>> not
> > >>>>>>>>>
> > >>>>>>>> voting for the patch because I do have any more time to spend on
> > >>>>>>>> this
> > >>>>>>>>
> > >>>>>>>> non-core feature and feel that a vote will have me assume a
> > >>>>>>>>>
> > >>>>>>>>> responsibility
> > >>>>>>>>>
> > >>>>>>>> I will not shirk.
> > >>>>>>>>
> > >>>>>>>>> S
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> FYI
> > >>>>>>>>>
> > >>>>>>>>>> On Fri, Mar 10, 2017 at 3:30 PM, Ted Yu<yu...@gmail.com>
> > >>>>>>>>>>>
> > >>>>>>>>>>> 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 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,
> > >>>>>>>>>>>>
> > >>>>>>>>>>> we
> > >>>>>>>>>>
> > >>>>>>>>> propose to community for merging into branch-2 (master branch,
> if
> > >>>>>>>>
> > >>>>>>>>> branch-2
> > >>>>>>>>>>
> > >>>>>>>>>>> doesn't materialize for whatever reason) again
> > >>>>>>>>>>>
> > >>>>>>>>>>>> Cheers
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> On Fri, Mar 10, 2017 at 3:01 PM, Andrew Purtell<
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> apurtell@apache.org>
> > >>>>>>>>>>>>
> > >>>>>>>>>>> wrote:
> > >>>>>>>>>> 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 the documentation issue is important but not
> actually
> > a
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> blocker.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>> That may be a controversial opinion, but documentation can
> be
> > >>>>>>>>>>>> back-filled
> > >>>>>>>>>>>> worst case. So take HBASE-17133 off the list.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Remaining are effectively HBASE-14417, HBASE-14141, and
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> HBASE-15227.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>> They
> > >>>>>>>>>>>
> > >>>>>>>>>> all have patches attached to the respective JIRAs so
> completing
> > >>>>>>>>>>
> > >>>>>>>>>>> this
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> work
> > >>>>>>>>>>>
> > >>>>>>>>>> won't be onerous. Get these committed and I will lift my -1.
> The
> > >>>>>>>>>>
> > >>>>>>>>>>> others
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> who
> > >>>>>>>>>>> voted +1 on this thread surely can help with that.
> > >>>>>>>>>>>
> > >>>>>>>>>>>> Thanks.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> On Fri, Mar 10, 2017 at 2:32 PM, Vladimir Rodionov<
> > >>>>>>>>>>>>> vladrodionov@gmail.com>
> > >>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> No problem I will downgrade Blockers to Majors if it scares
> > >>>>>>>>>>>>> you,
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Andrew
> > >>>>>>>>>>>>
> > >>>>>>>>>>> [image: [image: 🙂]]
> > >>>>>>>>>
> > >>>>>>>>> Sent from my iPhone
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> On Mar 10, 2017, at 1:52 PM, Andrew Purtell<
> > >>>>>>>>>>>>>> apurtell@apache.org
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> 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
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> 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 prevent that release because these blockers
> will
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>> be
> > >>>>>>>>>>
> > >>>>>>>>>>> there. I
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>> am
> > >>>>>>>>>
> > >>>>>>>>>> inclined to veto. Probably we should not propose branch
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> merges
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> into
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>> code
> > >>>>>>>>>
> > >>>>>>>>>> we
> > >>>>>>>>>>>
> > >>>>>>>>>>>> are trying to get out the door with known blockers. Why not
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> do
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> that
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>> work
> > >>>>>>>>>
> > >>>>>>>>>> first? It seems an obvious question. Perhaps I am missing
> > >>>>>>>>>>>
> > >>>>>>>>>>>> something.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> If we can branch for 2.0 now and then merge this, and not
> > >>>>>>>>>>>>> into
> > >>>>>>>>>>>>> the
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>> 2.0
> > >>>>>>>>>
> > >>>>>>>>>> branch, I would vote +1 for branch merge even with known
> > >>>>>>>>>>>
> > >>>>>>>>>>>> blockers
> > >>>>>>>>>>>>> pending.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>> On Fri, Mar 10, 2017 at 1:42 PM, Vladimir Rodionov<
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> vladrodionov@gmail.com>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> 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<
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> apurtell@apache.org
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>> 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<
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> vladrodionov@gmail.com>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> 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
> reviews
> > >>>>>>>>>>>
> > >>>>>>>>>>>> and
> > >>>>>>>>>>>>>>>> has
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> probably
> > >>>>>>>>>>
> > >>>>>>>>>>> the most lengthy discussion thread on Apache JIRA
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> (HBASE-14123)
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> :)
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> The work has been split into 3 phases (HBASE-14030,
> 14123,
> > >>>>>>>>>>>
> > >>>>>>>>>>>> 14414)
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Two
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> first
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> are complete, third one is still in progress.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> *** Summary of work HBASE-14123
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> The new feature introduces new command-line extensions
> > to
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> hbase
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> command
> > >>>>>>>>>>
> > >>>>>>>>>>> and, from the client side, is accessible through
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> command-line
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> only
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Operations:
> > >>>>>>>>>>
> > >>>>>>>>>>> * Create full backup on a list of tables or backup set
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> * Create incremental backup image for table list or backup
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> set
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> * Restore list of tables from a given backup image
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> * Show current backup progress
> > >>>>>>>>>>
> > >>>>>>>>>>> * Delete backup image and all related images
> > >>>>>>>>>>>>>>>>>> * Show history of backups
> > >>>>>>>>>>>>>>>>>> * Backup set operations: create backup set, add/remove
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> table
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> to/from
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> backup
> > >>>>>>>>>
> > >>>>>>>>>> set, etc
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> In the current implementation, the feature is already
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> usable,
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> meaning
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> that
> > >>>>>>>>>>
> > >>>>>>>>>>> users can backup tables and restore them using provided
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> command-line
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> tools.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Both: full and incremental backups are supported.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> This work is based on original work of IBM team
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> (HBASE-7912).
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> The
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> full
> > >>>>>>>>>>
> > >>>>>>>>>>> list
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> of JIRAs included in this mega patch can be found in three
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> umbrella
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> JIRAs:
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> HBASE-14030 (Phase 1), HBASE-14123 (Phase 2) and
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> HBASE-14414
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> (Phase 3
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> -
> > >>>>>>>>>
> > >>>>>>>>>> all
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> resolved ones made it into the patch)
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> *** What are the remaining work items
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> All remaining items can be found in Phase 3 umbrella
> > JIRA:
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> HBASE-14414.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> They are split into 3 groups: BLOCKER, CRITICAL, MAJOR
> > >>>>>>>>>>>>>>>> Only BLOCKERs and CRITICALs are guaranteed for HBase 2.0
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> release.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> ***** BLOCKER
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> * HBASE-14417 Incremental backup and bulk loading ( Patch
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> available)
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> * HBASE-14135 HBase Backup/Restore Phase 3: Merge
> backup
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> images
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> * HBASE-14141 HBase Backup/Restore Phase 3: Filter WALs
> on
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> backup
> > >>>>>>>>>>>
> > >>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> include only edits from backup tables (Patch available)
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> * HBASE-17133 Backup documentation
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> * HBASE-15227 Fault tolerance support
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> ***** CRITICAL
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> * HBASE-16465 Disable split/merges during backup
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> We have umbrella JIRA (HBASE-14414) to track all the
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> remaining
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> work
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> All the BLOCKER and CRITICAL JIRAs currently in open
> state
> > >>>>>>>>>>
> > >>>>>>>>>>> will
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> be
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> implemented by 2.0 release time. Some MAJOR too, but it
> > >>>>>>>>>>>
> > >>>>>>>>>>>> depends
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> on
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> resource
> > >>>>>>>>>>>
> > >>>>>>>>>>>> availability
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> The former development branch (HBASE-7912) is obsolete and
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> will
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> be
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> closed/deleted after the merge.
> > >>>>>>>>>>>
> > >>>>>>>>>>>> We want backup to be a GA feature in 2.0
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> We are going to support full backward compatibility for
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> backup
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> tool in
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> 2.0
> > >>>>>>>>>>
> > >>>>>>>>>>> and onwards.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> **** Configuration
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> Backup is disabled, by default. To enable it, the
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> following
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> configuration
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> properties must be added to hbase-site.xml:
> > >>>>>>>>>
> > >>>>>>>>>> hbase.backup.enable=true
> > >>>>>>>>>>>>>>>>>> hbase.master.logcleaner.plugins=YOUR_PLUGINS,org.
> > >>>>>>>>>>>>>>>>>> apache.hadoop.hbase.backup.master.BackupLogCleaner
> > >>>>>>>>>>>>>>>>>> hbase.procedure.master.classes=YOUR_CLASSES,org.
> > >>>>>>>>>>>>>>>>>> apache.hadoop.hbase.backup.master.
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> LogRollMasterProcedureManager
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> hbase.procedure.regionserver.classes=YOUR_CLASSES,org.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> apache.hadoop.hbase.backup.regionserver.
> > >>>>>>>>>>>
> > >>>>>>>>>>>> LogRollRegionServerProcedureMa
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> nager
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> I would like to thank IBM team and Jerry He for
> original
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> work,
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Enis, Ted, Stack, Matteo, Jerry for time spent on code
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> reviews
> > >>>>>>>>>>
> > >>>>>>>>>>> Special thanks to Ted Yu for his co-development work.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> References:
> > >>>>>>>>>>
> > >>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-7912
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> (original
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> IBM,
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> contains
> > >>>>>>>>>
> > >>>>>>>>>> design doc)
> > >>>>>>>>>>>
> > >>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-14030 (Phase
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> 1)
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-14123
> (Phase
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> 2)
> > >>>>>>>>>
> > >>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-14414 (Phase
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> 3)
> > >>>>>>>>>
> > >>>>>>>>>> Please vote +1/-1 by midnight Pacific Time (00:00
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> -0800 GMT) on March 11th on whether or not we should
> > >>>>>>>>>
> > >>>>>>>>>> merge
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> this
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> into
> > >>>>>>>>>
> > >>>>>>>>>> the
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> current master.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> -Vladimir Rodionov
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Best regards,
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> - Andy
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> If you are given a choice, you believe you have acted
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> freely. -
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Raymond
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Teller (via Peter Watts)
> > >>>>>>>>>>
> > >>>>>>>>>>> --
> > >>>>>>>>>>>>>>> Best regards,
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> - Andy
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> If you are given a choice, you believe you have acted
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> freely. -
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Raymond
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>> Teller (via Peter Watts)
> > >>>>>>>>>
> > >>>>>>>>>> --
> > >>>>>>>>>>>>> Best regards,
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> - Andy
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> If you are given a choice, you believe you have acted
> > freely. -
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Raymond
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>> Teller (via Peter Watts)
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>
> > >>>>
> > >>
> > >>
> >
>
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
Posted by Stack <st...@duboce.net>.
On Wed, Mar 15, 2017 at 5:51 PM, Ted Yu <yu...@gmail.com> wrote:
> Thanks for the vote, Josh.
>
> So far there have been 3 +1's (Enis', mine and Josh's)
>
> Should we start another thread on the procedure of merging or use this
> thread ?
> Background:
> HBASE-7912 branch is way out of date.
> Latest rounds of mega patch were based on then-current master branch.
>
>
1. Vlad is running this VOTE, not you.
2. Don't you need 3 PMC votes to merge? I count 2.
3. You almost derailed the merge with your earlier interjection rushing to
take us in the wrong direction; you'd think you'd learn from your past
experience but here you are again w/ haste and rash summary.
4. This vote has been awkward. Josh's note is considered and careful. You'd
think it could hang out there a while to see if draws a response rather
than rush to close.
I thought I was reviewing a patch that was against master, not some version
of master from eons ago. Thats a problem. When was the last rebase?
St.Ack
> Thanks
>
> On Wed, Mar 15, 2017 at 4:22 PM, Josh Elser <el...@apache.org> wrote:
>
> > Spent the day playing around with this on 6 nodes.
> >
> > I've found some rough edges: some known (the docs blocker Vlad pointed
> > out) and some that I think are unknown (tooling is rough -- partially
> from
> > wrong help messages and, I think, changes in design like Master-submitted
> > MR jobs).
> >
> > But, Stack's assessment (and Andrew's reminder) that further tweaking
> > would just throw us back into another review cycle is a real concern.
> It's
> > unfortunate that this feature has lingered so long aside of master to get
> > to this point, but I don't see any realistic resolution to this problem
> > than a merge. In the future, this is something we'll have to try harder
> to
> > avoid letting happen (looking in the mirror with quota work...)
> >
> > Thankfully, I can help out with development/review on the outstanding
> > blockers (notably, the two I pruned from Vlad's original of five -- the
> > other three still seem to be improvements). In addition to these
> blockers,
> > I believe the documentation *must* be updated before a release to note
> that
> > this feature is still growing -- it does not feel like a quality feature
> > that I've come to expect from this community. This isn't a knock on Vlad
> > and company; this is a hard problem and one that I could not have done
> > better given time constraints, but it is also one that users will demand
> > simplicity and the utmost correctness around. To this end, I will also
> try
> > to help out to smooth out these issues in the following 2.x release.
> >
> > So, this leaves me to say: +1 to merge with the caveat that the docs are
> > updated to make sure that any known, user-pitfalls are clearly
> documented.
> > This vote also comes with as real of a promise that I can make to help
> > avoid any issues with this feature that would prevent a 2.0 release.
> >
> > Thanks to all the giants whose shoulders I'm standing on to be able to
> > make this vote.
> >
> > Andrew Purtell wrote:
> >
> >> Great, and I changed my vote to -0 because Stack made a good argument
> that
> >> making more changes would invalidate review up to this point, and I
> trust
> >> this will be resolved before release.
> >>
> >> On Tue, Mar 14, 2017 at 4:29 PM, Josh Elser<el...@apache.org> wrote:
> >>
> >> Sorry Andrew, let me clarify as that didn't come out right.
> >>>
> >>> I didn't mean that isn't a conversation worth having _now_, just that I
> >>> was intentionally avoiding it in my previous email because I didn't
> >>> understand the scope of those issues that Vlad had identified. I wanted
> >>> to
> >>> better understand what they were really meant for a user before coming
> to
> >>> my own decision about whether or not I think they are blockers.
> >>>
> >>> That aside, I would agree with you that HBASE-15227 sounds like a real
> >>> blocker. Forcing a new full backup for every table sounds really bad --
> >>> that's not the kind of experience we'd want a user to have.
> >>>
> >>> Andrew Purtell wrote:
> >>>
> >>> I'm going to intentional avoid addressing the discussion of shipping
> >>>> partial features (related, but not relevant at the moment).
> >>>>
> >>>> Then we are not having the same conversation, because it is precisely
> >>>> because this is a vote for this feature to go into 2.0, which is
> already
> >>>> overdue, so should be released yesterday, that I took mention of
> >>>> "blocker"
> >>>> at face value. At least one of them seems to certainly approach this
> >>>> definition. It will be not user friendly, to say the least, to use
> this
> >>>> in
> >>>> a large scale deployment with HBASE-15227 unfinished. HBASE-15227
> >>>> currently
> >>>> has a severity of BLOCKER. Despite what is going on in our politics,
> >>>> words
> >>>> matter and we do not get to redefine them for convenience.
> >>>>
> >>>> Once this work is merged in, how is HBASE-15227 not a blocker for 2.0?
> >>>> Because Vlad offered to reduce its severity to make me feel better?
> >>>> Currently the description on the issue is "System must be tolerant to
> >>>> faults. Backup operations MUST be atomic (no partial completion state
> in
> >>>> system table)" Sounds like a blocker to me, indeed. It is an honest
> >>>> assessment and I don't think anyone is doing the community a favor by
> >>>> trying to walk that back.
> >>>>
> >>>>
> >>>> On Tue, Mar 14, 2017 at 1:57 PM, Josh Elser<el...@apache.org>
> wrote:
> >>>>
> >>>> I took a moment to read through the "blockers" as originally
> identified
> >>>> by
> >>>>
> >>>>> Vlad, and (to echo Enis' take) I read the majority of them as being
> >>>>> blockers not for the next release, but for a "full-fledged feature".
> >>>>> I'm
> >>>>> going to intentional avoid addressing the discussion of shipping
> >>>>> partial
> >>>>> features (related, but not relevant at the moment).
> >>>>>
> >>>>> HBASE-15227 is actually the one that bothers me the most, with
> >>>>> HBASE-17133
> >>>>> coming in close behind. Vlad, is there any documentation you can
> point
> >>>>> me
> >>>>> to about what the current issues are with the current implementation?
> >>>>> For
> >>>>> example, what happens now if the system has some kind of "partial
> >>>>> completion state"?
> >>>>>
> >>>>> Documentation is one of those that is really hard to judge. We want
> to
> >>>>> get
> >>>>> this code out for people to use (and to free up our strained dev
> >>>>> resources), but what good is some feature if the docs are
> >>>>> missing/incomplete?
> >>>>>
> >>>>> I think I could stomach the docs being inaccurate (with a clear
> >>>>> disclaimer
> >>>>> that the chapter is incomplete -- that's a 5min task). But, I think I
> >>>>> need
> >>>>> an answer about how the feature handles our common dist-sys category
> of
> >>>>> problems 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
> >>>>> problem as an (ignorant) user ;)
> >>>>>
> >>>>>
> >>>>> Andrew Purtell wrote:
> >>>>>
> >>>>> I don't like that issues were identified as "blockers" but now there
> is
> >>>>>
> >>>>>> an
> >>>>>> attempt to walk that back.
> >>>>>>
> >>>>>> I don't like that development of this feature has lingered for a
> long
> >>>>>> time
> >>>>>> in this unfinished state when this work could have been done by now,
> >>>>>> now
> >>>>>> 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 look at the current state and be nonplussed. This will be
> >>>>>> yet
> >>>>>> another half finished thing in 2.0 when this merge happens. Promises
> >>>>>> to
> >>>>>> finish the unfinished work are nice but not 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 2.0 release to slip
> >>>>>> further.
> >>>>>>
> >>>>>> Also, marking something experimental should be done on the merits of
> >>>>>> that
> >>>>>> evaluation, not simply to justify dropping unfinished work into a
> >>>>>> release
> >>>>>> branch.
> >>>>>>
> >>>>>> I will change my vote to -0.
> >>>>>>
> >>>>>>
> >>>>>> On Mon, Mar 13, 2017 at 4:05 PM, Enis Söztutar<en...@apache.org>
> >>>>>> wrote:
> >>>>>>
> >>>>>> I think there is some misconception of using the term "blockers" for
> >>>>>>
> >>>>>> referring to those jiras. My understanding is that those three jiras
> >>>>>>> are
> >>>>>>> blockers for the backup functionality to be more mature and more
> >>>>>>> usable.
> >>>>>>> But they are not release blockers. Let's say we merged the code in,
> >>>>>>> and
> >>>>>>> for
> >>>>>>> some reason those did not get addressed in time. We can still do
> the
> >>>>>>> 2.0
> >>>>>>> release without having to wait for the commits. We can instead mark
> >>>>>>> the
> >>>>>>> "backup" feature as experimental with known issues and go on with
> the
> >>>>>>> release. In that sense they are not real release 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
> >>>>>>> luxury of having to wait another couple of months and doing yet
> >>>>>>> another
> >>>>>>> giant round of reviews because the code base is a moving target.
> >>>>>>>
> >>>>>>> Enis
> >>>>>>>
> >>>>>>> On Mon, Mar 13, 2017 at 3:46 PM, Devaraj Das<dd...@hortonworks.com>
> >>>>>>> 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 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 to make the list of remaining work more complete
> by
> >>>>>>>
> >>>>>>>> citing
> >>>>>>>>
> >>>>>>> that as pending work.
> >>>>>>>
> >>>>>>>> ________________________________________
> >>>>>>>> From: Vladimir Rodionov<vl...@gmail.com>
> >>>>>>>> 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 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 (including moving
> backup/restore
> >>>>>>>>>
> >>>>>>>>>> out
> >>>>>>>>>>
> >>>>>>>>> of
> >>>>>>>>
> >>>>>>>> core to live in its own module).
> >>>>>>>>
> >>>>>>>>> For those who were not following our lengthy conversation on a
> >>>>>>>>> review
> >>>>>>>>>
> >>>>>>>>> board, separation of a backup code into a separate module has
> been
> >>>>>>>> done last year, but has been reverted back by request of a
> reviewer.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> -Vladimir
> >>>>>>>>
> >>>>>>>> On Mon, Mar 13, 2017 at 2:23 PM, Stack<st...@duboce.net>
> wrote:
> >>>>>>>>
> >>>>>>>> On Fri, Mar 10, 2017 at 9:09 PM, Stack<st...@duboce.net>
> wrote:
> >>>>>>>>
> >>>>>>>> On Fri, Mar 10, 2017 at 6:01 PM, Ted Yu<yu...@gmail.com>
> >>>>>>>>> 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 burned a bunch of dev resource).
> >>>>>>>>>
> >>>>>>>>>> The patch as is is now in a state where it is too big for our
> >>>>>>>>>> infra;
> >>>>>>>>>>
> >>>>>>>>>> rb
> >>>>>>>>>>
> >>>>>>>>> and JIRA are creaking under the size and # of iterations.
> >>>>>>>>
> >>>>>>>> Adding finish of new JIRAs to this merge implies a new round of
> >>>>>>>>>
> >>>>>>>>>> review
> >>>>>>>>>>
> >>>>>>>>> and
> >>>>>>>>
> >>>>>>>> test of an already massive patch. Who is going to do this work?
> >>>>>>>>>
> >>>>>>>>>> Going back to a new branch seems wrong route to take.
> >>>>>>>>>>
> >>>>>>>>>> St.Ack
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> To be more explicit, this patch was developed on a branch and
> >>>>>>>>>> then a
> >>>>>>>>>>
> >>>>>>>>>> bunch
> >>>>>>>>>
> >>>>>>>> of dev resources were burned getting it into a state where it
> could
> >>>>>>>> be
> >>>>>>>>
> >>>>>>>>> merged to master. Going back to a branch to bulk up the merge so
> it
> >>>>>>>>> includes more JIRAs than the many it already incorporates is the
> >>>>>>>>> wrong
> >>>>>>>>> direction for us to be headed in. It ignores the feedback given
> and
> >>>>>>>>> the
> >>>>>>>>> work done by Vladimir slimming down an already over-broad scope.
> It
> >>>>>>>>> is
> >>>>>>>>>
> >>>>>>>>> also
> >>>>>>>>>
> >>>>>>>> predicated on abundant review and testing resource being on tap to
> >>>>>>>>
> >>>>>>>>> cycle
> >>>>>>>>>
> >>>>>>>> on
> >>>>>>>>
> >>>>>>>> a feature that is useful, but non-core.
> >>>>>>>>
> >>>>>>>>> The patch is ready for merge IMO. Geoffrey makes a nice list of
> >>>>>>>>> what
> >>>>>>>>> is
> >>>>>>>>> still to do though IIRC, the list is incomplete because a bunch
> of
> >>>>>>>>> follow-ons came of the review cycle (including moving
> >>>>>>>>> backup/restore
> >>>>>>>>>
> >>>>>>>>> out
> >>>>>>>>>
> >>>>>>>> of
> >>>>>>>>
> >>>>>>>> core to live in its own module).
> >>>>>>>>
> >>>>>>>>> The patch needs three votes to merge. I am not against merge but
> I
> >>>>>>>>> am
> >>>>>>>>>
> >>>>>>>>> not
> >>>>>>>>>
> >>>>>>>> voting for the patch because I do have any more time to spend on
> >>>>>>>> this
> >>>>>>>>
> >>>>>>>> non-core feature and feel that a vote will have me assume a
> >>>>>>>>>
> >>>>>>>>> responsibility
> >>>>>>>>>
> >>>>>>>> I will not shirk.
> >>>>>>>>
> >>>>>>>>> S
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> FYI
> >>>>>>>>>
> >>>>>>>>>> On Fri, Mar 10, 2017 at 3:30 PM, Ted Yu<yu...@gmail.com>
> >>>>>>>>>>>
> >>>>>>>>>>> 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 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,
> >>>>>>>>>>>>
> >>>>>>>>>>> we
> >>>>>>>>>>
> >>>>>>>>> propose to community for merging into branch-2 (master branch, if
> >>>>>>>>
> >>>>>>>>> branch-2
> >>>>>>>>>>
> >>>>>>>>>>> doesn't materialize for whatever reason) again
> >>>>>>>>>>>
> >>>>>>>>>>>> Cheers
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Fri, Mar 10, 2017 at 3:01 PM, Andrew Purtell<
> >>>>>>>>>>>>
> >>>>>>>>>>>> apurtell@apache.org>
> >>>>>>>>>>>>
> >>>>>>>>>>> wrote:
> >>>>>>>>>> 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 the documentation issue is important but not actually
> a
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> blocker.
> >>>>>>>>>>>>>
> >>>>>>>>>>>> That may be a controversial opinion, but documentation can be
> >>>>>>>>>>>> back-filled
> >>>>>>>>>>>> worst case. So take HBASE-17133 off the list.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Remaining are effectively HBASE-14417, HBASE-14141, and
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> HBASE-15227.
> >>>>>>>>>>>>>
> >>>>>>>>>>>> They
> >>>>>>>>>>>
> >>>>>>>>>> all have patches attached to the respective JIRAs so completing
> >>>>>>>>>>
> >>>>>>>>>>> this
> >>>>>>>>>>>>
> >>>>>>>>>>>> work
> >>>>>>>>>>>
> >>>>>>>>>> won't be onerous. Get these committed and I will lift my -1. The
> >>>>>>>>>>
> >>>>>>>>>>> others
> >>>>>>>>>>>>
> >>>>>>>>>>>> who
> >>>>>>>>>>> voted +1 on this thread surely can help with that.
> >>>>>>>>>>>
> >>>>>>>>>>>> Thanks.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Fri, Mar 10, 2017 at 2:32 PM, Vladimir Rodionov<
> >>>>>>>>>>>>> vladrodionov@gmail.com>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> No problem I will downgrade Blockers to Majors if it scares
> >>>>>>>>>>>>> you,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Andrew
> >>>>>>>>>>>>
> >>>>>>>>>>> [image: [image: 🙂]]
> >>>>>>>>>
> >>>>>>>>> Sent from my iPhone
> >>>>>>>>>>>>
> >>>>>>>>>>>>> On Mar 10, 2017, at 1:52 PM, Andrew Purtell<
> >>>>>>>>>>>>>> apurtell@apache.org
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 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 prevent that release because these blockers will
> >>>>>>>>>>>>>
> >>>>>>>>>>>> be
> >>>>>>>>>>
> >>>>>>>>>>> there. I
> >>>>>>>>>>>>>
> >>>>>>>>>>>> am
> >>>>>>>>>
> >>>>>>>>>> inclined to veto. Probably we should not propose branch
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> merges
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> into
> >>>>>>>>>>>>>
> >>>>>>>>>>>> code
> >>>>>>>>>
> >>>>>>>>>> we
> >>>>>>>>>>>
> >>>>>>>>>>>> are trying to get out the door with known blockers. Why not
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> do
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> that
> >>>>>>>>>>>>>
> >>>>>>>>>>>> work
> >>>>>>>>>
> >>>>>>>>>> first? It seems an obvious question. Perhaps I am missing
> >>>>>>>>>>>
> >>>>>>>>>>>> something.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> If we can branch for 2.0 now and then merge this, and not
> >>>>>>>>>>>>> into
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>>
> >>>>>>>>>>>> 2.0
> >>>>>>>>>
> >>>>>>>>>> branch, I would vote +1 for branch merge even with known
> >>>>>>>>>>>
> >>>>>>>>>>>> blockers
> >>>>>>>>>>>>> pending.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> On Fri, Mar 10, 2017 at 1:42 PM, Vladimir Rodionov<
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> vladrodionov@gmail.com>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> 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<
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> apurtell@apache.org
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> 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<
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> vladrodionov@gmail.com>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> 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 reviews
> >>>>>>>>>>>
> >>>>>>>>>>>> and
> >>>>>>>>>>>>>>>> has
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> probably
> >>>>>>>>>>
> >>>>>>>>>>> the most lengthy discussion thread on Apache JIRA
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> (HBASE-14123)
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> :)
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> The work has been split into 3 phases (HBASE-14030, 14123,
> >>>>>>>>>>>
> >>>>>>>>>>>> 14414)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Two
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> first
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> are complete, third one is still in progress.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> *** Summary of work HBASE-14123
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> The new feature introduces new command-line extensions
> to
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> hbase
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> command
> >>>>>>>>>>
> >>>>>>>>>>> and, from the client side, is accessible through
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> command-line
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> only
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Operations:
> >>>>>>>>>>
> >>>>>>>>>>> * Create full backup on a list of tables or backup set
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> * Create incremental backup image for table list or backup
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> set
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> * Restore list of tables from a given backup image
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> * Show current backup progress
> >>>>>>>>>>
> >>>>>>>>>>> * Delete backup image and all related images
> >>>>>>>>>>>>>>>>>> * Show history of backups
> >>>>>>>>>>>>>>>>>> * Backup set operations: create backup set, add/remove
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> table
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> to/from
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> backup
> >>>>>>>>>
> >>>>>>>>>> set, etc
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> In the current implementation, the feature is already
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> usable,
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> meaning
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> that
> >>>>>>>>>>
> >>>>>>>>>>> users can backup tables and restore them using provided
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> command-line
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> tools.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Both: full and incremental backups are supported.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> This work is based on original work of IBM team
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> (HBASE-7912).
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> The
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> full
> >>>>>>>>>>
> >>>>>>>>>>> list
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> of JIRAs included in this mega patch can be found in three
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> umbrella
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> JIRAs:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> HBASE-14030 (Phase 1), HBASE-14123 (Phase 2) and
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> HBASE-14414
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> (Phase 3
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> -
> >>>>>>>>>
> >>>>>>>>>> all
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> resolved ones made it into the patch)
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> *** What are the remaining work items
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> All remaining items can be found in Phase 3 umbrella
> JIRA:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> HBASE-14414.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> They are split into 3 groups: BLOCKER, CRITICAL, MAJOR
> >>>>>>>>>>>>>>>> Only BLOCKERs and CRITICALs are guaranteed for HBase 2.0
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> release.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> ***** BLOCKER
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> * HBASE-14417 Incremental backup and bulk loading ( Patch
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> available)
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> * HBASE-14135 HBase Backup/Restore Phase 3: Merge backup
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> images
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> * HBASE-14141 HBase Backup/Restore Phase 3: Filter WALs on
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> backup
> >>>>>>>>>>>
> >>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> include only edits from backup tables (Patch available)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> * HBASE-17133 Backup documentation
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> * HBASE-15227 Fault tolerance support
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> ***** CRITICAL
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> * HBASE-16465 Disable split/merges during backup
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> We have umbrella JIRA (HBASE-14414) to track all the
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> remaining
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> work
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> All the BLOCKER and CRITICAL JIRAs currently in open state
> >>>>>>>>>>
> >>>>>>>>>>> will
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> implemented by 2.0 release time. Some MAJOR too, but it
> >>>>>>>>>>>
> >>>>>>>>>>>> depends
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> on
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> resource
> >>>>>>>>>>>
> >>>>>>>>>>>> availability
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> The former development branch (HBASE-7912) is obsolete and
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> will
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> closed/deleted after the merge.
> >>>>>>>>>>>
> >>>>>>>>>>>> We want backup to be a GA feature in 2.0
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> We are going to support full backward compatibility for
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> backup
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> tool in
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> 2.0
> >>>>>>>>>>
> >>>>>>>>>>> and onwards.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> **** Configuration
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Backup is disabled, by default. To enable it, the
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> following
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> configuration
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> properties must be added to hbase-site.xml:
> >>>>>>>>>
> >>>>>>>>>> hbase.backup.enable=true
> >>>>>>>>>>>>>>>>>> hbase.master.logcleaner.plugins=YOUR_PLUGINS,org.
> >>>>>>>>>>>>>>>>>> apache.hadoop.hbase.backup.master.BackupLogCleaner
> >>>>>>>>>>>>>>>>>> hbase.procedure.master.classes=YOUR_CLASSES,org.
> >>>>>>>>>>>>>>>>>> apache.hadoop.hbase.backup.master.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> LogRollMasterProcedureManager
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> hbase.procedure.regionserver.classes=YOUR_CLASSES,org.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> apache.hadoop.hbase.backup.regionserver.
> >>>>>>>>>>>
> >>>>>>>>>>>> LogRollRegionServerProcedureMa
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> nager
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I would like to thank IBM team and Jerry He for original
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> work,
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Enis, Ted, Stack, Matteo, Jerry for time spent on code
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> reviews
> >>>>>>>>>>
> >>>>>>>>>>> Special thanks to Ted Yu for his co-development work.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> References:
> >>>>>>>>>>
> >>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-7912
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> (original
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> IBM,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> contains
> >>>>>>>>>
> >>>>>>>>>> design doc)
> >>>>>>>>>>>
> >>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-14030 (Phase
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> 1)
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-14123 (Phase
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> 2)
> >>>>>>>>>
> >>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-14414 (Phase
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> 3)
> >>>>>>>>>
> >>>>>>>>>> Please vote +1/-1 by midnight Pacific Time (00:00
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> -0800 GMT) on March 11th on whether or not we should
> >>>>>>>>>
> >>>>>>>>>> merge
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> this
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> into
> >>>>>>>>>
> >>>>>>>>>> the
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> current master.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> -Vladimir Rodionov
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Best regards,
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> - Andy
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> If you are given a choice, you believe you have acted
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> freely. -
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Raymond
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Teller (via Peter Watts)
> >>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>>>>>> Best regards,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> - Andy
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> If you are given a choice, you believe you have acted
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> freely. -
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Raymond
> >>>>>>>>>>>>>
> >>>>>>>>>>>> Teller (via Peter Watts)
> >>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>>>>> Best regards,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> - Andy
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> If you are given a choice, you believe you have acted
> freely. -
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Raymond
> >>>>>>>>>>>>>
> >>>>>>>>>>>> Teller (via Peter Watts)
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>
> >>>>
> >>
> >>
>
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
Posted by Ted Yu <yu...@gmail.com>.
Thanks for the vote, Josh.
So far there have been 3 +1's (Enis', mine and Josh's)
Should we start another thread on the procedure of merging or use this
thread ?
Background:
HBASE-7912 branch is way out of date.
Latest rounds of mega patch were based on then-current master branch.
Thanks
On Wed, Mar 15, 2017 at 4:22 PM, Josh Elser <el...@apache.org> wrote:
> Spent the day playing around with this on 6 nodes.
>
> I've found some rough edges: some known (the docs blocker Vlad pointed
> out) and some that I think are unknown (tooling is rough -- partially from
> wrong help messages and, I think, changes in design like Master-submitted
> MR jobs).
>
> But, Stack's assessment (and Andrew's reminder) that further tweaking
> would just throw us back into another review cycle is a real concern. It's
> unfortunate that this feature has lingered so long aside of master to get
> to this point, but I don't see any realistic resolution to this problem
> than a merge. In the future, this is something we'll have to try harder to
> avoid letting happen (looking in the mirror with quota work...)
>
> Thankfully, I can help out with development/review on the outstanding
> blockers (notably, the two I pruned from Vlad's original of five -- the
> other three still seem to be improvements). In addition to these blockers,
> I believe the documentation *must* be updated before a release to note that
> this feature is still growing -- it does not feel like a quality feature
> that I've come to expect from this community. This isn't a knock on Vlad
> and company; this is a hard problem and one that I could not have done
> better given time constraints, but it is also one that users will demand
> simplicity and the utmost correctness around. To this end, I will also try
> to help out to smooth out these issues in the following 2.x release.
>
> So, this leaves me to say: +1 to merge with the caveat that the docs are
> updated to make sure that any known, user-pitfalls are clearly documented.
> This vote also comes with as real of a promise that I can make to help
> avoid any issues with this feature that would prevent a 2.0 release.
>
> Thanks to all the giants whose shoulders I'm standing on to be able to
> make this vote.
>
> Andrew Purtell wrote:
>
>> Great, and I changed my vote to -0 because Stack made a good argument that
>> making more changes would invalidate review up to this point, and I trust
>> this will be resolved before release.
>>
>> On Tue, Mar 14, 2017 at 4:29 PM, Josh Elser<el...@apache.org> wrote:
>>
>> Sorry Andrew, let me clarify as that didn't come out right.
>>>
>>> I didn't mean that isn't a conversation worth having _now_, just that I
>>> was intentionally avoiding it in my previous email because I didn't
>>> understand the scope of those issues that Vlad had identified. I wanted
>>> to
>>> better understand what they were really meant for a user before coming to
>>> my own decision about whether or not I think they are blockers.
>>>
>>> That aside, I would agree with you that HBASE-15227 sounds like a real
>>> blocker. Forcing a new full backup for every table sounds really bad --
>>> that's not the kind of experience we'd want a user to have.
>>>
>>> Andrew Purtell wrote:
>>>
>>> I'm going to intentional avoid addressing the discussion of shipping
>>>> partial features (related, but not relevant at the moment).
>>>>
>>>> Then we are not having the same conversation, because it is precisely
>>>> because this is a vote for this feature to go into 2.0, which is already
>>>> overdue, so should be released yesterday, that I took mention of
>>>> "blocker"
>>>> at face value. At least one of them seems to certainly approach this
>>>> definition. It will be not user friendly, to say the least, to use this
>>>> in
>>>> a large scale deployment with HBASE-15227 unfinished. HBASE-15227
>>>> currently
>>>> has a severity of BLOCKER. Despite what is going on in our politics,
>>>> words
>>>> matter and we do not get to redefine them for convenience.
>>>>
>>>> Once this work is merged in, how is HBASE-15227 not a blocker for 2.0?
>>>> Because Vlad offered to reduce its severity to make me feel better?
>>>> Currently the description on the issue is "System must be tolerant to
>>>> faults. Backup operations MUST be atomic (no partial completion state in
>>>> system table)" Sounds like a blocker to me, indeed. It is an honest
>>>> assessment and I don't think anyone is doing the community a favor by
>>>> trying to walk that back.
>>>>
>>>>
>>>> On Tue, Mar 14, 2017 at 1:57 PM, Josh Elser<el...@apache.org> wrote:
>>>>
>>>> I took a moment to read through the "blockers" as originally identified
>>>> by
>>>>
>>>>> Vlad, and (to echo Enis' take) I read the majority of them as being
>>>>> blockers not for the next release, but for a "full-fledged feature".
>>>>> I'm
>>>>> going to intentional avoid addressing the discussion of shipping
>>>>> partial
>>>>> features (related, but not relevant at the moment).
>>>>>
>>>>> HBASE-15227 is actually the one that bothers me the most, with
>>>>> HBASE-17133
>>>>> coming in close behind. Vlad, is there any documentation you can point
>>>>> me
>>>>> to about what the current issues are with the current implementation?
>>>>> For
>>>>> example, what happens now if the system has some kind of "partial
>>>>> completion state"?
>>>>>
>>>>> Documentation is one of those that is really hard to judge. We want to
>>>>> get
>>>>> this code out for people to use (and to free up our strained dev
>>>>> resources), but what good is some feature if the docs are
>>>>> missing/incomplete?
>>>>>
>>>>> I think I could stomach the docs being inaccurate (with a clear
>>>>> disclaimer
>>>>> that the chapter is incomplete -- that's a 5min task). But, I think I
>>>>> need
>>>>> an answer about how the feature handles our common dist-sys category of
>>>>> problems 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
>>>>> problem as an (ignorant) user ;)
>>>>>
>>>>>
>>>>> Andrew Purtell wrote:
>>>>>
>>>>> I don't like that issues were identified as "blockers" but now there is
>>>>>
>>>>>> an
>>>>>> attempt to walk that back.
>>>>>>
>>>>>> I don't like that development of this feature has lingered for a long
>>>>>> time
>>>>>> in this unfinished state when this work could have been done by now,
>>>>>> now
>>>>>> 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 look at the current state and be nonplussed. This will be
>>>>>> yet
>>>>>> another half finished thing in 2.0 when this merge happens. Promises
>>>>>> to
>>>>>> finish the unfinished work are nice but not 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 2.0 release to slip
>>>>>> further.
>>>>>>
>>>>>> Also, marking something experimental should be done on the merits of
>>>>>> that
>>>>>> evaluation, not simply to justify dropping unfinished work into a
>>>>>> release
>>>>>> branch.
>>>>>>
>>>>>> I will change my vote to -0.
>>>>>>
>>>>>>
>>>>>> On Mon, Mar 13, 2017 at 4:05 PM, Enis Söztutar<en...@apache.org>
>>>>>> wrote:
>>>>>>
>>>>>> I think there is some misconception of using the term "blockers" for
>>>>>>
>>>>>> referring to those jiras. My understanding is that those three jiras
>>>>>>> are
>>>>>>> blockers for the backup functionality to be more mature and more
>>>>>>> usable.
>>>>>>> But they are not release blockers. Let's say we merged the code in,
>>>>>>> and
>>>>>>> for
>>>>>>> some reason those did not get addressed in time. We can still do the
>>>>>>> 2.0
>>>>>>> release without having to wait for the commits. We can instead mark
>>>>>>> the
>>>>>>> "backup" feature as experimental with known issues and go on with the
>>>>>>> release. In that sense they are not real release 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
>>>>>>> luxury of having to wait another couple of months and doing yet
>>>>>>> another
>>>>>>> giant round of reviews because the code base is a moving target.
>>>>>>>
>>>>>>> Enis
>>>>>>>
>>>>>>> On Mon, Mar 13, 2017 at 3:46 PM, Devaraj Das<dd...@hortonworks.com>
>>>>>>> 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 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 to make the list of remaining work more complete by
>>>>>>>
>>>>>>>> citing
>>>>>>>>
>>>>>>> that as pending work.
>>>>>>>
>>>>>>>> ________________________________________
>>>>>>>> From: Vladimir Rodionov<vl...@gmail.com>
>>>>>>>> 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 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 (including moving backup/restore
>>>>>>>>>
>>>>>>>>>> out
>>>>>>>>>>
>>>>>>>>> of
>>>>>>>>
>>>>>>>> core to live in its own module).
>>>>>>>>
>>>>>>>>> For those who were not following our lengthy conversation on a
>>>>>>>>> review
>>>>>>>>>
>>>>>>>>> board, separation of a backup code into a separate module has been
>>>>>>>> done last year, but has been reverted back by request of a reviewer.
>>>>>>>>
>>>>>>>>
>>>>>>>> -Vladimir
>>>>>>>>
>>>>>>>> On Mon, Mar 13, 2017 at 2:23 PM, Stack<st...@duboce.net> wrote:
>>>>>>>>
>>>>>>>> On Fri, Mar 10, 2017 at 9:09 PM, Stack<st...@duboce.net> wrote:
>>>>>>>>
>>>>>>>> On Fri, Mar 10, 2017 at 6:01 PM, Ted Yu<yu...@gmail.com>
>>>>>>>>> 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 burned a bunch of dev resource).
>>>>>>>>>
>>>>>>>>>> The patch as is is now in a state where it is too big for our
>>>>>>>>>> infra;
>>>>>>>>>>
>>>>>>>>>> rb
>>>>>>>>>>
>>>>>>>>> and JIRA are creaking under the size and # of iterations.
>>>>>>>>
>>>>>>>> Adding finish of new JIRAs to this merge implies a new round of
>>>>>>>>>
>>>>>>>>>> review
>>>>>>>>>>
>>>>>>>>> and
>>>>>>>>
>>>>>>>> test of an already massive patch. Who is going to do this work?
>>>>>>>>>
>>>>>>>>>> Going back to a new branch seems wrong route to take.
>>>>>>>>>>
>>>>>>>>>> St.Ack
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> To be more explicit, this patch was developed on a branch and
>>>>>>>>>> then a
>>>>>>>>>>
>>>>>>>>>> bunch
>>>>>>>>>
>>>>>>>> of dev resources were burned getting it into a state where it could
>>>>>>>> be
>>>>>>>>
>>>>>>>>> merged to master. Going back to a branch to bulk up the merge so it
>>>>>>>>> includes more JIRAs than the many it already incorporates is the
>>>>>>>>> wrong
>>>>>>>>> direction for us to be headed in. It ignores the feedback given and
>>>>>>>>> the
>>>>>>>>> work done by Vladimir slimming down an already over-broad scope. It
>>>>>>>>> is
>>>>>>>>>
>>>>>>>>> also
>>>>>>>>>
>>>>>>>> predicated on abundant review and testing resource being on tap to
>>>>>>>>
>>>>>>>>> cycle
>>>>>>>>>
>>>>>>>> on
>>>>>>>>
>>>>>>>> a feature that is useful, but non-core.
>>>>>>>>
>>>>>>>>> The patch is ready for merge IMO. Geoffrey makes a nice list of
>>>>>>>>> what
>>>>>>>>> is
>>>>>>>>> still to do though IIRC, the list is incomplete because a bunch of
>>>>>>>>> follow-ons came of the review cycle (including moving
>>>>>>>>> backup/restore
>>>>>>>>>
>>>>>>>>> out
>>>>>>>>>
>>>>>>>> of
>>>>>>>>
>>>>>>>> core to live in its own module).
>>>>>>>>
>>>>>>>>> The patch needs three votes to merge. I am not against merge but I
>>>>>>>>> am
>>>>>>>>>
>>>>>>>>> not
>>>>>>>>>
>>>>>>>> voting for the patch because I do have any more time to spend on
>>>>>>>> this
>>>>>>>>
>>>>>>>> non-core feature and feel that a vote will have me assume a
>>>>>>>>>
>>>>>>>>> responsibility
>>>>>>>>>
>>>>>>>> I will not shirk.
>>>>>>>>
>>>>>>>>> S
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> FYI
>>>>>>>>>
>>>>>>>>>> On Fri, Mar 10, 2017 at 3:30 PM, Ted Yu<yu...@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>> 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 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,
>>>>>>>>>>>>
>>>>>>>>>>> we
>>>>>>>>>>
>>>>>>>>> propose to community for merging into branch-2 (master branch, if
>>>>>>>>
>>>>>>>>> branch-2
>>>>>>>>>>
>>>>>>>>>>> doesn't materialize for whatever reason) again
>>>>>>>>>>>
>>>>>>>>>>>> Cheers
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Mar 10, 2017 at 3:01 PM, Andrew Purtell<
>>>>>>>>>>>>
>>>>>>>>>>>> apurtell@apache.org>
>>>>>>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>> 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 the documentation issue is important but not actually a
>>>>>>>>>>>>>
>>>>>>>>>>>>> blocker.
>>>>>>>>>>>>>
>>>>>>>>>>>> That may be a controversial opinion, but documentation can be
>>>>>>>>>>>> back-filled
>>>>>>>>>>>> worst case. So take HBASE-17133 off the list.
>>>>>>>>>>>>
>>>>>>>>>>>> Remaining are effectively HBASE-14417, HBASE-14141, and
>>>>>>>>>>>>>
>>>>>>>>>>>>> HBASE-15227.
>>>>>>>>>>>>>
>>>>>>>>>>>> They
>>>>>>>>>>>
>>>>>>>>>> all have patches attached to the respective JIRAs so completing
>>>>>>>>>>
>>>>>>>>>>> this
>>>>>>>>>>>>
>>>>>>>>>>>> work
>>>>>>>>>>>
>>>>>>>>>> won't be onerous. Get these committed and I will lift my -1. The
>>>>>>>>>>
>>>>>>>>>>> others
>>>>>>>>>>>>
>>>>>>>>>>>> who
>>>>>>>>>>> voted +1 on this thread surely can help with that.
>>>>>>>>>>>
>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, Mar 10, 2017 at 2:32 PM, Vladimir Rodionov<
>>>>>>>>>>>>> vladrodionov@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> No problem I will downgrade Blockers to Majors if it scares
>>>>>>>>>>>>> you,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Andrew
>>>>>>>>>>>>
>>>>>>>>>>> [image: [image: 🙂]]
>>>>>>>>>
>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>
>>>>>>>>>>>>> On Mar 10, 2017, at 1:52 PM, Andrew Purtell<
>>>>>>>>>>>>>> apurtell@apache.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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 prevent that release because these blockers will
>>>>>>>>>>>>>
>>>>>>>>>>>> be
>>>>>>>>>>
>>>>>>>>>>> there. I
>>>>>>>>>>>>>
>>>>>>>>>>>> am
>>>>>>>>>
>>>>>>>>>> inclined to veto. Probably we should not propose branch
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> merges
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> into
>>>>>>>>>>>>>
>>>>>>>>>>>> code
>>>>>>>>>
>>>>>>>>>> we
>>>>>>>>>>>
>>>>>>>>>>>> are trying to get out the door with known blockers. Why not
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> do
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>
>>>>>>>>>>>> work
>>>>>>>>>
>>>>>>>>>> first? It seems an obvious question. Perhaps I am missing
>>>>>>>>>>>
>>>>>>>>>>>> something.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If we can branch for 2.0 now and then merge this, and not
>>>>>>>>>>>>> into
>>>>>>>>>>>>> the
>>>>>>>>>>>>>
>>>>>>>>>>>> 2.0
>>>>>>>>>
>>>>>>>>>> branch, I would vote +1 for branch merge even with known
>>>>>>>>>>>
>>>>>>>>>>>> blockers
>>>>>>>>>>>>> pending.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On Fri, Mar 10, 2017 at 1:42 PM, Vladimir Rodionov<
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> vladrodionov@gmail.com>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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<
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> apurtell@apache.org
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>> 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<
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> vladrodionov@gmail.com>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 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 reviews
>>>>>>>>>>>
>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> has
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> probably
>>>>>>>>>>
>>>>>>>>>>> the most lengthy discussion thread on Apache JIRA
>>>>>>>>>>>>>
>>>>>>>>>>>>>> (HBASE-14123)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> :)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The work has been split into 3 phases (HBASE-14030, 14123,
>>>>>>>>>>>
>>>>>>>>>>>> 14414)
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Two
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> first
>>>>>>>>>>>>>
>>>>>>>>>>>>>> are complete, third one is still in progress.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> *** Summary of work HBASE-14123
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The new feature introduces new command-line extensions to
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> hbase
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> command
>>>>>>>>>>
>>>>>>>>>>> and, from the client side, is accessible through
>>>>>>>>>>>>>
>>>>>>>>>>>>>> command-line
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> only
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Operations:
>>>>>>>>>>
>>>>>>>>>>> * Create full backup on a list of tables or backup set
>>>>>>>>>>>>>
>>>>>>>>>>>>>> * Create incremental backup image for table list or backup
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> set
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> * Restore list of tables from a given backup image
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> * Show current backup progress
>>>>>>>>>>
>>>>>>>>>>> * Delete backup image and all related images
>>>>>>>>>>>>>>>>>> * Show history of backups
>>>>>>>>>>>>>>>>>> * Backup set operations: create backup set, add/remove
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> table
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> to/from
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> backup
>>>>>>>>>
>>>>>>>>>> set, etc
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> In the current implementation, the feature is already
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> usable,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> meaning
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> that
>>>>>>>>>>
>>>>>>>>>>> users can backup tables and restore them using provided
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> command-line
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> tools.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Both: full and incremental backups are supported.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This work is based on original work of IBM team
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> (HBASE-7912).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> full
>>>>>>>>>>
>>>>>>>>>>> list
>>>>>>>>>>>>>
>>>>>>>>>>>>>> of JIRAs included in this mega patch can be found in three
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> umbrella
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> JIRAs:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> HBASE-14030 (Phase 1), HBASE-14123 (Phase 2) and
>>>>>>>>>>>>>
>>>>>>>>>>>>>> HBASE-14414
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> (Phase 3
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -
>>>>>>>>>
>>>>>>>>>> all
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> resolved ones made it into the patch)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> *** What are the remaining work items
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> All remaining items can be found in Phase 3 umbrella JIRA:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> HBASE-14414.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> They are split into 3 groups: BLOCKER, CRITICAL, MAJOR
>>>>>>>>>>>>>>>> Only BLOCKERs and CRITICALs are guaranteed for HBase 2.0
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ***** BLOCKER
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> * HBASE-14417 Incremental backup and bulk loading ( Patch
>>>>>>>>>>>>>
>>>>>>>>>>>>>> available)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> * HBASE-14135 HBase Backup/Restore Phase 3: Merge backup
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> images
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> * HBASE-14141 HBase Backup/Restore Phase 3: Filter WALs on
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> backup
>>>>>>>>>>>
>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> include only edits from backup tables (Patch available)
>>>>>>>>>>>>>
>>>>>>>>>>>>>> * HBASE-17133 Backup documentation
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> * HBASE-15227 Fault tolerance support
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ***** CRITICAL
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> * HBASE-16465 Disable split/merges during backup
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> We have umbrella JIRA (HBASE-14414) to track all the
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> remaining
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> work
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> All the BLOCKER and CRITICAL JIRAs currently in open state
>>>>>>>>>>
>>>>>>>>>>> will
>>>>>>>>>>>>>
>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> implemented by 2.0 release time. Some MAJOR too, but it
>>>>>>>>>>>
>>>>>>>>>>>> depends
>>>>>>>>>>>>>
>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> resource
>>>>>>>>>>>
>>>>>>>>>>>> availability
>>>>>>>>>>>>>
>>>>>>>>>>>>>> The former development branch (HBASE-7912) is obsolete and
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> closed/deleted after the merge.
>>>>>>>>>>>
>>>>>>>>>>>> We want backup to be a GA feature in 2.0
>>>>>>>>>>>>>
>>>>>>>>>>>>>> We are going to support full backward compatibility for
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> backup
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> tool in
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2.0
>>>>>>>>>>
>>>>>>>>>>> and onwards.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> **** Configuration
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Backup is disabled, by default. To enable it, the
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> following
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> configuration
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> properties must be added to hbase-site.xml:
>>>>>>>>>
>>>>>>>>>> hbase.backup.enable=true
>>>>>>>>>>>>>>>>>> hbase.master.logcleaner.plugins=YOUR_PLUGINS,org.
>>>>>>>>>>>>>>>>>> apache.hadoop.hbase.backup.master.BackupLogCleaner
>>>>>>>>>>>>>>>>>> hbase.procedure.master.classes=YOUR_CLASSES,org.
>>>>>>>>>>>>>>>>>> apache.hadoop.hbase.backup.master.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> LogRollMasterProcedureManager
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> hbase.procedure.regionserver.classes=YOUR_CLASSES,org.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> apache.hadoop.hbase.backup.regionserver.
>>>>>>>>>>>
>>>>>>>>>>>> LogRollRegionServerProcedureMa
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> nager
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I would like to thank IBM team and Jerry He for original
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> work,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Enis, Ted, Stack, Matteo, Jerry for time spent on code
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> reviews
>>>>>>>>>>
>>>>>>>>>>> Special thanks to Ted Yu for his co-development work.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> References:
>>>>>>>>>>
>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-7912
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> (original
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> IBM,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> contains
>>>>>>>>>
>>>>>>>>>> design doc)
>>>>>>>>>>>
>>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-14030 (Phase
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 1)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-14123 (Phase
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2)
>>>>>>>>>
>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-14414 (Phase
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 3)
>>>>>>>>>
>>>>>>>>>> Please vote +1/-1 by midnight Pacific Time (00:00
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -0800 GMT) on March 11th on whether or not we should
>>>>>>>>>
>>>>>>>>>> merge
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> into
>>>>>>>>>
>>>>>>>>>> the
>>>>>>>>>>>>>
>>>>>>>>>>>>>> current master.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -Vladimir Rodionov
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> - Andy
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If you are given a choice, you believe you have acted
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> freely. -
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Raymond
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Teller (via Peter Watts)
>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - Andy
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If you are given a choice, you believe you have acted
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> freely. -
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Raymond
>>>>>>>>>>>>>
>>>>>>>>>>>> Teller (via Peter Watts)
>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Andy
>>>>>>>>>>>>>
>>>>>>>>>>>>> If you are given a choice, you believe you have acted freely. -
>>>>>>>>>>>>>
>>>>>>>>>>>>> Raymond
>>>>>>>>>>>>>
>>>>>>>>>>>> Teller (via Peter Watts)
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>>
>>
>>
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
Posted by Josh Elser <el...@apache.org>.
Spent the day playing around with this on 6 nodes.
I've found some rough edges: some known (the docs blocker Vlad pointed
out) and some that I think are unknown (tooling is rough -- partially
from wrong help messages and, I think, changes in design like
Master-submitted MR jobs).
But, Stack's assessment (and Andrew's reminder) that further tweaking
would just throw us back into another review cycle is a real concern.
It's unfortunate that this feature has lingered so long aside of master
to get to this point, but I don't see any realistic resolution to this
problem than a merge. In the future, this is something we'll have to try
harder to avoid letting happen (looking in the mirror with quota work...)
Thankfully, I can help out with development/review on the outstanding
blockers (notably, the two I pruned from Vlad's original of five -- the
other three still seem to be improvements). In addition to these
blockers, I believe the documentation *must* be updated before a release
to note that this feature is still growing -- it does not feel like a
quality feature that I've come to expect from this community. This isn't
a knock on Vlad and company; this is a hard problem and one that I could
not have done better given time constraints, but it is also one that
users will demand simplicity and the utmost correctness around. To this
end, I will also try to help out to smooth out these issues in the
following 2.x release.
So, this leaves me to say: +1 to merge with the caveat that the docs are
updated to make sure that any known, user-pitfalls are clearly
documented. This vote also comes with as real of a promise that I can
make to help avoid any issues with this feature that would prevent a 2.0
release.
Thanks to all the giants whose shoulders I'm standing on to be able to
make this vote.
Andrew Purtell wrote:
> Great, and I changed my vote to -0 because Stack made a good argument that
> making more changes would invalidate review up to this point, and I trust
> this will be resolved before release.
>
> On Tue, Mar 14, 2017 at 4:29 PM, Josh Elser<el...@apache.org> wrote:
>
>> Sorry Andrew, let me clarify as that didn't come out right.
>>
>> I didn't mean that isn't a conversation worth having _now_, just that I
>> was intentionally avoiding it in my previous email because I didn't
>> understand the scope of those issues that Vlad had identified. I wanted to
>> better understand what they were really meant for a user before coming to
>> my own decision about whether or not I think they are blockers.
>>
>> That aside, I would agree with you that HBASE-15227 sounds like a real
>> blocker. Forcing a new full backup for every table sounds really bad --
>> that's not the kind of experience we'd want a user to have.
>>
>> Andrew Purtell wrote:
>>
>>> I'm going to intentional avoid addressing the discussion of shipping
>>> partial features (related, but not relevant at the moment).
>>>
>>> Then we are not having the same conversation, because it is precisely
>>> because this is a vote for this feature to go into 2.0, which is already
>>> overdue, so should be released yesterday, that I took mention of "blocker"
>>> at face value. At least one of them seems to certainly approach this
>>> definition. It will be not user friendly, to say the least, to use this in
>>> a large scale deployment with HBASE-15227 unfinished. HBASE-15227
>>> currently
>>> has a severity of BLOCKER. Despite what is going on in our politics, words
>>> matter and we do not get to redefine them for convenience.
>>>
>>> Once this work is merged in, how is HBASE-15227 not a blocker for 2.0?
>>> Because Vlad offered to reduce its severity to make me feel better?
>>> Currently the description on the issue is "System must be tolerant to
>>> faults. Backup operations MUST be atomic (no partial completion state in
>>> system table)" Sounds like a blocker to me, indeed. It is an honest
>>> assessment and I don't think anyone is doing the community a favor by
>>> trying to walk that back.
>>>
>>>
>>> On Tue, Mar 14, 2017 at 1:57 PM, Josh Elser<el...@apache.org> wrote:
>>>
>>> I took a moment to read through the "blockers" as originally identified by
>>>> Vlad, and (to echo Enis' take) I read the majority of them as being
>>>> blockers not for the next release, but for a "full-fledged feature". I'm
>>>> going to intentional avoid addressing the discussion of shipping partial
>>>> features (related, but not relevant at the moment).
>>>>
>>>> HBASE-15227 is actually the one that bothers me the most, with
>>>> HBASE-17133
>>>> coming in close behind. Vlad, is there any documentation you can point me
>>>> to about what the current issues are with the current implementation? For
>>>> example, what happens now if the system has some kind of "partial
>>>> completion state"?
>>>>
>>>> Documentation is one of those that is really hard to judge. We want to
>>>> get
>>>> this code out for people to use (and to free up our strained dev
>>>> resources), but what good is some feature if the docs are
>>>> missing/incomplete?
>>>>
>>>> I think I could stomach the docs being inaccurate (with a clear
>>>> disclaimer
>>>> that the chapter is incomplete -- that's a 5min task). But, I think I
>>>> need
>>>> an answer about how the feature handles our common dist-sys category of
>>>> problems 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
>>>> problem as an (ignorant) user ;)
>>>>
>>>>
>>>> Andrew Purtell wrote:
>>>>
>>>> I don't like that issues were identified as "blockers" but now there is
>>>>> an
>>>>> attempt to walk that back.
>>>>>
>>>>> I don't like that development of this feature has lingered for a long
>>>>> time
>>>>> in this unfinished state when this work could have been done by now, now
>>>>> 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 look at the current state and be nonplussed. This will be yet
>>>>> another half finished thing in 2.0 when this merge happens. Promises to
>>>>> finish the unfinished work are nice but not 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 2.0 release to slip
>>>>> further.
>>>>>
>>>>> Also, marking something experimental should be done on the merits of
>>>>> that
>>>>> evaluation, not simply to justify dropping unfinished work into a
>>>>> release
>>>>> branch.
>>>>>
>>>>> I will change my vote to -0.
>>>>>
>>>>>
>>>>> On Mon, Mar 13, 2017 at 4:05 PM, Enis S�ztutar<en...@apache.org>
>>>>> wrote:
>>>>>
>>>>> I think there is some misconception of using the term "blockers" for
>>>>>
>>>>>> referring to those jiras. My understanding is that those three jiras
>>>>>> are
>>>>>> blockers for the backup functionality to be more mature and more
>>>>>> usable.
>>>>>> But they are not release blockers. Let's say we merged the code in, and
>>>>>> for
>>>>>> some reason those did not get addressed in time. We can still do the
>>>>>> 2.0
>>>>>> release without having to wait for the commits. We can instead mark the
>>>>>> "backup" feature as experimental with known issues and go on with the
>>>>>> release. In that sense they are not real release 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
>>>>>> luxury of having to wait another couple of months and doing yet another
>>>>>> giant round of reviews because the code base is a moving target.
>>>>>>
>>>>>> Enis
>>>>>>
>>>>>> On Mon, Mar 13, 2017 at 3:46 PM, Devaraj Das<dd...@hortonworks.com>
>>>>>> 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 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 to make the list of remaining work more complete by
>>>>>>> citing
>>>>>> that as pending work.
>>>>>>> ________________________________________
>>>>>>> From: Vladimir Rodionov<vl...@gmail.com>
>>>>>>> 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 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 (including moving backup/restore
>>>>>>>>> out
>>>>>>> of
>>>>>>>
>>>>>>> core to live in its own module).
>>>>>>>> For those who were not following our lengthy conversation on a review
>>>>>>>>
>>>>>>> board, separation of a backup code into a separate module has been
>>>>>>> done last year, but has been reverted back by request of a reviewer.
>>>>>>>
>>>>>>>
>>>>>>> -Vladimir
>>>>>>>
>>>>>>> On Mon, Mar 13, 2017 at 2:23 PM, Stack<st...@duboce.net> wrote:
>>>>>>>
>>>>>>> On Fri, Mar 10, 2017 at 9:09 PM, Stack<st...@duboce.net> wrote:
>>>>>>>
>>>>>>>> On Fri, Mar 10, 2017 at 6:01 PM, Ted Yu<yu...@gmail.com>
>>>>>>>> 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 burned a bunch of dev resource).
>>>>>>>>> The patch as is is now in a state where it is too big for our infra;
>>>>>>>>>
>>>>>>>>> rb
>>>>>>> and JIRA are creaking under the size and # of iterations.
>>>>>>>
>>>>>>>> Adding finish of new JIRAs to this merge implies a new round of
>>>>>>>>> review
>>>>>>> and
>>>>>>>
>>>>>>>> test of an already massive patch. Who is going to do this work?
>>>>>>>>> Going back to a new branch seems wrong route to take.
>>>>>>>>>
>>>>>>>>> St.Ack
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> To be more explicit, this patch was developed on a branch and then a
>>>>>>>>>
>>>>>>>> bunch
>>>>>>> of dev resources were burned getting it into a state where it could be
>>>>>>>> merged to master. Going back to a branch to bulk up the merge so it
>>>>>>>> includes more JIRAs than the many it already incorporates is the
>>>>>>>> wrong
>>>>>>>> direction for us to be headed in. It ignores the feedback given and
>>>>>>>> the
>>>>>>>> work done by Vladimir slimming down an already over-broad scope. It
>>>>>>>> is
>>>>>>>>
>>>>>>>> also
>>>>>>> predicated on abundant review and testing resource being on tap to
>>>>>>>> cycle
>>>>>>> on
>>>>>>>
>>>>>>> a feature that is useful, but non-core.
>>>>>>>> The patch is ready for merge IMO. Geoffrey makes a nice list of what
>>>>>>>> is
>>>>>>>> still to do though IIRC, the list is incomplete because a bunch of
>>>>>>>> follow-ons came of the review cycle (including moving backup/restore
>>>>>>>>
>>>>>>>> out
>>>>>>> of
>>>>>>>
>>>>>>> core to live in its own module).
>>>>>>>> The patch needs three votes to merge. I am not against merge but I am
>>>>>>>>
>>>>>>>> not
>>>>>>> voting for the patch because I do have any more time to spend on this
>>>>>>>
>>>>>>>> non-core feature and feel that a vote will have me assume a
>>>>>>>>
>>>>>>>> responsibility
>>>>>>> I will not shirk.
>>>>>>>> S
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> FYI
>>>>>>>>>> On Fri, Mar 10, 2017 at 3:30 PM, Ted Yu<yu...@gmail.com>
>>>>>>>>>>
>>>>>>>>>> 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 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,
>>>>>>>>> we
>>>>>>> propose to community for merging into branch-2 (master branch, if
>>>>>>>>> branch-2
>>>>>>>>>> doesn't materialize for whatever reason) again
>>>>>>>>>>> Cheers
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Mar 10, 2017 at 3:01 PM, Andrew Purtell<
>>>>>>>>>>>
>>>>>>>>>>> apurtell@apache.org>
>>>>>>>>> wrote:
>>>>>>>>> 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 the documentation issue is important but not actually a
>>>>>>>>>>>>
>>>>>>>>>>>> blocker.
>>>>>>>>>>> That may be a controversial opinion, but documentation can be
>>>>>>>>>>> back-filled
>>>>>>>>>>> worst case. So take HBASE-17133 off the list.
>>>>>>>>>>>
>>>>>>>>>>>> Remaining are effectively HBASE-14417, HBASE-14141, and
>>>>>>>>>>>>
>>>>>>>>>>>> HBASE-15227.
>>>>>>>>>> They
>>>>>>>>> all have patches attached to the respective JIRAs so completing
>>>>>>>>>>> this
>>>>>>>>>>>
>>>>>>>>>> work
>>>>>>>>> won't be onerous. Get these committed and I will lift my -1. The
>>>>>>>>>>> others
>>>>>>>>>>>
>>>>>>>>>> who
>>>>>>>>>> voted +1 on this thread surely can help with that.
>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Mar 10, 2017 at 2:32 PM, Vladimir Rodionov<
>>>>>>>>>>>> vladrodionov@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> No problem I will downgrade Blockers to Majors if it scares
>>>>>>>>>>>> you,
>>>>>>>>>>>>
>>>>>>>>>>> Andrew
>>>>>>>> [image: [image: \U0001f642]]
>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>> On Mar 10, 2017, at 1:52 PM, Andrew Purtell<
>>>>>>>>>>>>> apurtell@apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>> wrote:
>>>>>>>>> \u200bI 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 prevent that release because these blockers will
>>>>>>>>> be
>>>>>>>>>>>> there. I
>>>>>>>> am
>>>>>>>>>>>>> inclined to veto. Probably we should not propose branch
>>>>>>>>>>>>>> merges
>>>>>>>>>>>> into
>>>>>>>> code
>>>>>>>>>> we
>>>>>>>>>>>>> are trying to get out the door with known blockers. Why not
>>>>>>>>>>>>>> do
>>>>>>>>>>>> that
>>>>>>>> work
>>>>>>>>>> first? It seems an obvious question. Perhaps I am missing
>>>>>>>>>>>>> something.
>>>>>>>>>>>>>
>>>>>>>>>>>> If we can branch for 2.0 now and then merge this, and not
>>>>>>>>>>>> into
>>>>>>>>>>>> the
>>>>>>>> 2.0
>>>>>>>>>> branch, I would vote +1 for branch merge even with known
>>>>>>>>>>>> blockers
>>>>>>>>>>>> pending.
>>>>>>>>> \u200b
>>>>>>>>>>>>>> On Fri, Mar 10, 2017 at 1:42 PM, Vladimir Rodionov<
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> vladrodionov@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 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<
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> apurtell@apache.org
>>>>>>>>>>>>> wrote:
>>>>>>>>>> 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<
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> vladrodionov@gmail.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> 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 reviews
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> has
>>>>>>>>> probably
>>>>>>>>>>>> the most lengthy discussion thread on Apache JIRA
>>>>>>>>>>>>>>>> (HBASE-14123)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> :)
>>>>>>>>>> The work has been split into 3 phases (HBASE-14030, 14123,
>>>>>>>>>>>> 14414)
>>>>>>>>>>>>>>> Two
>>>>>>>>>>>> first
>>>>>>>>>>>>>> are complete, third one is still in progress.
>>>>>>>>>>>>>>>>> *** Summary of work HBASE-14123
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The new feature introduces new command-line extensions to
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> hbase
>>>>>>>>> command
>>>>>>>>>>>> and, from the client side, is accessible through
>>>>>>>>>>>>>>>> command-line
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> only
>>>>>>>>> Operations:
>>>>>>>>>>>> * Create full backup on a list of tables or backup set
>>>>>>>>>>>>>>>>> * Create incremental backup image for table list or backup
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> set
>>>>>>>>>>>>>>> * Restore list of tables from a given backup image
>>>>>>>>> * Show current backup progress
>>>>>>>>>>>>>>>>> * Delete backup image and all related images
>>>>>>>>>>>>>>>>> * Show history of backups
>>>>>>>>>>>>>>>>> * Backup set operations: create backup set, add/remove
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> table
>>>>>>>>>>>>>>> to/from
>>>>>>>> backup
>>>>>>>>>>>>>> set, etc
>>>>>>>>>>>>>>>>> In the current implementation, the feature is already
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> usable,
>>>>>>>>>>>>>>> meaning
>>>>>>>>> that
>>>>>>>>>>>>>> users can backup tables and restore them using provided
>>>>>>>>>>>>>>>> command-line
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> tools.
>>>>>>>>>>>>>> Both: full and incremental backups are supported.
>>>>>>>>>>>>>>>>> This work is based on original work of IBM team
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> (HBASE-7912).
>>>>>>>>>>>>>>> The
>>>>>>>>> full
>>>>>>>>>>>> list
>>>>>>>>>>>>>> of JIRAs included in this mega patch can be found in three
>>>>>>>>>>>>>>>> umbrella
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> JIRAs:
>>>>>>>>>>>> HBASE-14030 (Phase 1), HBASE-14123 (Phase 2) and
>>>>>>>>>>>>>>>> HBASE-14414
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> (Phase 3
>>>>>>>> -
>>>>>>>>>>>>> all
>>>>>>>>>>>>>>> resolved ones made it into the patch)
>>>>>>>>>>>>>>>>> *** What are the remaining work items
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> All remaining items can be found in Phase 3 umbrella JIRA:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> HBASE-14414.
>>>>>>>>>>>>>>> They are split into 3 groups: BLOCKER, CRITICAL, MAJOR
>>>>>>>>>>>>>>> Only BLOCKERs and CRITICALs are guaranteed for HBase 2.0
>>>>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>> ***** BLOCKER
>>>>>>>>>>>> * HBASE-14417 Incremental backup and bulk loading ( Patch
>>>>>>>>>>>>>>>>> available)
>>>>>>>>>>>>>>> * HBASE-14135 HBase Backup/Restore Phase 3: Merge backup
>>>>>>>>>>>>>> images
>>>>>>>>>>>>>>> * HBASE-14141 HBase Backup/Restore Phase 3: Filter WALs on
>>>>>>>>>> backup
>>>>>>>>>>>>>>> to
>>>>>>>>>>>> include only edits from backup tables (Patch available)
>>>>>>>>>>>>>> * HBASE-17133 Backup documentation
>>>>>>>>>>>>>>>>> * HBASE-15227 Fault tolerance support
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ***** CRITICAL
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> * HBASE-16465 Disable split/merges during backup
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> We have umbrella JIRA (HBASE-14414) to track all the
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> remaining
>>>>>>>>>>>>>>> work
>>>>>>>>> All the BLOCKER and CRITICAL JIRAs currently in open state
>>>>>>>>>>>> will
>>>>>>>>>>>>>>> be
>>>>>>>>>> implemented by 2.0 release time. Some MAJOR too, but it
>>>>>>>>>>>> depends
>>>>>>>>>>>>>>> on
>>>>>>>>>> resource
>>>>>>>>>>>> availability
>>>>>>>>>>>>>>>>> The former development branch (HBASE-7912) is obsolete and
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>> be
>>>>>>>>>> closed/deleted after the merge.
>>>>>>>>>>>> We want backup to be a GA feature in 2.0
>>>>>>>>>>>>>>>>> We are going to support full backward compatibility for
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> backup
>>>>>>>>>>>>>>> tool in
>>>>>>>>> 2.0
>>>>>>>>>>>>>> and onwards.
>>>>>>>>>>>>>>>>> **** Configuration
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Backup is disabled, by default. To enable it, the
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> following
>>>>>>>>>>>>>>> configuration
>>>>>>>> properties must be added to hbase-site.xml:
>>>>>>>>>>>>>>>>> hbase.backup.enable=true
>>>>>>>>>>>>>>>>> hbase.master.logcleaner.plugins=YOUR_PLUGINS,org.
>>>>>>>>>>>>>>>>> apache.hadoop.hbase.backup.master.BackupLogCleaner
>>>>>>>>>>>>>>>>> hbase.procedure.master.classes=YOUR_CLASSES,org.
>>>>>>>>>>>>>>>>> apache.hadoop.hbase.backup.master.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> LogRollMasterProcedureManager
>>>>>>>>>>>>>>> hbase.procedure.regionserver.classes=YOUR_CLASSES,org.
>>>>>>>>>> apache.hadoop.hbase.backup.regionserver.
>>>>>>>>>>>>>>>>> LogRollRegionServerProcedureMa
>>>>>>>>>>>>>>> nager
>>>>>>>>>>>>>>>>> I would like to thank IBM team and Jerry He for original
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> work,
>>>>>>>>>>>>>>> Enis, Ted, Stack, Matteo, Jerry for time spent on code
>>>>>>>>> reviews
>>>>>>>>>>>>>>> Special thanks to Ted Yu for his co-development work.
>>>>>>>>> References:
>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-7912
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> (original
>>>>>>>>>>>>>>> IBM,
>>>>>>>> contains
>>>>>>>>>> design doc)
>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-14030 (Phase
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 1)
>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-14123 (Phase
>>>>>>>> 2)
>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-14414 (Phase
>>>>>>>> 3)
>>>>>>>>>>>>>>> Please vote +1/-1 by midnight Pacific Time (00:00
>>>>>>>> -0800 GMT) on March 11th \u200bon whether or not we should
>>>>>>>>>>>>>>>>> merge
>>>>>>>>>>>>>>> this
>>>>>>>> into
>>>>>>>>>>>> the
>>>>>>>>>>>>>> current master.
>>>>>>>>>>>>>>>>> -Vladimir Rodionov
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> - Andy
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If you are given a choice, you believe you have acted
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> freely. -
>>>>>>>>>>>>>> Raymond
>>>>>>>>> Teller (via Peter Watts)
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - Andy
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If you are given a choice, you believe you have acted
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> freely. -
>>>>>>>>>>>> Raymond
>>>>>>>> Teller (via Peter Watts)
>>>>>>>>>>>> --
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>
>>>>>>>>>>>> - Andy
>>>>>>>>>>>>
>>>>>>>>>>>> If you are given a choice, you believe you have acted freely. -
>>>>>>>>>>>>
>>>>>>>>>>>> Raymond
>>>>>>>>>> Teller (via Peter Watts)
>>>>>
>>>
>
>
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
Posted by Andrew Purtell <ap...@apache.org>.
Great, and I changed my vote to -0 because Stack made a good argument that
making more changes would invalidate review up to this point, and I trust
this will be resolved before release.
On Tue, Mar 14, 2017 at 4:29 PM, Josh Elser <el...@apache.org> wrote:
> Sorry Andrew, let me clarify as that didn't come out right.
>
> I didn't mean that isn't a conversation worth having _now_, just that I
> was intentionally avoiding it in my previous email because I didn't
> understand the scope of those issues that Vlad had identified. I wanted to
> better understand what they were really meant for a user before coming to
> my own decision about whether or not I think they are blockers.
>
> That aside, I would agree with you that HBASE-15227 sounds like a real
> blocker. Forcing a new full backup for every table sounds really bad --
> that's not the kind of experience we'd want a user to have.
>
> Andrew Purtell wrote:
>
>> I'm going to intentional avoid addressing the discussion of shipping
>>>
>> partial features (related, but not relevant at the moment).
>>
>> Then we are not having the same conversation, because it is precisely
>> because this is a vote for this feature to go into 2.0, which is already
>> overdue, so should be released yesterday, that I took mention of "blocker"
>> at face value. At least one of them seems to certainly approach this
>> definition. It will be not user friendly, to say the least, to use this in
>> a large scale deployment with HBASE-15227 unfinished. HBASE-15227
>> currently
>> has a severity of BLOCKER. Despite what is going on in our politics, words
>> matter and we do not get to redefine them for convenience.
>>
>> Once this work is merged in, how is HBASE-15227 not a blocker for 2.0?
>> Because Vlad offered to reduce its severity to make me feel better?
>> Currently the description on the issue is "System must be tolerant to
>> faults. Backup operations MUST be atomic (no partial completion state in
>> system table)" Sounds like a blocker to me, indeed. It is an honest
>> assessment and I don't think anyone is doing the community a favor by
>> trying to walk that back.
>>
>>
>> On Tue, Mar 14, 2017 at 1:57 PM, Josh Elser<el...@apache.org> wrote:
>>
>> I took a moment to read through the "blockers" as originally identified by
>>> Vlad, and (to echo Enis' take) I read the majority of them as being
>>> blockers not for the next release, but for a "full-fledged feature". I'm
>>> going to intentional avoid addressing the discussion of shipping partial
>>> features (related, but not relevant at the moment).
>>>
>>> HBASE-15227 is actually the one that bothers me the most, with
>>> HBASE-17133
>>> coming in close behind. Vlad, is there any documentation you can point me
>>> to about what the current issues are with the current implementation? For
>>> example, what happens now if the system has some kind of "partial
>>> completion state"?
>>>
>>> Documentation is one of those that is really hard to judge. We want to
>>> get
>>> this code out for people to use (and to free up our strained dev
>>> resources), but what good is some feature if the docs are
>>> missing/incomplete?
>>>
>>> I think I could stomach the docs being inaccurate (with a clear
>>> disclaimer
>>> that the chapter is incomplete -- that's a 5min task). But, I think I
>>> need
>>> an answer about how the feature handles our common dist-sys category of
>>> problems 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
>>> problem as an (ignorant) user ;)
>>>
>>>
>>> Andrew Purtell wrote:
>>>
>>> I don't like that issues were identified as "blockers" but now there is
>>>> an
>>>> attempt to walk that back.
>>>>
>>>> I don't like that development of this feature has lingered for a long
>>>> time
>>>> in this unfinished state when this work could have been done by now, now
>>>> 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 look at the current state and be nonplussed. This will be yet
>>>> another half finished thing in 2.0 when this merge happens. Promises to
>>>> finish the unfinished work are nice but not 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 2.0 release to slip
>>>> further.
>>>>
>>>> Also, marking something experimental should be done on the merits of
>>>> that
>>>> evaluation, not simply to justify dropping unfinished work into a
>>>> release
>>>> branch.
>>>>
>>>> I will change my vote to -0.
>>>>
>>>>
>>>> On Mon, Mar 13, 2017 at 4:05 PM, Enis Söztutar<en...@apache.org>
>>>> wrote:
>>>>
>>>> I think there is some misconception of using the term "blockers" for
>>>>
>>>>> referring to those jiras. My understanding is that those three jiras
>>>>> are
>>>>> blockers for the backup functionality to be more mature and more
>>>>> usable.
>>>>> But they are not release blockers. Let's say we merged the code in, and
>>>>> for
>>>>> some reason those did not get addressed in time. We can still do the
>>>>> 2.0
>>>>> release without having to wait for the commits. We can instead mark the
>>>>> "backup" feature as experimental with known issues and go on with the
>>>>> release. In that sense they are not real release 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
>>>>> luxury of having to wait another couple of months and doing yet another
>>>>> giant round of reviews because the code base is a moving target.
>>>>>
>>>>> Enis
>>>>>
>>>>> On Mon, Mar 13, 2017 at 3:46 PM, Devaraj Das<dd...@hortonworks.com>
>>>>> 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 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 to make the list of remaining work more complete by
>>>>>>
>>>>>> citing
>>>>>
>>>>> that as pending work.
>>>>>> ________________________________________
>>>>>> From: Vladimir Rodionov<vl...@gmail.com>
>>>>>> 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 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 (including moving backup/restore
>>>>>>>>
>>>>>>>> out
>>>>>>>
>>>>>> of
>>>>>>
>>>>>> core to live in its own module).
>>>>>>> For those who were not following our lengthy conversation on a review
>>>>>>>
>>>>>> board, separation of a backup code into a separate module has been
>>>>>> done last year, but has been reverted back by request of a reviewer.
>>>>>>
>>>>>>
>>>>>> -Vladimir
>>>>>>
>>>>>> On Mon, Mar 13, 2017 at 2:23 PM, Stack<st...@duboce.net> wrote:
>>>>>>
>>>>>> On Fri, Mar 10, 2017 at 9:09 PM, Stack<st...@duboce.net> wrote:
>>>>>>
>>>>>>> On Fri, Mar 10, 2017 at 6:01 PM, Ted Yu<yu...@gmail.com>
>>>>>>> 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 burned a bunch of dev resource).
>>>>>>>>
>>>>>>>> The patch as is is now in a state where it is too big for our infra;
>>>>>>>>
>>>>>>>> rb
>>>>>>>
>>>>>> and JIRA are creaking under the size and # of iterations.
>>>>>>
>>>>>>> Adding finish of new JIRAs to this merge implies a new round of
>>>>>>>>
>>>>>>>> review
>>>>>>>
>>>>>> and
>>>>>>
>>>>>>> test of an already massive patch. Who is going to do this work?
>>>>>>>>
>>>>>>>> Going back to a new branch seems wrong route to take.
>>>>>>>>
>>>>>>>> St.Ack
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> To be more explicit, this patch was developed on a branch and then a
>>>>>>>>
>>>>>>> bunch
>>>>>>
>>>>>> of dev resources were burned getting it into a state where it could be
>>>>>>> merged to master. Going back to a branch to bulk up the merge so it
>>>>>>> includes more JIRAs than the many it already incorporates is the
>>>>>>> wrong
>>>>>>> direction for us to be headed in. It ignores the feedback given and
>>>>>>> the
>>>>>>> work done by Vladimir slimming down an already over-broad scope. It
>>>>>>> is
>>>>>>>
>>>>>>> also
>>>>>>
>>>>>> predicated on abundant review and testing resource being on tap to
>>>>>>>
>>>>>>> cycle
>>>>>> on
>>>>>>
>>>>>> a feature that is useful, but non-core.
>>>>>>>
>>>>>>> The patch is ready for merge IMO. Geoffrey makes a nice list of what
>>>>>>> is
>>>>>>> still to do though IIRC, the list is incomplete because a bunch of
>>>>>>> follow-ons came of the review cycle (including moving backup/restore
>>>>>>>
>>>>>>> out
>>>>>> of
>>>>>>
>>>>>> core to live in its own module).
>>>>>>>
>>>>>>> The patch needs three votes to merge. I am not against merge but I am
>>>>>>>
>>>>>>> not
>>>>>> voting for the patch because I do have any more time to spend on this
>>>>>>
>>>>>>> non-core feature and feel that a vote will have me assume a
>>>>>>>
>>>>>>> responsibility
>>>>>>
>>>>>> I will not shirk.
>>>>>>>
>>>>>>> S
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> FYI
>>>>>>>>
>>>>>>>>> On Fri, Mar 10, 2017 at 3:30 PM, Ted Yu<yu...@gmail.com>
>>>>>>>>>
>>>>>>>>> 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 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,
>>>>>>>>>
>>>>>>>> we
>>>>>>
>>>>>> propose to community for merging into branch-2 (master branch, if
>>>>>>>
>>>>>>>> branch-2
>>>>>>>>>
>>>>>>>>> doesn't materialize for whatever reason) again
>>>>>>>>>>
>>>>>>>>>> Cheers
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Mar 10, 2017 at 3:01 PM, Andrew Purtell<
>>>>>>>>>>
>>>>>>>>>> apurtell@apache.org>
>>>>>>>>>
>>>>>>>> wrote:
>>>>>>>
>>>>>>>> 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 the documentation issue is important but not actually a
>>>>>>>>>>>
>>>>>>>>>>> blocker.
>>>>>>>>>> That may be a controversial opinion, but documentation can be
>>>>>>>>>> back-filled
>>>>>>>>>> worst case. So take HBASE-17133 off the list.
>>>>>>>>>>
>>>>>>>>>>> Remaining are effectively HBASE-14417, HBASE-14141, and
>>>>>>>>>>>
>>>>>>>>>>> HBASE-15227.
>>>>>>>>>>
>>>>>>>>> They
>>>>>>>
>>>>>>>> all have patches attached to the respective JIRAs so completing
>>>>>>>>>> this
>>>>>>>>>>
>>>>>>>>> work
>>>>>>>
>>>>>>>> won't be onerous. Get these committed and I will lift my -1. The
>>>>>>>>>> others
>>>>>>>>>>
>>>>>>>>> who
>>>>>>>>
>>>>>>>>> voted +1 on this thread surely can help with that.
>>>>>>>>>>>
>>>>>>>>>>> Thanks.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Mar 10, 2017 at 2:32 PM, Vladimir Rodionov<
>>>>>>>>>>> vladrodionov@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> No problem I will downgrade Blockers to Majors if it scares
>>>>>>>>>>> you,
>>>>>>>>>>>
>>>>>>>>>> Andrew
>>>>>>
>>>>>>> [image: [image: 🙂]]
>>>>>>>>>>
>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>
>>>>>>>>>>>> On Mar 10, 2017, at 1:52 PM, Andrew Purtell<
>>>>>>>>>>>> apurtell@apache.org
>>>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>> 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 prevent that release because these blockers will
>>>>>>>
>>>>>>>> be
>>>>>>>>>>>>
>>>>>>>>>>> there. I
>>>>>>
>>>>>>> am
>>>>>>>>>>>>
>>>>>>>>>>>> inclined to veto. Probably we should not propose branch
>>>>>>>>>>>>>
>>>>>>>>>>>>> merges
>>>>>>>>>>>>
>>>>>>>>>>> into
>>>>>>
>>>>>>> code
>>>>>>>>
>>>>>>>>> we
>>>>>>>>>>>>
>>>>>>>>>>>> are trying to get out the door with known blockers. Why not
>>>>>>>>>>>>>
>>>>>>>>>>>>> do
>>>>>>>>>>>>
>>>>>>>>>>> that
>>>>>>
>>>>>>> work
>>>>>>>>
>>>>>>>>> first? It seems an obvious question. Perhaps I am missing
>>>>>>>>>>>> something.
>>>>>>>>>>>>
>>>>>>>>>>> If we can branch for 2.0 now and then merge this, and not
>>>>>>>>>>
>>>>>>>>>>> into
>>>>>>>>>>>>
>>>>>>>>>>> the
>>>>>>
>>>>>>> 2.0
>>>>>>>>
>>>>>>>>> branch, I would vote +1 for branch merge even with known
>>>>>>>>>>
>>>>>>>>>>> blockers
>>>>>>>>>>>>
>>>>>>>>>>> pending.
>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, Mar 10, 2017 at 1:42 PM, Vladimir Rodionov<
>>>>>>>>>>>>>
>>>>>>>>>>>>> vladrodionov@gmail.com>
>>>>>>>>>>>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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<
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> apurtell@apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> 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<
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> vladrodionov@gmail.com>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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 reviews
>>>>>>>>>>>>>
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> has
>>>>>>>
>>>>>>>> probably
>>>>>>>>>>
>>>>>>>>>>> the most lengthy discussion thread on Apache JIRA
>>>>>>>>>>>>>>> (HBASE-14123)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> :)
>>>>>>>>
>>>>>>>>> The work has been split into 3 phases (HBASE-14030, 14123,
>>>>>>>>>>
>>>>>>>>>>> 14414)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Two
>>>>>>>>>>
>>>>>>>>>>> first
>>>>>>>>>>>>
>>>>>>>>>>>>> are complete, third one is still in progress.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> *** Summary of work HBASE-14123
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The new feature introduces new command-line extensions to
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> hbase
>>>>>>>
>>>>>>>> command
>>>>>>>>>>
>>>>>>>>>>> and, from the client side, is accessible through
>>>>>>>>>>>>>>> command-line
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> only
>>>>>>>
>>>>>>>> Operations:
>>>>>>>>>>
>>>>>>>>>>> * Create full backup on a list of tables or backup set
>>>>>>>>>>>>>>>> * Create incremental backup image for table list or backup
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> set
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> * Restore list of tables from a given backup image
>>>>>>>
>>>>>>>> * Show current backup progress
>>>>>>>>>>>>>>>> * Delete backup image and all related images
>>>>>>>>>>>>>>>> * Show history of backups
>>>>>>>>>>>>>>>> * Backup set operations: create backup set, add/remove
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> table
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> to/from
>>>>>>
>>>>>>> backup
>>>>>>>>>>>>
>>>>>>>>>>>>> set, etc
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> In the current implementation, the feature is already
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> usable,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> meaning
>>>>>>>
>>>>>>>> that
>>>>>>>>>>>>
>>>>>>>>>>>>> users can backup tables and restore them using provided
>>>>>>>>>>>>>>> command-line
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> tools.
>>>>>>>>>>>>
>>>>>>>>>>>>> Both: full and incremental backups are supported.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This work is based on original work of IBM team
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> (HBASE-7912).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The
>>>>>>>
>>>>>>>> full
>>>>>>>>>>
>>>>>>>>>>> list
>>>>>>>>>>>>
>>>>>>>>>>>>> of JIRAs included in this mega patch can be found in three
>>>>>>>>>>>>>>> umbrella
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> JIRAs:
>>>>>>>>>>
>>>>>>>>>>> HBASE-14030 (Phase 1), HBASE-14123 (Phase 2) and
>>>>>>>>>>>>>>> HBASE-14414
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> (Phase 3
>>>>>>
>>>>>>> -
>>>>>>>>>>>>
>>>>>>>>>>>> all
>>>>>>>>>>>>>
>>>>>>>>>>>>>> resolved ones made it into the patch)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> *** What are the remaining work items
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> All remaining items can be found in Phase 3 umbrella JIRA:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> HBASE-14414.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> They are split into 3 groups: BLOCKER, CRITICAL, MAJOR
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Only BLOCKERs and CRITICALs are guaranteed for HBase 2.0
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ***** BLOCKER
>>>>>>>>>>
>>>>>>>>>>> * HBASE-14417 Incremental backup and bulk loading ( Patch
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> available)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> * HBASE-14135 HBase Backup/Restore Phase 3: Merge backup
>>>>>>>>>>>>
>>>>>>>>>>>>> images
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> * HBASE-14141 HBase Backup/Restore Phase 3: Filter WALs on
>>>>>>>>
>>>>>>>>> backup
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> to
>>>>>>>>>>
>>>>>>>>>>> include only edits from backup tables (Patch available)
>>>>>>>>>>>>
>>>>>>>>>>>>> * HBASE-17133 Backup documentation
>>>>>>>>>>>>>>>> * HBASE-15227 Fault tolerance support
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ***** CRITICAL
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> * HBASE-16465 Disable split/merges during backup
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> We have umbrella JIRA (HBASE-14414) to track all the
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> remaining
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> work
>>>>>>>
>>>>>>>> All the BLOCKER and CRITICAL JIRAs currently in open state
>>>>>>>>>>
>>>>>>>>>>> will
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> be
>>>>>>>>
>>>>>>>>> implemented by 2.0 release time. Some MAJOR too, but it
>>>>>>>>>>
>>>>>>>>>>> depends
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> on
>>>>>>>>
>>>>>>>>> resource
>>>>>>>>>>
>>>>>>>>>>> availability
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The former development branch (HBASE-7912) is obsolete and
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> be
>>>>>>>>
>>>>>>>>> closed/deleted after the merge.
>>>>>>>>>>
>>>>>>>>>>> We want backup to be a GA feature in 2.0
>>>>>>>>>>>>>>>> We are going to support full backward compatibility for
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> backup
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> tool in
>>>>>>>
>>>>>>>> 2.0
>>>>>>>>>>>>
>>>>>>>>>>>>> and onwards.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> **** Configuration
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Backup is disabled, by default. To enable it, the
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> following
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> configuration
>>>>>>
>>>>>>> properties must be added to hbase-site.xml:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> hbase.backup.enable=true
>>>>>>>>>>>>>>>> hbase.master.logcleaner.plugins=YOUR_PLUGINS,org.
>>>>>>>>>>>>>>>> apache.hadoop.hbase.backup.master.BackupLogCleaner
>>>>>>>>>>>>>>>> hbase.procedure.master.classes=YOUR_CLASSES,org.
>>>>>>>>>>>>>>>> apache.hadoop.hbase.backup.master.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> LogRollMasterProcedureManager
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> hbase.procedure.regionserver.classes=YOUR_CLASSES,org.
>>>>>>>>
>>>>>>>>> apache.hadoop.hbase.backup.regionserver.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> LogRollRegionServerProcedureMa
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> nager
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I would like to thank IBM team and Jerry He for original
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> work,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Enis, Ted, Stack, Matteo, Jerry for time spent on code
>>>>>>>
>>>>>>>> reviews
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Special thanks to Ted Yu for his co-development work.
>>>>>>>
>>>>>>>> References:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-7912
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> (original
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> IBM,
>>>>>>
>>>>>>> contains
>>>>>>>>
>>>>>>>>> design doc)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-14030 (Phase
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 1)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-14123 (Phase
>>>>>>
>>>>>>> 2)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-14414 (Phase
>>>>>>
>>>>>>> 3)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please vote +1/-1 by midnight Pacific Time (00:00
>>>>>>
>>>>>>> -0800 GMT) on March 11th on whether or not we should
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> merge
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> this
>>>>>>
>>>>>>> into
>>>>>>>>>>
>>>>>>>>>>> the
>>>>>>>>>>>>
>>>>>>>>>>>>> current master.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -Vladimir Rodionov
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - Andy
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If you are given a choice, you believe you have acted
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> freely. -
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Raymond
>>>>>>>
>>>>>>>> Teller (via Peter Watts)
>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Andy
>>>>>>>>>>>>>
>>>>>>>>>>>>> If you are given a choice, you believe you have acted
>>>>>>>>>>>>>
>>>>>>>>>>>>> freely. -
>>>>>>>>>>>>
>>>>>>>>>>> Raymond
>>>>>>
>>>>>>> Teller (via Peter Watts)
>>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Best regards,
>>>>>>>>>>>
>>>>>>>>>>> - Andy
>>>>>>>>>>>
>>>>>>>>>>> If you are given a choice, you believe you have acted freely. -
>>>>>>>>>>>
>>>>>>>>>>> Raymond
>>>>>>>>>>
>>>>>>>>> Teller (via Peter Watts)
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>
>>>>
>>>>
>>
>>
--
Best regards,
- Andy
If you are given a choice, you believe you have acted freely. - Raymond
Teller (via Peter Watts)
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
Posted by Josh Elser <el...@apache.org>.
Sorry Andrew, let me clarify as that didn't come out right.
I didn't mean that isn't a conversation worth having _now_, just that I
was intentionally avoiding it in my previous email because I didn't
understand the scope of those issues that Vlad had identified. I wanted
to better understand what they were really meant for a user before
coming to my own decision about whether or not I think they are blockers.
That aside, I would agree with you that HBASE-15227 sounds like a real
blocker. Forcing a new full backup for every table sounds really bad --
that's not the kind of experience we'd want a user to have.
Andrew Purtell wrote:
>> I'm going to intentional avoid addressing the discussion of shipping
> partial features (related, but not relevant at the moment).
>
> Then we are not having the same conversation, because it is precisely
> because this is a vote for this feature to go into 2.0, which is already
> overdue, so should be released yesterday, that I took mention of "blocker"
> at face value. At least one of them seems to certainly approach this
> definition. It will be not user friendly, to say the least, to use this in
> a large scale deployment with HBASE-15227 unfinished. HBASE-15227 currently
> has a severity of BLOCKER. Despite what is going on in our politics, words
> matter and we do not get to redefine them for convenience.
>
> Once this work is merged in, how is HBASE-15227 not a blocker for 2.0?
> Because Vlad offered to reduce its severity to make me feel better?
> Currently the description on the issue is "System must be tolerant to
> faults. Backup operations MUST be atomic (no partial completion state in
> system table)" Sounds like a blocker to me, indeed. It is an honest
> assessment and I don't think anyone is doing the community a favor by
> trying to walk that back.
>
>
> On Tue, Mar 14, 2017 at 1:57 PM, Josh Elser<el...@apache.org> wrote:
>
>> I took a moment to read through the "blockers" as originally identified by
>> Vlad, and (to echo Enis' take) I read the majority of them as being
>> blockers not for the next release, but for a "full-fledged feature". I'm
>> going to intentional avoid addressing the discussion of shipping partial
>> features (related, but not relevant at the moment).
>>
>> HBASE-15227 is actually the one that bothers me the most, with HBASE-17133
>> coming in close behind. Vlad, is there any documentation you can point me
>> to about what the current issues are with the current implementation? For
>> example, what happens now if the system has some kind of "partial
>> completion state"?
>>
>> Documentation is one of those that is really hard to judge. We want to get
>> this code out for people to use (and to free up our strained dev
>> resources), but what good is some feature if the docs are
>> missing/incomplete?
>>
>> I think I could stomach the docs being inaccurate (with a clear disclaimer
>> that the chapter is incomplete -- that's a 5min task). But, I think I need
>> an answer about how the feature handles our common dist-sys category of
>> problems 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
>> problem as an (ignorant) user ;)
>>
>>
>> Andrew Purtell wrote:
>>
>>> I don't like that issues were identified as "blockers" but now there is an
>>> attempt to walk that back.
>>>
>>> I don't like that development of this feature has lingered for a long time
>>> in this unfinished state when this work could have been done by now, now
>>> 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 look at the current state and be nonplussed. This will be yet
>>> another half finished thing in 2.0 when this merge happens. Promises to
>>> finish the unfinished work are nice but not 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 2.0 release to slip
>>> further.
>>>
>>> Also, marking something experimental should be done on the merits of that
>>> evaluation, not simply to justify dropping unfinished work into a release
>>> branch.
>>>
>>> I will change my vote to -0.
>>>
>>>
>>> On Mon, Mar 13, 2017 at 4:05 PM, Enis S�ztutar<en...@apache.org> wrote:
>>>
>>> I think there is some misconception of using the term "blockers" for
>>>> referring to those jiras. My understanding is that those three jiras are
>>>> blockers for the backup functionality to be more mature and more usable.
>>>> But they are not release blockers. Let's say we merged the code in, and
>>>> for
>>>> some reason those did not get addressed in time. We can still do the 2.0
>>>> release without having to wait for the commits. We can instead mark the
>>>> "backup" feature as experimental with known issues and go on with the
>>>> release. In that sense they are not real release 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
>>>> luxury of having to wait another couple of months and doing yet another
>>>> giant round of reviews because the code base is a moving target.
>>>>
>>>> Enis
>>>>
>>>> On Mon, Mar 13, 2017 at 3:46 PM, Devaraj Das<dd...@hortonworks.com>
>>>> 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 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 to make the list of remaining work more complete by
>>>>>
>>>> citing
>>>>
>>>>> that as pending work.
>>>>> ________________________________________
>>>>> From: Vladimir Rodionov<vl...@gmail.com>
>>>>> 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 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 (including moving backup/restore
>>>>>>>
>>>>>> out
>>>>> of
>>>>>
>>>>>> core to live in its own module).
>>>>>> For those who were not following our lengthy conversation on a review
>>>>> board, separation of a backup code into a separate module has been
>>>>> done last year, but has been reverted back by request of a reviewer.
>>>>>
>>>>>
>>>>> -Vladimir
>>>>>
>>>>> On Mon, Mar 13, 2017 at 2:23 PM, Stack<st...@duboce.net> wrote:
>>>>>
>>>>> On Fri, Mar 10, 2017 at 9:09 PM, Stack<st...@duboce.net> wrote:
>>>>>> On Fri, Mar 10, 2017 at 6:01 PM, Ted Yu<yu...@gmail.com> 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 burned a bunch of dev resource).
>>>>>>>
>>>>>>> The patch as is is now in a state where it is too big for our infra;
>>>>>>>
>>>>>> rb
>>>>> and JIRA are creaking under the size and # of iterations.
>>>>>>> Adding finish of new JIRAs to this merge implies a new round of
>>>>>>>
>>>>>> review
>>>>> and
>>>>>>> test of an already massive patch. Who is going to do this work?
>>>>>>>
>>>>>>> Going back to a new branch seems wrong route to take.
>>>>>>>
>>>>>>> St.Ack
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> To be more explicit, this patch was developed on a branch and then a
>>>>> bunch
>>>>>
>>>>>> of dev resources were burned getting it into a state where it could be
>>>>>> merged to master. Going back to a branch to bulk up the merge so it
>>>>>> includes more JIRAs than the many it already incorporates is the wrong
>>>>>> direction for us to be headed in. It ignores the feedback given and the
>>>>>> work done by Vladimir slimming down an already over-broad scope. It is
>>>>>>
>>>>> also
>>>>>
>>>>>> predicated on abundant review and testing resource being on tap to
>>>>>>
>>>>> cycle
>>>>> on
>>>>>
>>>>>> a feature that is useful, but non-core.
>>>>>>
>>>>>> The patch is ready for merge IMO. Geoffrey makes a nice list of what is
>>>>>> still to do though IIRC, the list is incomplete because a bunch of
>>>>>> follow-ons came of the review cycle (including moving backup/restore
>>>>>>
>>>>> out
>>>>> of
>>>>>
>>>>>> core to live in its own module).
>>>>>>
>>>>>> The patch needs three votes to merge. I am not against merge but I am
>>>>>>
>>>>> not
>>>>> voting for the patch because I do have any more time to spend on this
>>>>>> non-core feature and feel that a vote will have me assume a
>>>>>>
>>>>> responsibility
>>>>>
>>>>>> I will not shirk.
>>>>>>
>>>>>> S
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> FYI
>>>>>>>> On Fri, Mar 10, 2017 at 3:30 PM, Ted Yu<yu...@gmail.com>
>>>>>>>>
>>>>>>> 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 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,
>>>>> we
>>>>>
>>>>>> propose to community for merging into branch-2 (master branch, if
>>>>>>>> branch-2
>>>>>>>>
>>>>>>>>> doesn't materialize for whatever reason) again
>>>>>>>>>
>>>>>>>>> Cheers
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Mar 10, 2017 at 3:01 PM, Andrew Purtell<
>>>>>>>>>
>>>>>>>> apurtell@apache.org>
>>>>>> wrote:
>>>>>>>>> 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 the documentation issue is important but not actually a
>>>>>>>>>>
>>>>>>>>> blocker.
>>>>>>>>> That may be a controversial opinion, but documentation can be
>>>>>>>>> back-filled
>>>>>>>>> worst case. So take HBASE-17133 off the list.
>>>>>>>>>> Remaining are effectively HBASE-14417, HBASE-14141, and
>>>>>>>>>>
>>>>>>>>> HBASE-15227.
>>>>>> They
>>>>>>>>> all have patches attached to the respective JIRAs so completing
>>>>>>>>> this
>>>>>> work
>>>>>>>>> won't be onerous. Get these committed and I will lift my -1. The
>>>>>>>>> others
>>>>>>> who
>>>>>>>>>> voted +1 on this thread surely can help with that.
>>>>>>>>>>
>>>>>>>>>> Thanks.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Mar 10, 2017 at 2:32 PM, Vladimir Rodionov<
>>>>>>>>>> vladrodionov@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> No problem I will downgrade Blockers to Majors if it scares
>>>>>>>>>> you,
>>>>> Andrew
>>>>>>>>> [image: \U0001f642]
>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>
>>>>>>>>>>> On Mar 10, 2017, at 1:52 PM, Andrew Purtell<
>>>>>>>>>>> apurtell@apache.org
>>>>>> wrote:
>>>>>>>>>>> \u200bI 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 prevent that release because these blockers will
>>>>>>>>>>> be
>>>>> there. I
>>>>>>>>>>> am
>>>>>>>>>>>
>>>>>>>>>>>> inclined to veto. Probably we should not propose branch
>>>>>>>>>>>>
>>>>>>>>>>> merges
>>>>> into
>>>>>>> code
>>>>>>>>>>> we
>>>>>>>>>>>
>>>>>>>>>>>> are trying to get out the door with known blockers. Why not
>>>>>>>>>>>>
>>>>>>>>>>> do
>>>>> that
>>>>>>> work
>>>>>>>>>>> first? It seems an obvious question. Perhaps I am missing
>>>>>>>>>>> something.
>>>>>>>>> If we can branch for 2.0 now and then merge this, and not
>>>>>>>>>>> into
>>>>> the
>>>>>>> 2.0
>>>>>>>>> branch, I would vote +1 for branch merge even with known
>>>>>>>>>>> blockers
>>>>>> pending.
>>>>>>>>>>>> \u200b
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Mar 10, 2017 at 1:42 PM, Vladimir Rodionov<
>>>>>>>>>>>>
>>>>>>>>>>> vladrodionov@gmail.com>
>>>>>>>>>>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> 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<
>>>>>>>>>>>>>
>>>>>>>>>>>> apurtell@apache.org
>>>>>>> wrote:
>>>>>>>>>>>> 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<
>>>>>>>>>>>>>>
>>>>>>>>>>>>> vladrodionov@gmail.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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 reviews
>>>>>>>>>>>>>> and
>>>>>> has
>>>>>>>>> probably
>>>>>>>>>>>>>> the most lengthy discussion thread on Apache JIRA
>>>>>>>>>>>>>> (HBASE-14123)
>>>>>>> :)
>>>>>>>>> The work has been split into 3 phases (HBASE-14030, 14123,
>>>>>>>>>>>>>> 14414)
>>>>>>>>> Two
>>>>>>>>>>> first
>>>>>>>>>>>>>> are complete, third one is still in progress.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *** Summary of work HBASE-14123
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The new feature introduces new command-line extensions to
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> the
>>>>>> hbase
>>>>>>>>> command
>>>>>>>>>>>>>> and, from the client side, is accessible through
>>>>>>>>>>>>>> command-line
>>>>>> only
>>>>>>>>> Operations:
>>>>>>>>>>>>>>> * Create full backup on a list of tables or backup set
>>>>>>>>>>>>>>> * Create incremental backup image for table list or backup
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> set
>>>>>> * Restore list of tables from a given backup image
>>>>>>>>>>>>>>> * Show current backup progress
>>>>>>>>>>>>>>> * Delete backup image and all related images
>>>>>>>>>>>>>>> * Show history of backups
>>>>>>>>>>>>>>> * Backup set operations: create backup set, add/remove
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> table
>>>>> to/from
>>>>>>>>>>> backup
>>>>>>>>>>>>>> set, etc
>>>>>>>>>>>>>>> In the current implementation, the feature is already
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> usable,
>>>>>> meaning
>>>>>>>>>>> that
>>>>>>>>>>>>>> users can backup tables and restore them using provided
>>>>>>>>>>>>>> command-line
>>>>>>>>>>> tools.
>>>>>>>>>>>>>> Both: full and incremental backups are supported.
>>>>>>>>>>>>>>> This work is based on original work of IBM team
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> (HBASE-7912).
>>>>>> The
>>>>>>>>> full
>>>>>>>>>>> list
>>>>>>>>>>>>>> of JIRAs included in this mega patch can be found in three
>>>>>>>>>>>>>> umbrella
>>>>>>>>> JIRAs:
>>>>>>>>>>>>>> HBASE-14030 (Phase 1), HBASE-14123 (Phase 2) and
>>>>>>>>>>>>>> HBASE-14414
>>>>> (Phase 3
>>>>>>>>>>> -
>>>>>>>>>>>
>>>>>>>>>>>> all
>>>>>>>>>>>>>> resolved ones made it into the patch)
>>>>>>>>>>>>>>> *** What are the remaining work items
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> All remaining items can be found in Phase 3 umbrella JIRA:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> HBASE-14414.
>>>>>>>>>>>> They are split into 3 groups: BLOCKER, CRITICAL, MAJOR
>>>>>>>>>>>>>>> Only BLOCKERs and CRITICALs are guaranteed for HBase 2.0
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> release.
>>>>>>>>> ***** BLOCKER
>>>>>>>>>>>>>>> * HBASE-14417 Incremental backup and bulk loading ( Patch
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> available)
>>>>>>>>>>> * HBASE-14135 HBase Backup/Restore Phase 3: Merge backup
>>>>>>>>>>>>>> images
>>>>>>> * HBASE-14141 HBase Backup/Restore Phase 3: Filter WALs on
>>>>>>>>>>>>>> backup
>>>>>>>>> to
>>>>>>>>>>> include only edits from backup tables (Patch available)
>>>>>>>>>>>>>>> * HBASE-17133 Backup documentation
>>>>>>>>>>>>>>> * HBASE-15227 Fault tolerance support
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ***** CRITICAL
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> * HBASE-16465 Disable split/merges during backup
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We have umbrella JIRA (HBASE-14414) to track all the
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> remaining
>>>>>> work
>>>>>>>>> All the BLOCKER and CRITICAL JIRAs currently in open state
>>>>>>>>>>>>>> will
>>>>>>> be
>>>>>>>>> implemented by 2.0 release time. Some MAJOR too, but it
>>>>>>>>>>>>>> depends
>>>>>>> on
>>>>>>>>> resource
>>>>>>>>>>>>>> availability
>>>>>>>>>>>>>>> The former development branch (HBASE-7912) is obsolete and
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> will
>>>>>>> be
>>>>>>>>> closed/deleted after the merge.
>>>>>>>>>>>>>>> We want backup to be a GA feature in 2.0
>>>>>>>>>>>>>>> We are going to support full backward compatibility for
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> backup
>>>>>> tool in
>>>>>>>>>>> 2.0
>>>>>>>>>>>>>> and onwards.
>>>>>>>>>>>>>>> **** Configuration
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Backup is disabled, by default. To enable it, the
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> following
>>>>> configuration
>>>>>>>>>>>>>> properties must be added to hbase-site.xml:
>>>>>>>>>>>>>>> hbase.backup.enable=true
>>>>>>>>>>>>>>> hbase.master.logcleaner.plugins=YOUR_PLUGINS,org.
>>>>>>>>>>>>>>> apache.hadoop.hbase.backup.master.BackupLogCleaner
>>>>>>>>>>>>>>> hbase.procedure.master.classes=YOUR_CLASSES,org.
>>>>>>>>>>>>>>> apache.hadoop.hbase.backup.master.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> LogRollMasterProcedureManager
>>>>>>> hbase.procedure.regionserver.classes=YOUR_CLASSES,org.
>>>>>>>>>>>>>>> apache.hadoop.hbase.backup.regionserver.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> LogRollRegionServerProcedureMa
>>>>>>>>>>>> nager
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I would like to thank IBM team and Jerry He for original
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> work,
>>>>>> Enis, Ted, Stack, Matteo, Jerry for time spent on code
>>>>>>>>>>>>>> reviews
>>>>>> Special thanks to Ted Yu for his co-development work.
>>>>>>>>>>>>>>> References:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-7912
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> (original
>>>>> IBM,
>>>>>>> contains
>>>>>>>>>>>>>> design doc)
>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-14030 (Phase
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1)
>>>>> https://issues.apache.org/jira/browse/HBASE-14123 (Phase
>>>>>>>>>>>>>> 2)
>>>>> https://issues.apache.org/jira/browse/HBASE-14414 (Phase
>>>>>>>>>>>>>> 3)
>>>>> Please vote +1/-1 by midnight Pacific Time (00:00
>>>>>>>>>>>>>>> -0800 GMT) on March 11th \u200bon whether or not we should
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> merge
>>>>> this
>>>>>>>>> into
>>>>>>>>>>> the
>>>>>>>>>>>>>> current master.
>>>>>>>>>>>>>>> -Vladimir Rodionov
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - Andy
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If you are given a choice, you believe you have acted
>>>>>>>>>>>>>>
>>>>>>>>>>>>> freely. -
>>>>>> Raymond
>>>>>>>>>>> Teller (via Peter Watts)
>>>>>>>>>>>> --
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>
>>>>>>>>>>>> - Andy
>>>>>>>>>>>>
>>>>>>>>>>>> If you are given a choice, you believe you have acted
>>>>>>>>>>>>
>>>>>>>>>>> freely. -
>>>>> Raymond
>>>>>>>>>>> Teller (via Peter Watts)
>>>>>>>>>> --
>>>>>>>>>> Best regards,
>>>>>>>>>>
>>>>>>>>>> - Andy
>>>>>>>>>>
>>>>>>>>>> If you are given a choice, you believe you have acted freely. -
>>>>>>>>>>
>>>>>>>>> Raymond
>>>>>>> Teller (via Peter Watts)
>>>>>>>>>>
>>>
>>>
>
>
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
Posted by Vladimir Rodionov <vl...@gmail.com>.
To be honest, Andrew, it is a blocker because I called it BLOCKER. By
BLOCKER I meant - MUST be resolved by 2.0 RC1.
How far are we from 2.0 RC1, by the way? I am pretty sure, that not only
Phase 3 will be completed by that date, but even more advanced - Phase 4,
with features like snapshot-less full backups, performance optimizations,
point-in-time recovery and full s3 (and other clouds) support.
-Vlad
On Tue, Mar 14, 2017 at 3:43 PM, Andrew Purtell <ap...@apache.org> wrote:
> > I'm going to intentional avoid addressing the discussion of shipping
> partial features (related, but not relevant at the moment).
>
> Then we are not having the same conversation, because it is precisely
> because this is a vote for this feature to go into 2.0, which is already
> overdue, so should be released yesterday, that I took mention of "blocker"
> at face value. At least one of them seems to certainly approach this
> definition. It will be not user friendly, to say the least, to use this in
> a large scale deployment with HBASE-15227 unfinished. HBASE-15227 currently
> has a severity of BLOCKER. Despite what is going on in our politics, words
> matter and we do not get to redefine them for convenience.
>
> Once this work is merged in, how is HBASE-15227 not a blocker for 2.0?
> Because Vlad offered to reduce its severity to make me feel better?
> Currently the description on the issue is "System must be tolerant to
> faults. Backup operations MUST be atomic (no partial completion state in
> system table)" Sounds like a blocker to me, indeed. It is an honest
> assessment and I don't think anyone is doing the community a favor by
> trying to walk that back.
>
>
> On Tue, Mar 14, 2017 at 1:57 PM, Josh Elser <el...@apache.org> wrote:
>
> > I took a moment to read through the "blockers" as originally identified
> by
> > Vlad, and (to echo Enis' take) I read the majority of them as being
> > blockers not for the next release, but for a "full-fledged feature". I'm
> > going to intentional avoid addressing the discussion of shipping partial
> > features (related, but not relevant at the moment).
> >
> > HBASE-15227 is actually the one that bothers me the most, with
> HBASE-17133
> > coming in close behind. Vlad, is there any documentation you can point me
> > to about what the current issues are with the current implementation? For
> > example, what happens now if the system has some kind of "partial
> > completion state"?
> >
> > Documentation is one of those that is really hard to judge. We want to
> get
> > this code out for people to use (and to free up our strained dev
> > resources), but what good is some feature if the docs are
> > missing/incomplete?
> >
> > I think I could stomach the docs being inaccurate (with a clear
> disclaimer
> > that the chapter is incomplete -- that's a 5min task). But, I think I
> need
> > an answer about how the feature handles our common dist-sys category of
> > problems 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
> > problem as an (ignorant) user ;)
> >
> >
> > Andrew Purtell wrote:
> >
> >> I don't like that issues were identified as "blockers" but now there is
> an
> >> attempt to walk that back.
> >>
> >> I don't like that development of this feature has lingered for a long
> time
> >> in this unfinished state when this work could have been done by now, now
> >> 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 look at the current state and be nonplussed. This will be yet
> >> another half finished thing in 2.0 when this merge happens. Promises to
> >> finish the unfinished work are nice but not 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 2.0 release to slip
> >> further.
> >>
> >> Also, marking something experimental should be done on the merits of
> that
> >> evaluation, not simply to justify dropping unfinished work into a
> release
> >> branch.
> >>
> >> I will change my vote to -0.
> >>
> >>
> >> On Mon, Mar 13, 2017 at 4:05 PM, Enis Söztutar<en...@apache.org> wrote:
> >>
> >> I think there is some misconception of using the term "blockers" for
> >>> referring to those jiras. My understanding is that those three jiras
> are
> >>> blockers for the backup functionality to be more mature and more
> usable.
> >>> But they are not release blockers. Let's say we merged the code in, and
> >>> for
> >>> some reason those did not get addressed in time. We can still do the
> 2.0
> >>> release without having to wait for the commits. We can instead mark the
> >>> "backup" feature as experimental with known issues and go on with the
> >>> release. In that sense they are not real release 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
> >>> luxury of having to wait another couple of months and doing yet another
> >>> giant round of reviews because the code base is a moving target.
> >>>
> >>> Enis
> >>>
> >>> On Mon, Mar 13, 2017 at 3:46 PM, Devaraj Das<dd...@hortonworks.com>
> >>> 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 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 to make the list of remaining work more complete by
> >>>>
> >>> citing
> >>>
> >>>> that as pending work.
> >>>> ________________________________________
> >>>> From: Vladimir Rodionov<vl...@gmail.com>
> >>>> 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 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 (including moving backup/restore
> >>>>>>
> >>>>> out
> >>>
> >>>> of
> >>>>
> >>>>> core to live in its own module).
> >>>>>>
> >>>>> For those who were not following our lengthy conversation on a review
> >>>> board, separation of a backup code into a separate module has been
> >>>> done last year, but has been reverted back by request of a reviewer.
> >>>>
> >>>>
> >>>> -Vladimir
> >>>>
> >>>> On Mon, Mar 13, 2017 at 2:23 PM, Stack<st...@duboce.net> wrote:
> >>>>
> >>>> On Fri, Mar 10, 2017 at 9:09 PM, Stack<st...@duboce.net> wrote:
> >>>>>
> >>>>> On Fri, Mar 10, 2017 at 6:01 PM, Ted Yu<yu...@gmail.com> 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 burned a bunch of dev resource).
> >>>>>>
> >>>>>> The patch as is is now in a state where it is too big for our infra;
> >>>>>>
> >>>>> rb
> >>>
> >>>> and JIRA are creaking under the size and # of iterations.
> >>>>>>
> >>>>>> Adding finish of new JIRAs to this merge implies a new round of
> >>>>>>
> >>>>> review
> >>>
> >>>> and
> >>>>>
> >>>>>> test of an already massive patch. Who is going to do this work?
> >>>>>>
> >>>>>> Going back to a new branch seems wrong route to take.
> >>>>>>
> >>>>>> St.Ack
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> To be more explicit, this patch was developed on a branch and then a
> >>>>>
> >>>> bunch
> >>>>
> >>>>> of dev resources were burned getting it into a state where it could
> be
> >>>>> merged to master. Going back to a branch to bulk up the merge so it
> >>>>> includes more JIRAs than the many it already incorporates is the
> wrong
> >>>>> direction for us to be headed in. It ignores the feedback given and
> the
> >>>>> work done by Vladimir slimming down an already over-broad scope. It
> is
> >>>>>
> >>>> also
> >>>>
> >>>>> predicated on abundant review and testing resource being on tap to
> >>>>>
> >>>> cycle
> >>>
> >>>> on
> >>>>
> >>>>> a feature that is useful, but non-core.
> >>>>>
> >>>>> The patch is ready for merge IMO. Geoffrey makes a nice list of what
> is
> >>>>> still to do though IIRC, the list is incomplete because a bunch of
> >>>>> follow-ons came of the review cycle (including moving backup/restore
> >>>>>
> >>>> out
> >>>
> >>>> of
> >>>>
> >>>>> core to live in its own module).
> >>>>>
> >>>>> The patch needs three votes to merge. I am not against merge but I am
> >>>>>
> >>>> not
> >>>
> >>>> voting for the patch because I do have any more time to spend on this
> >>>>> non-core feature and feel that a vote will have me assume a
> >>>>>
> >>>> responsibility
> >>>>
> >>>>> I will not shirk.
> >>>>>
> >>>>> S
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> FYI
> >>>>>>>
> >>>>>>> On Fri, Mar 10, 2017 at 3:30 PM, Ted Yu<yu...@gmail.com>
> >>>>>>>
> >>>>>> 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 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,
> >>>
> >>>> we
> >>>>
> >>>>> propose to community for merging into branch-2 (master branch, if
> >>>>>>>>
> >>>>>>> branch-2
> >>>>>>>
> >>>>>>>> doesn't materialize for whatever reason) again
> >>>>>>>>
> >>>>>>>> Cheers
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Fri, Mar 10, 2017 at 3:01 PM, Andrew Purtell<
> >>>>>>>>
> >>>>>>> apurtell@apache.org>
> >>>>
> >>>>> wrote:
> >>>>>>>>
> >>>>>>>> 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 the documentation issue is important but not actually a
> >>>>>>>>>
> >>>>>>>> blocker.
> >>>>>>>
> >>>>>>>> That may be a controversial opinion, but documentation can be
> >>>>>>>>>
> >>>>>>>> back-filled
> >>>>>>>
> >>>>>>>> worst case. So take HBASE-17133 off the list.
> >>>>>>>>>
> >>>>>>>>> Remaining are effectively HBASE-14417, HBASE-14141, and
> >>>>>>>>>
> >>>>>>>> HBASE-15227.
> >>>>
> >>>>> They
> >>>>>>>
> >>>>>>>> all have patches attached to the respective JIRAs so completing
> >>>>>>>>>
> >>>>>>>> this
> >>>>
> >>>>> work
> >>>>>>>
> >>>>>>>> won't be onerous. Get these committed and I will lift my -1. The
> >>>>>>>>>
> >>>>>>>> others
> >>>>>
> >>>>>> who
> >>>>>>>>> voted +1 on this thread surely can help with that.
> >>>>>>>>>
> >>>>>>>>> Thanks.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Fri, Mar 10, 2017 at 2:32 PM, Vladimir Rodionov<
> >>>>>>>>> vladrodionov@gmail.com>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> No problem I will downgrade Blockers to Majors if it scares
> >>>>>>>>>>
> >>>>>>>>> you,
> >>>
> >>>> Andrew
> >>>>>>>
> >>>>>>>> [image: 🙂]
> >>>>>>>>>
> >>>>>>>>>> Sent from my iPhone
> >>>>>>>>>>
> >>>>>>>>>> On Mar 10, 2017, at 1:52 PM, Andrew Purtell<
> >>>>>>>>>>>
> >>>>>>>>>> apurtell@apache.org
> >>>>
> >>>>> 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
> >>>
> >>>> 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 prevent that release because these blockers will
> >>>>>>>>>>>
> >>>>>>>>>> be
> >>>
> >>>> there. I
> >>>>>>>>>
> >>>>>>>>>> am
> >>>>>>>>>>
> >>>>>>>>>>> inclined to veto. Probably we should not propose branch
> >>>>>>>>>>>
> >>>>>>>>>> merges
> >>>
> >>>> into
> >>>>>
> >>>>>> code
> >>>>>>>>>
> >>>>>>>>>> we
> >>>>>>>>>>
> >>>>>>>>>>> are trying to get out the door with known blockers. Why not
> >>>>>>>>>>>
> >>>>>>>>>> do
> >>>
> >>>> that
> >>>>>
> >>>>>> work
> >>>>>>>>>
> >>>>>>>>>> first? It seems an obvious question. Perhaps I am missing
> >>>>>>>>>>>
> >>>>>>>>>> something.
> >>>>>>>
> >>>>>>>> If we can branch for 2.0 now and then merge this, and not
> >>>>>>>>>>>
> >>>>>>>>>> into
> >>>
> >>>> the
> >>>>>
> >>>>>> 2.0
> >>>>>>>
> >>>>>>>> branch, I would vote +1 for branch merge even with known
> >>>>>>>>>>>
> >>>>>>>>>> blockers
> >>>>
> >>>>> pending.
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Fri, Mar 10, 2017 at 1:42 PM, Vladimir Rodionov<
> >>>>>>>>>>>
> >>>>>>>>>> vladrodionov@gmail.com>
> >>>>>>>>>>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> 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<
> >>>>>>>>>>>>
> >>>>>>>>>>> apurtell@apache.org
> >>>>>
> >>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> 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<
> >>>>>>>>>>>>>
> >>>>>>>>>>>> vladrodionov@gmail.com>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> 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 reviews
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> and
> >>>>
> >>>>> has
> >>>>>>>
> >>>>>>>> probably
> >>>>>>>>>>>>
> >>>>>>>>>>>>> the most lengthy discussion thread on Apache JIRA
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> (HBASE-14123)
> >>>>>
> >>>>>> :)
> >>>>>>>
> >>>>>>>> The work has been split into 3 phases (HBASE-14030, 14123,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> 14414)
> >>>>>>>
> >>>>>>>> Two
> >>>>>>>>>
> >>>>>>>>>> first
> >>>>>>>>>>>>
> >>>>>>>>>>>>> are complete, third one is still in progress.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> *** Summary of work HBASE-14123
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> The new feature introduces new command-line extensions to
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> the
> >>>>
> >>>>> hbase
> >>>>>>>
> >>>>>>>> command
> >>>>>>>>>>>>
> >>>>>>>>>>>>> and, from the client side, is accessible through
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> command-line
> >>>>
> >>>>> only
> >>>>>>>
> >>>>>>>> Operations:
> >>>>>>>>>>>>>> * Create full backup on a list of tables or backup set
> >>>>>>>>>>>>>> * Create incremental backup image for table list or backup
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> set
> >>>>
> >>>>> * Restore list of tables from a given backup image
> >>>>>>>>>>>>>> * Show current backup progress
> >>>>>>>>>>>>>> * Delete backup image and all related images
> >>>>>>>>>>>>>> * Show history of backups
> >>>>>>>>>>>>>> * Backup set operations: create backup set, add/remove
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> table
> >>>
> >>>> to/from
> >>>>>>>>>
> >>>>>>>>>> backup
> >>>>>>>>>>>>
> >>>>>>>>>>>>> set, etc
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> In the current implementation, the feature is already
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> usable,
> >>>>
> >>>>> meaning
> >>>>>>>>>
> >>>>>>>>>> that
> >>>>>>>>>>>>
> >>>>>>>>>>>>> users can backup tables and restore them using provided
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> command-line
> >>>>>>>>>
> >>>>>>>>>> tools.
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Both: full and incremental backups are supported.
> >>>>>>>>>>>>>> This work is based on original work of IBM team
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> (HBASE-7912).
> >>>>
> >>>>> The
> >>>>>>>
> >>>>>>>> full
> >>>>>>>>>
> >>>>>>>>>> list
> >>>>>>>>>>>>
> >>>>>>>>>>>>> of JIRAs included in this mega patch can be found in three
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> umbrella
> >>>>>>>
> >>>>>>>> JIRAs:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> HBASE-14030 (Phase 1), HBASE-14123 (Phase 2) and
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> HBASE-14414
> >>>
> >>>> (Phase 3
> >>>>>>>>>
> >>>>>>>>>> -
> >>>>>>>>>>
> >>>>>>>>>>> all
> >>>>>>>>>>>>
> >>>>>>>>>>>>> resolved ones made it into the patch)
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> *** What are the remaining work items
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> All remaining items can be found in Phase 3 umbrella JIRA:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> HBASE-14414.
> >>>>>>>>>>
> >>>>>>>>>>> They are split into 3 groups: BLOCKER, CRITICAL, MAJOR
> >>>>>>>>>>>>>> Only BLOCKERs and CRITICALs are guaranteed for HBase 2.0
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> release.
> >>>>>>>
> >>>>>>>> ***** BLOCKER
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> * HBASE-14417 Incremental backup and bulk loading ( Patch
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> available)
> >>>>>>>>>
> >>>>>>>>>> * HBASE-14135 HBase Backup/Restore Phase 3: Merge backup
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> images
> >>>>>
> >>>>>> * HBASE-14141 HBase Backup/Restore Phase 3: Filter WALs on
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> backup
> >>>>>>>
> >>>>>>>> to
> >>>>>>>>>
> >>>>>>>>>> include only edits from backup tables (Patch available)
> >>>>>>>>>>>>>> * HBASE-17133 Backup documentation
> >>>>>>>>>>>>>> * HBASE-15227 Fault tolerance support
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> ***** CRITICAL
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> * HBASE-16465 Disable split/merges during backup
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> We have umbrella JIRA (HBASE-14414) to track all the
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> remaining
> >>>>
> >>>>> work
> >>>>>>>
> >>>>>>>> All the BLOCKER and CRITICAL JIRAs currently in open state
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> will
> >>>>>
> >>>>>> be
> >>>>>>>
> >>>>>>>> implemented by 2.0 release time. Some MAJOR too, but it
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> depends
> >>>>>
> >>>>>> on
> >>>>>>>
> >>>>>>>> resource
> >>>>>>>>>>>>
> >>>>>>>>>>>>> availability
> >>>>>>>>>>>>>> The former development branch (HBASE-7912) is obsolete and
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> will
> >>>>>
> >>>>>> be
> >>>>>>>
> >>>>>>>> closed/deleted after the merge.
> >>>>>>>>>>>>>> We want backup to be a GA feature in 2.0
> >>>>>>>>>>>>>> We are going to support full backward compatibility for
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> backup
> >>>>
> >>>>> tool in
> >>>>>>>>>
> >>>>>>>>>> 2.0
> >>>>>>>>>>>>
> >>>>>>>>>>>>> and onwards.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> **** Configuration
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Backup is disabled, by default. To enable it, the
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> following
> >>>
> >>>> configuration
> >>>>>>>>>>>>
> >>>>>>>>>>>>> properties must be added to hbase-site.xml:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> hbase.backup.enable=true
> >>>>>>>>>>>>>> hbase.master.logcleaner.plugins=YOUR_PLUGINS,org.
> >>>>>>>>>>>>>> apache.hadoop.hbase.backup.master.BackupLogCleaner
> >>>>>>>>>>>>>> hbase.procedure.master.classes=YOUR_CLASSES,org.
> >>>>>>>>>>>>>> apache.hadoop.hbase.backup.master.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> LogRollMasterProcedureManager
> >>>>>
> >>>>>> hbase.procedure.regionserver.classes=YOUR_CLASSES,org.
> >>>>>>>>>>>>>> apache.hadoop.hbase.backup.regionserver.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> LogRollRegionServerProcedureMa
> >>>>>>>>>>
> >>>>>>>>>>> nager
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I would like to thank IBM team and Jerry He for original
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> work,
> >>>>
> >>>>> Enis, Ted, Stack, Matteo, Jerry for time spent on code
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> reviews
> >>>>
> >>>>> Special thanks to Ted Yu for his co-development work.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> References:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-7912
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> (original
> >>>
> >>>> IBM,
> >>>>>
> >>>>>> contains
> >>>>>>>>>>>>
> >>>>>>>>>>>>> design doc)
> >>>>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-14030 (Phase
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> 1)
> >>>
> >>>> https://issues.apache.org/jira/browse/HBASE-14123 (Phase
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> 2)
> >>>
> >>>> https://issues.apache.org/jira/browse/HBASE-14414 (Phase
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> 3)
> >>>
> >>>> Please vote +1/-1 by midnight Pacific Time (00:00
> >>>>>>>>>>>>>> -0800 GMT) on March 11th on whether or not we should
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> merge
> >>>
> >>>> this
> >>>>>>>
> >>>>>>>> into
> >>>>>>>>>
> >>>>>>>>>> the
> >>>>>>>>>>>>
> >>>>>>>>>>>>> current master.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> -Vladimir Rodionov
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> --
> >>>>>>>>>>>>> Best regards,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> - Andy
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> If you are given a choice, you believe you have acted
> >>>>>>>>>>>>>
> >>>>>>>>>>>> freely. -
> >>>>
> >>>>> Raymond
> >>>>>>>>>
> >>>>>>>>>> Teller (via Peter Watts)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> Best regards,
> >>>>>>>>>>>
> >>>>>>>>>>> - Andy
> >>>>>>>>>>>
> >>>>>>>>>>> If you are given a choice, you believe you have acted
> >>>>>>>>>>>
> >>>>>>>>>> freely. -
> >>>
> >>>> Raymond
> >>>>>>>>>
> >>>>>>>>>> Teller (via Peter Watts)
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Best regards,
> >>>>>>>>>
> >>>>>>>>> - Andy
> >>>>>>>>>
> >>>>>>>>> If you are given a choice, you believe you have acted freely. -
> >>>>>>>>>
> >>>>>>>> Raymond
> >>>>>
> >>>>>> Teller (via Peter Watts)
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>
> >>
> >>
>
>
> --
> Best regards,
>
> - Andy
>
> If you are given a choice, you believe you have acted freely. - Raymond
> Teller (via Peter Watts)
>
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
Posted by Andrew Purtell <ap...@apache.org>.
> I'm going to intentional avoid addressing the discussion of shipping
partial features (related, but not relevant at the moment).
Then we are not having the same conversation, because it is precisely
because this is a vote for this feature to go into 2.0, which is already
overdue, so should be released yesterday, that I took mention of "blocker"
at face value. At least one of them seems to certainly approach this
definition. It will be not user friendly, to say the least, to use this in
a large scale deployment with HBASE-15227 unfinished. HBASE-15227 currently
has a severity of BLOCKER. Despite what is going on in our politics, words
matter and we do not get to redefine them for convenience.
Once this work is merged in, how is HBASE-15227 not a blocker for 2.0?
Because Vlad offered to reduce its severity to make me feel better?
Currently the description on the issue is "System must be tolerant to
faults. Backup operations MUST be atomic (no partial completion state in
system table)" Sounds like a blocker to me, indeed. It is an honest
assessment and I don't think anyone is doing the community a favor by
trying to walk that back.
On Tue, Mar 14, 2017 at 1:57 PM, Josh Elser <el...@apache.org> wrote:
> I took a moment to read through the "blockers" as originally identified by
> Vlad, and (to echo Enis' take) I read the majority of them as being
> blockers not for the next release, but for a "full-fledged feature". I'm
> going to intentional avoid addressing the discussion of shipping partial
> features (related, but not relevant at the moment).
>
> HBASE-15227 is actually the one that bothers me the most, with HBASE-17133
> coming in close behind. Vlad, is there any documentation you can point me
> to about what the current issues are with the current implementation? For
> example, what happens now if the system has some kind of "partial
> completion state"?
>
> Documentation is one of those that is really hard to judge. We want to get
> this code out for people to use (and to free up our strained dev
> resources), but what good is some feature if the docs are
> missing/incomplete?
>
> I think I could stomach the docs being inaccurate (with a clear disclaimer
> that the chapter is incomplete -- that's a 5min task). But, I think I need
> an answer about how the feature handles our common dist-sys category of
> problems 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
> problem as an (ignorant) user ;)
>
>
> Andrew Purtell wrote:
>
>> I don't like that issues were identified as "blockers" but now there is an
>> attempt to walk that back.
>>
>> I don't like that development of this feature has lingered for a long time
>> in this unfinished state when this work could have been done by now, now
>> 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 look at the current state and be nonplussed. This will be yet
>> another half finished thing in 2.0 when this merge happens. Promises to
>> finish the unfinished work are nice but not 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 2.0 release to slip
>> further.
>>
>> Also, marking something experimental should be done on the merits of that
>> evaluation, not simply to justify dropping unfinished work into a release
>> branch.
>>
>> I will change my vote to -0.
>>
>>
>> On Mon, Mar 13, 2017 at 4:05 PM, Enis Söztutar<en...@apache.org> wrote:
>>
>> I think there is some misconception of using the term "blockers" for
>>> referring to those jiras. My understanding is that those three jiras are
>>> blockers for the backup functionality to be more mature and more usable.
>>> But they are not release blockers. Let's say we merged the code in, and
>>> for
>>> some reason those did not get addressed in time. We can still do the 2.0
>>> release without having to wait for the commits. We can instead mark the
>>> "backup" feature as experimental with known issues and go on with the
>>> release. In that sense they are not real release 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
>>> luxury of having to wait another couple of months and doing yet another
>>> giant round of reviews because the code base is a moving target.
>>>
>>> Enis
>>>
>>> On Mon, Mar 13, 2017 at 3:46 PM, Devaraj Das<dd...@hortonworks.com>
>>> 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 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 to make the list of remaining work more complete by
>>>>
>>> citing
>>>
>>>> that as pending work.
>>>> ________________________________________
>>>> From: Vladimir Rodionov<vl...@gmail.com>
>>>> 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 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 (including moving backup/restore
>>>>>>
>>>>> out
>>>
>>>> of
>>>>
>>>>> core to live in its own module).
>>>>>>
>>>>> For those who were not following our lengthy conversation on a review
>>>> board, separation of a backup code into a separate module has been
>>>> done last year, but has been reverted back by request of a reviewer.
>>>>
>>>>
>>>> -Vladimir
>>>>
>>>> On Mon, Mar 13, 2017 at 2:23 PM, Stack<st...@duboce.net> wrote:
>>>>
>>>> On Fri, Mar 10, 2017 at 9:09 PM, Stack<st...@duboce.net> wrote:
>>>>>
>>>>> On Fri, Mar 10, 2017 at 6:01 PM, Ted Yu<yu...@gmail.com> 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 burned a bunch of dev resource).
>>>>>>
>>>>>> The patch as is is now in a state where it is too big for our infra;
>>>>>>
>>>>> rb
>>>
>>>> and JIRA are creaking under the size and # of iterations.
>>>>>>
>>>>>> Adding finish of new JIRAs to this merge implies a new round of
>>>>>>
>>>>> review
>>>
>>>> and
>>>>>
>>>>>> test of an already massive patch. Who is going to do this work?
>>>>>>
>>>>>> Going back to a new branch seems wrong route to take.
>>>>>>
>>>>>> St.Ack
>>>>>>
>>>>>>
>>>>>>
>>>>>> To be more explicit, this patch was developed on a branch and then a
>>>>>
>>>> bunch
>>>>
>>>>> of dev resources were burned getting it into a state where it could be
>>>>> merged to master. Going back to a branch to bulk up the merge so it
>>>>> includes more JIRAs than the many it already incorporates is the wrong
>>>>> direction for us to be headed in. It ignores the feedback given and the
>>>>> work done by Vladimir slimming down an already over-broad scope. It is
>>>>>
>>>> also
>>>>
>>>>> predicated on abundant review and testing resource being on tap to
>>>>>
>>>> cycle
>>>
>>>> on
>>>>
>>>>> a feature that is useful, but non-core.
>>>>>
>>>>> The patch is ready for merge IMO. Geoffrey makes a nice list of what is
>>>>> still to do though IIRC, the list is incomplete because a bunch of
>>>>> follow-ons came of the review cycle (including moving backup/restore
>>>>>
>>>> out
>>>
>>>> of
>>>>
>>>>> core to live in its own module).
>>>>>
>>>>> The patch needs three votes to merge. I am not against merge but I am
>>>>>
>>>> not
>>>
>>>> voting for the patch because I do have any more time to spend on this
>>>>> non-core feature and feel that a vote will have me assume a
>>>>>
>>>> responsibility
>>>>
>>>>> I will not shirk.
>>>>>
>>>>> S
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> FYI
>>>>>>>
>>>>>>> On Fri, Mar 10, 2017 at 3:30 PM, Ted Yu<yu...@gmail.com>
>>>>>>>
>>>>>> 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 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,
>>>
>>>> we
>>>>
>>>>> propose to community for merging into branch-2 (master branch, if
>>>>>>>>
>>>>>>> branch-2
>>>>>>>
>>>>>>>> doesn't materialize for whatever reason) again
>>>>>>>>
>>>>>>>> Cheers
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Mar 10, 2017 at 3:01 PM, Andrew Purtell<
>>>>>>>>
>>>>>>> apurtell@apache.org>
>>>>
>>>>> wrote:
>>>>>>>>
>>>>>>>> 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 the documentation issue is important but not actually a
>>>>>>>>>
>>>>>>>> blocker.
>>>>>>>
>>>>>>>> That may be a controversial opinion, but documentation can be
>>>>>>>>>
>>>>>>>> back-filled
>>>>>>>
>>>>>>>> worst case. So take HBASE-17133 off the list.
>>>>>>>>>
>>>>>>>>> Remaining are effectively HBASE-14417, HBASE-14141, and
>>>>>>>>>
>>>>>>>> HBASE-15227.
>>>>
>>>>> They
>>>>>>>
>>>>>>>> all have patches attached to the respective JIRAs so completing
>>>>>>>>>
>>>>>>>> this
>>>>
>>>>> work
>>>>>>>
>>>>>>>> won't be onerous. Get these committed and I will lift my -1. The
>>>>>>>>>
>>>>>>>> others
>>>>>
>>>>>> who
>>>>>>>>> voted +1 on this thread surely can help with that.
>>>>>>>>>
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Mar 10, 2017 at 2:32 PM, Vladimir Rodionov<
>>>>>>>>> vladrodionov@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> No problem I will downgrade Blockers to Majors if it scares
>>>>>>>>>>
>>>>>>>>> you,
>>>
>>>> Andrew
>>>>>>>
>>>>>>>> [image: 🙂]
>>>>>>>>>
>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>
>>>>>>>>>> On Mar 10, 2017, at 1:52 PM, Andrew Purtell<
>>>>>>>>>>>
>>>>>>>>>> apurtell@apache.org
>>>>
>>>>> 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
>>>
>>>> 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 prevent that release because these blockers will
>>>>>>>>>>>
>>>>>>>>>> be
>>>
>>>> there. I
>>>>>>>>>
>>>>>>>>>> am
>>>>>>>>>>
>>>>>>>>>>> inclined to veto. Probably we should not propose branch
>>>>>>>>>>>
>>>>>>>>>> merges
>>>
>>>> into
>>>>>
>>>>>> code
>>>>>>>>>
>>>>>>>>>> we
>>>>>>>>>>
>>>>>>>>>>> are trying to get out the door with known blockers. Why not
>>>>>>>>>>>
>>>>>>>>>> do
>>>
>>>> that
>>>>>
>>>>>> work
>>>>>>>>>
>>>>>>>>>> first? It seems an obvious question. Perhaps I am missing
>>>>>>>>>>>
>>>>>>>>>> something.
>>>>>>>
>>>>>>>> If we can branch for 2.0 now and then merge this, and not
>>>>>>>>>>>
>>>>>>>>>> into
>>>
>>>> the
>>>>>
>>>>>> 2.0
>>>>>>>
>>>>>>>> branch, I would vote +1 for branch merge even with known
>>>>>>>>>>>
>>>>>>>>>> blockers
>>>>
>>>>> pending.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Mar 10, 2017 at 1:42 PM, Vladimir Rodionov<
>>>>>>>>>>>
>>>>>>>>>> vladrodionov@gmail.com>
>>>>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> 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<
>>>>>>>>>>>>
>>>>>>>>>>> apurtell@apache.org
>>>>>
>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> 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<
>>>>>>>>>>>>>
>>>>>>>>>>>> vladrodionov@gmail.com>
>>>>>>>>>>>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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 reviews
>>>>>>>>>>>>>>
>>>>>>>>>>>>> and
>>>>
>>>>> has
>>>>>>>
>>>>>>>> probably
>>>>>>>>>>>>
>>>>>>>>>>>>> the most lengthy discussion thread on Apache JIRA
>>>>>>>>>>>>>>
>>>>>>>>>>>>> (HBASE-14123)
>>>>>
>>>>>> :)
>>>>>>>
>>>>>>>> The work has been split into 3 phases (HBASE-14030, 14123,
>>>>>>>>>>>>>>
>>>>>>>>>>>>> 14414)
>>>>>>>
>>>>>>>> Two
>>>>>>>>>
>>>>>>>>>> first
>>>>>>>>>>>>
>>>>>>>>>>>>> are complete, third one is still in progress.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *** Summary of work HBASE-14123
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The new feature introduces new command-line extensions to
>>>>>>>>>>>>>>
>>>>>>>>>>>>> the
>>>>
>>>>> hbase
>>>>>>>
>>>>>>>> command
>>>>>>>>>>>>
>>>>>>>>>>>>> and, from the client side, is accessible through
>>>>>>>>>>>>>>
>>>>>>>>>>>>> command-line
>>>>
>>>>> only
>>>>>>>
>>>>>>>> Operations:
>>>>>>>>>>>>>> * Create full backup on a list of tables or backup set
>>>>>>>>>>>>>> * Create incremental backup image for table list or backup
>>>>>>>>>>>>>>
>>>>>>>>>>>>> set
>>>>
>>>>> * Restore list of tables from a given backup image
>>>>>>>>>>>>>> * Show current backup progress
>>>>>>>>>>>>>> * Delete backup image and all related images
>>>>>>>>>>>>>> * Show history of backups
>>>>>>>>>>>>>> * Backup set operations: create backup set, add/remove
>>>>>>>>>>>>>>
>>>>>>>>>>>>> table
>>>
>>>> to/from
>>>>>>>>>
>>>>>>>>>> backup
>>>>>>>>>>>>
>>>>>>>>>>>>> set, etc
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In the current implementation, the feature is already
>>>>>>>>>>>>>>
>>>>>>>>>>>>> usable,
>>>>
>>>>> meaning
>>>>>>>>>
>>>>>>>>>> that
>>>>>>>>>>>>
>>>>>>>>>>>>> users can backup tables and restore them using provided
>>>>>>>>>>>>>>
>>>>>>>>>>>>> command-line
>>>>>>>>>
>>>>>>>>>> tools.
>>>>>>>>>>>>
>>>>>>>>>>>>> Both: full and incremental backups are supported.
>>>>>>>>>>>>>> This work is based on original work of IBM team
>>>>>>>>>>>>>>
>>>>>>>>>>>>> (HBASE-7912).
>>>>
>>>>> The
>>>>>>>
>>>>>>>> full
>>>>>>>>>
>>>>>>>>>> list
>>>>>>>>>>>>
>>>>>>>>>>>>> of JIRAs included in this mega patch can be found in three
>>>>>>>>>>>>>>
>>>>>>>>>>>>> umbrella
>>>>>>>
>>>>>>>> JIRAs:
>>>>>>>>>>>>
>>>>>>>>>>>>> HBASE-14030 (Phase 1), HBASE-14123 (Phase 2) and
>>>>>>>>>>>>>>
>>>>>>>>>>>>> HBASE-14414
>>>
>>>> (Phase 3
>>>>>>>>>
>>>>>>>>>> -
>>>>>>>>>>
>>>>>>>>>>> all
>>>>>>>>>>>>
>>>>>>>>>>>>> resolved ones made it into the patch)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *** What are the remaining work items
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> All remaining items can be found in Phase 3 umbrella JIRA:
>>>>>>>>>>>>>>
>>>>>>>>>>>>> HBASE-14414.
>>>>>>>>>>
>>>>>>>>>>> They are split into 3 groups: BLOCKER, CRITICAL, MAJOR
>>>>>>>>>>>>>> Only BLOCKERs and CRITICALs are guaranteed for HBase 2.0
>>>>>>>>>>>>>>
>>>>>>>>>>>>> release.
>>>>>>>
>>>>>>>> ***** BLOCKER
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> * HBASE-14417 Incremental backup and bulk loading ( Patch
>>>>>>>>>>>>>>
>>>>>>>>>>>>> available)
>>>>>>>>>
>>>>>>>>>> * HBASE-14135 HBase Backup/Restore Phase 3: Merge backup
>>>>>>>>>>>>>>
>>>>>>>>>>>>> images
>>>>>
>>>>>> * HBASE-14141 HBase Backup/Restore Phase 3: Filter WALs on
>>>>>>>>>>>>>>
>>>>>>>>>>>>> backup
>>>>>>>
>>>>>>>> to
>>>>>>>>>
>>>>>>>>>> include only edits from backup tables (Patch available)
>>>>>>>>>>>>>> * HBASE-17133 Backup documentation
>>>>>>>>>>>>>> * HBASE-15227 Fault tolerance support
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ***** CRITICAL
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> * HBASE-16465 Disable split/merges during backup
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> We have umbrella JIRA (HBASE-14414) to track all the
>>>>>>>>>>>>>>
>>>>>>>>>>>>> remaining
>>>>
>>>>> work
>>>>>>>
>>>>>>>> All the BLOCKER and CRITICAL JIRAs currently in open state
>>>>>>>>>>>>>>
>>>>>>>>>>>>> will
>>>>>
>>>>>> be
>>>>>>>
>>>>>>>> implemented by 2.0 release time. Some MAJOR too, but it
>>>>>>>>>>>>>>
>>>>>>>>>>>>> depends
>>>>>
>>>>>> on
>>>>>>>
>>>>>>>> resource
>>>>>>>>>>>>
>>>>>>>>>>>>> availability
>>>>>>>>>>>>>> The former development branch (HBASE-7912) is obsolete and
>>>>>>>>>>>>>>
>>>>>>>>>>>>> will
>>>>>
>>>>>> be
>>>>>>>
>>>>>>>> closed/deleted after the merge.
>>>>>>>>>>>>>> We want backup to be a GA feature in 2.0
>>>>>>>>>>>>>> We are going to support full backward compatibility for
>>>>>>>>>>>>>>
>>>>>>>>>>>>> backup
>>>>
>>>>> tool in
>>>>>>>>>
>>>>>>>>>> 2.0
>>>>>>>>>>>>
>>>>>>>>>>>>> and onwards.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> **** Configuration
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Backup is disabled, by default. To enable it, the
>>>>>>>>>>>>>>
>>>>>>>>>>>>> following
>>>
>>>> configuration
>>>>>>>>>>>>
>>>>>>>>>>>>> properties must be added to hbase-site.xml:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> hbase.backup.enable=true
>>>>>>>>>>>>>> hbase.master.logcleaner.plugins=YOUR_PLUGINS,org.
>>>>>>>>>>>>>> apache.hadoop.hbase.backup.master.BackupLogCleaner
>>>>>>>>>>>>>> hbase.procedure.master.classes=YOUR_CLASSES,org.
>>>>>>>>>>>>>> apache.hadoop.hbase.backup.master.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> LogRollMasterProcedureManager
>>>>>
>>>>>> hbase.procedure.regionserver.classes=YOUR_CLASSES,org.
>>>>>>>>>>>>>> apache.hadoop.hbase.backup.regionserver.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> LogRollRegionServerProcedureMa
>>>>>>>>>>
>>>>>>>>>>> nager
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I would like to thank IBM team and Jerry He for original
>>>>>>>>>>>>>>
>>>>>>>>>>>>> work,
>>>>
>>>>> Enis, Ted, Stack, Matteo, Jerry for time spent on code
>>>>>>>>>>>>>>
>>>>>>>>>>>>> reviews
>>>>
>>>>> Special thanks to Ted Yu for his co-development work.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> References:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-7912
>>>>>>>>>>>>>>
>>>>>>>>>>>>> (original
>>>
>>>> IBM,
>>>>>
>>>>>> contains
>>>>>>>>>>>>
>>>>>>>>>>>>> design doc)
>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-14030 (Phase
>>>>>>>>>>>>>>
>>>>>>>>>>>>> 1)
>>>
>>>> https://issues.apache.org/jira/browse/HBASE-14123 (Phase
>>>>>>>>>>>>>>
>>>>>>>>>>>>> 2)
>>>
>>>> https://issues.apache.org/jira/browse/HBASE-14414 (Phase
>>>>>>>>>>>>>>
>>>>>>>>>>>>> 3)
>>>
>>>> Please vote +1/-1 by midnight Pacific Time (00:00
>>>>>>>>>>>>>> -0800 GMT) on March 11th on whether or not we should
>>>>>>>>>>>>>>
>>>>>>>>>>>>> merge
>>>
>>>> this
>>>>>>>
>>>>>>>> into
>>>>>>>>>
>>>>>>>>>> the
>>>>>>>>>>>>
>>>>>>>>>>>>> current master.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -Vladimir Rodionov
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Andy
>>>>>>>>>>>>>
>>>>>>>>>>>>> If you are given a choice, you believe you have acted
>>>>>>>>>>>>>
>>>>>>>>>>>> freely. -
>>>>
>>>>> Raymond
>>>>>>>>>
>>>>>>>>>> Teller (via Peter Watts)
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Best regards,
>>>>>>>>>>>
>>>>>>>>>>> - Andy
>>>>>>>>>>>
>>>>>>>>>>> If you are given a choice, you believe you have acted
>>>>>>>>>>>
>>>>>>>>>> freely. -
>>>
>>>> Raymond
>>>>>>>>>
>>>>>>>>>> Teller (via Peter Watts)
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Best regards,
>>>>>>>>>
>>>>>>>>> - Andy
>>>>>>>>>
>>>>>>>>> If you are given a choice, you believe you have acted freely. -
>>>>>>>>>
>>>>>>>> Raymond
>>>>>
>>>>>> Teller (via Peter Watts)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>
>>
>>
--
Best regards,
- Andy
If you are given a choice, you believe you have acted freely. - Raymond
Teller (via Peter Watts)
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
Posted by Vladimir Rodionov <vl...@gmail.com>.
Josh,
On a doc side we have a very good manual:
https://issues.apache.org/jira/secure/attachment/12829269/Backup-and-Restore-Apache_19Sep2016.pdf
The only thing what was changed is the command-line tools args format, but
you can start from there - just type command w/o args.
In the current implementation the worst thing which could happen is a
failure during backup, which will leave backup system table in incomplete
state (read - broken). This won't affect cluster operations but may prevent
further backup operations (will require full backup for all table to reset
broken system table).
I am currently starting working on HBASE-15227. It will probably take a
week or two to finish.
On a doc side, as I already mention we will need to update command-line
tool section in the doc I posted above.
-Vlad
On Tue, Mar 14, 2017 at 1:57 PM, Josh Elser <el...@apache.org> wrote:
> I took a moment to read through the "blockers" as originally identified by
> Vlad, and (to echo Enis' take) I read the majority of them as being
> blockers not for the next release, but for a "full-fledged feature". I'm
> going to intentional avoid addressing the discussion of shipping partial
> features (related, but not relevant at the moment).
>
> HBASE-15227 is actually the one that bothers me the most, with HBASE-17133
> coming in close behind. Vlad, is there any documentation you can point me
> to about what the current issues are with the current implementation? For
> example, what happens now if the system has some kind of "partial
> completion state"?
>
> Documentation is one of those that is really hard to judge. We want to get
> this code out for people to use (and to free up our strained dev
> resources), but what good is some feature if the docs are
> missing/incomplete?
>
> I think I could stomach the docs being inaccurate (with a clear disclaimer
> that the chapter is incomplete -- that's a 5min task). But, I think I need
> an answer about how the feature handles our common dist-sys category of
> problems 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
> problem as an (ignorant) user ;)
>
>
> Andrew Purtell wrote:
>
>> I don't like that issues were identified as "blockers" but now there is an
>> attempt to walk that back.
>>
>> I don't like that development of this feature has lingered for a long time
>> in this unfinished state when this work could have been done by now, now
>> 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 look at the current state and be nonplussed. This will be yet
>> another half finished thing in 2.0 when this merge happens. Promises to
>> finish the unfinished work are nice but not 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 2.0 release to slip
>> further.
>>
>> Also, marking something experimental should be done on the merits of that
>> evaluation, not simply to justify dropping unfinished work into a release
>> branch.
>>
>> I will change my vote to -0.
>>
>>
>> On Mon, Mar 13, 2017 at 4:05 PM, Enis Söztutar<en...@apache.org> wrote:
>>
>> I think there is some misconception of using the term "blockers" for
>>> referring to those jiras. My understanding is that those three jiras are
>>> blockers for the backup functionality to be more mature and more usable.
>>> But they are not release blockers. Let's say we merged the code in, and
>>> for
>>> some reason those did not get addressed in time. We can still do the 2.0
>>> release without having to wait for the commits. We can instead mark the
>>> "backup" feature as experimental with known issues and go on with the
>>> release. In that sense they are not real release 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
>>> luxury of having to wait another couple of months and doing yet another
>>> giant round of reviews because the code base is a moving target.
>>>
>>> Enis
>>>
>>> On Mon, Mar 13, 2017 at 3:46 PM, Devaraj Das<dd...@hortonworks.com>
>>> 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 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 to make the list of remaining work more complete by
>>>>
>>> citing
>>>
>>>> that as pending work.
>>>> ________________________________________
>>>> From: Vladimir Rodionov<vl...@gmail.com>
>>>> 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 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 (including moving backup/restore
>>>>>>
>>>>> out
>>>
>>>> of
>>>>
>>>>> core to live in its own module).
>>>>>>
>>>>> For those who were not following our lengthy conversation on a review
>>>> board, separation of a backup code into a separate module has been
>>>> done last year, but has been reverted back by request of a reviewer.
>>>>
>>>>
>>>> -Vladimir
>>>>
>>>> On Mon, Mar 13, 2017 at 2:23 PM, Stack<st...@duboce.net> wrote:
>>>>
>>>> On Fri, Mar 10, 2017 at 9:09 PM, Stack<st...@duboce.net> wrote:
>>>>>
>>>>> On Fri, Mar 10, 2017 at 6:01 PM, Ted Yu<yu...@gmail.com> 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 burned a bunch of dev resource).
>>>>>>
>>>>>> The patch as is is now in a state where it is too big for our infra;
>>>>>>
>>>>> rb
>>>
>>>> and JIRA are creaking under the size and # of iterations.
>>>>>>
>>>>>> Adding finish of new JIRAs to this merge implies a new round of
>>>>>>
>>>>> review
>>>
>>>> and
>>>>>
>>>>>> test of an already massive patch. Who is going to do this work?
>>>>>>
>>>>>> Going back to a new branch seems wrong route to take.
>>>>>>
>>>>>> St.Ack
>>>>>>
>>>>>>
>>>>>>
>>>>>> To be more explicit, this patch was developed on a branch and then a
>>>>>
>>>> bunch
>>>>
>>>>> of dev resources were burned getting it into a state where it could be
>>>>> merged to master. Going back to a branch to bulk up the merge so it
>>>>> includes more JIRAs than the many it already incorporates is the wrong
>>>>> direction for us to be headed in. It ignores the feedback given and the
>>>>> work done by Vladimir slimming down an already over-broad scope. It is
>>>>>
>>>> also
>>>>
>>>>> predicated on abundant review and testing resource being on tap to
>>>>>
>>>> cycle
>>>
>>>> on
>>>>
>>>>> a feature that is useful, but non-core.
>>>>>
>>>>> The patch is ready for merge IMO. Geoffrey makes a nice list of what is
>>>>> still to do though IIRC, the list is incomplete because a bunch of
>>>>> follow-ons came of the review cycle (including moving backup/restore
>>>>>
>>>> out
>>>
>>>> of
>>>>
>>>>> core to live in its own module).
>>>>>
>>>>> The patch needs three votes to merge. I am not against merge but I am
>>>>>
>>>> not
>>>
>>>> voting for the patch because I do have any more time to spend on this
>>>>> non-core feature and feel that a vote will have me assume a
>>>>>
>>>> responsibility
>>>>
>>>>> I will not shirk.
>>>>>
>>>>> S
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> FYI
>>>>>>>
>>>>>>> On Fri, Mar 10, 2017 at 3:30 PM, Ted Yu<yu...@gmail.com>
>>>>>>>
>>>>>> 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 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,
>>>
>>>> we
>>>>
>>>>> propose to community for merging into branch-2 (master branch, if
>>>>>>>>
>>>>>>> branch-2
>>>>>>>
>>>>>>>> doesn't materialize for whatever reason) again
>>>>>>>>
>>>>>>>> Cheers
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Mar 10, 2017 at 3:01 PM, Andrew Purtell<
>>>>>>>>
>>>>>>> apurtell@apache.org>
>>>>
>>>>> wrote:
>>>>>>>>
>>>>>>>> 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 the documentation issue is important but not actually a
>>>>>>>>>
>>>>>>>> blocker.
>>>>>>>
>>>>>>>> That may be a controversial opinion, but documentation can be
>>>>>>>>>
>>>>>>>> back-filled
>>>>>>>
>>>>>>>> worst case. So take HBASE-17133 off the list.
>>>>>>>>>
>>>>>>>>> Remaining are effectively HBASE-14417, HBASE-14141, and
>>>>>>>>>
>>>>>>>> HBASE-15227.
>>>>
>>>>> They
>>>>>>>
>>>>>>>> all have patches attached to the respective JIRAs so completing
>>>>>>>>>
>>>>>>>> this
>>>>
>>>>> work
>>>>>>>
>>>>>>>> won't be onerous. Get these committed and I will lift my -1. The
>>>>>>>>>
>>>>>>>> others
>>>>>
>>>>>> who
>>>>>>>>> voted +1 on this thread surely can help with that.
>>>>>>>>>
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Mar 10, 2017 at 2:32 PM, Vladimir Rodionov<
>>>>>>>>> vladrodionov@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> 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<
>>>>>>>>>>>
>>>>>>>>>> apurtell@apache.org
>>>>
>>>>> 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
>>>
>>>> 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 prevent that release because these blockers will
>>>>>>>>>>>
>>>>>>>>>> be
>>>
>>>> there. I
>>>>>>>>>
>>>>>>>>>> am
>>>>>>>>>>
>>>>>>>>>>> inclined to veto. Probably we should not propose branch
>>>>>>>>>>>
>>>>>>>>>> merges
>>>
>>>> into
>>>>>
>>>>>> code
>>>>>>>>>
>>>>>>>>>> we
>>>>>>>>>>
>>>>>>>>>>> are trying to get out the door with known blockers. Why not
>>>>>>>>>>>
>>>>>>>>>> do
>>>
>>>> that
>>>>>
>>>>>> work
>>>>>>>>>
>>>>>>>>>> first? It seems an obvious question. Perhaps I am missing
>>>>>>>>>>>
>>>>>>>>>> something.
>>>>>>>
>>>>>>>> If we can branch for 2.0 now and then merge this, and not
>>>>>>>>>>>
>>>>>>>>>> into
>>>
>>>> the
>>>>>
>>>>>> 2.0
>>>>>>>
>>>>>>>> branch, I would vote +1 for branch merge even with known
>>>>>>>>>>>
>>>>>>>>>> blockers
>>>>
>>>>> pending.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Mar 10, 2017 at 1:42 PM, Vladimir Rodionov<
>>>>>>>>>>>
>>>>>>>>>> vladrodionov@gmail.com>
>>>>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> 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<
>>>>>>>>>>>>
>>>>>>>>>>> apurtell@apache.org
>>>>>
>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> 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<
>>>>>>>>>>>>>
>>>>>>>>>>>> vladrodionov@gmail.com>
>>>>>>>>>>>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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 reviews
>>>>>>>>>>>>>>
>>>>>>>>>>>>> and
>>>>
>>>>> has
>>>>>>>
>>>>>>>> probably
>>>>>>>>>>>>
>>>>>>>>>>>>> the most lengthy discussion thread on Apache JIRA
>>>>>>>>>>>>>>
>>>>>>>>>>>>> (HBASE-14123)
>>>>>
>>>>>> :)
>>>>>>>
>>>>>>>> The work has been split into 3 phases (HBASE-14030, 14123,
>>>>>>>>>>>>>>
>>>>>>>>>>>>> 14414)
>>>>>>>
>>>>>>>> Two
>>>>>>>>>
>>>>>>>>>> first
>>>>>>>>>>>>
>>>>>>>>>>>>> are complete, third one is still in progress.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *** Summary of work HBASE-14123
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The new feature introduces new command-line extensions to
>>>>>>>>>>>>>>
>>>>>>>>>>>>> the
>>>>
>>>>> hbase
>>>>>>>
>>>>>>>> command
>>>>>>>>>>>>
>>>>>>>>>>>>> and, from the client side, is accessible through
>>>>>>>>>>>>>>
>>>>>>>>>>>>> command-line
>>>>
>>>>> only
>>>>>>>
>>>>>>>> Operations:
>>>>>>>>>>>>>> * Create full backup on a list of tables or backup set
>>>>>>>>>>>>>> * Create incremental backup image for table list or backup
>>>>>>>>>>>>>>
>>>>>>>>>>>>> set
>>>>
>>>>> * Restore list of tables from a given backup image
>>>>>>>>>>>>>> * Show current backup progress
>>>>>>>>>>>>>> * Delete backup image and all related images
>>>>>>>>>>>>>> * Show history of backups
>>>>>>>>>>>>>> * Backup set operations: create backup set, add/remove
>>>>>>>>>>>>>>
>>>>>>>>>>>>> table
>>>
>>>> to/from
>>>>>>>>>
>>>>>>>>>> backup
>>>>>>>>>>>>
>>>>>>>>>>>>> set, etc
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In the current implementation, the feature is already
>>>>>>>>>>>>>>
>>>>>>>>>>>>> usable,
>>>>
>>>>> meaning
>>>>>>>>>
>>>>>>>>>> that
>>>>>>>>>>>>
>>>>>>>>>>>>> users can backup tables and restore them using provided
>>>>>>>>>>>>>>
>>>>>>>>>>>>> command-line
>>>>>>>>>
>>>>>>>>>> tools.
>>>>>>>>>>>>
>>>>>>>>>>>>> Both: full and incremental backups are supported.
>>>>>>>>>>>>>> This work is based on original work of IBM team
>>>>>>>>>>>>>>
>>>>>>>>>>>>> (HBASE-7912).
>>>>
>>>>> The
>>>>>>>
>>>>>>>> full
>>>>>>>>>
>>>>>>>>>> list
>>>>>>>>>>>>
>>>>>>>>>>>>> of JIRAs included in this mega patch can be found in three
>>>>>>>>>>>>>>
>>>>>>>>>>>>> umbrella
>>>>>>>
>>>>>>>> JIRAs:
>>>>>>>>>>>>
>>>>>>>>>>>>> HBASE-14030 (Phase 1), HBASE-14123 (Phase 2) and
>>>>>>>>>>>>>>
>>>>>>>>>>>>> HBASE-14414
>>>
>>>> (Phase 3
>>>>>>>>>
>>>>>>>>>> -
>>>>>>>>>>
>>>>>>>>>>> all
>>>>>>>>>>>>
>>>>>>>>>>>>> resolved ones made it into the patch)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *** What are the remaining work items
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> All remaining items can be found in Phase 3 umbrella JIRA:
>>>>>>>>>>>>>>
>>>>>>>>>>>>> HBASE-14414.
>>>>>>>>>>
>>>>>>>>>>> They are split into 3 groups: BLOCKER, CRITICAL, MAJOR
>>>>>>>>>>>>>> Only BLOCKERs and CRITICALs are guaranteed for HBase 2.0
>>>>>>>>>>>>>>
>>>>>>>>>>>>> release.
>>>>>>>
>>>>>>>> ***** BLOCKER
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> * HBASE-14417 Incremental backup and bulk loading ( Patch
>>>>>>>>>>>>>>
>>>>>>>>>>>>> available)
>>>>>>>>>
>>>>>>>>>> * HBASE-14135 HBase Backup/Restore Phase 3: Merge backup
>>>>>>>>>>>>>>
>>>>>>>>>>>>> images
>>>>>
>>>>>> * HBASE-14141 HBase Backup/Restore Phase 3: Filter WALs on
>>>>>>>>>>>>>>
>>>>>>>>>>>>> backup
>>>>>>>
>>>>>>>> to
>>>>>>>>>
>>>>>>>>>> include only edits from backup tables (Patch available)
>>>>>>>>>>>>>> * HBASE-17133 Backup documentation
>>>>>>>>>>>>>> * HBASE-15227 Fault tolerance support
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ***** CRITICAL
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> * HBASE-16465 Disable split/merges during backup
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> We have umbrella JIRA (HBASE-14414) to track all the
>>>>>>>>>>>>>>
>>>>>>>>>>>>> remaining
>>>>
>>>>> work
>>>>>>>
>>>>>>>> All the BLOCKER and CRITICAL JIRAs currently in open state
>>>>>>>>>>>>>>
>>>>>>>>>>>>> will
>>>>>
>>>>>> be
>>>>>>>
>>>>>>>> implemented by 2.0 release time. Some MAJOR too, but it
>>>>>>>>>>>>>>
>>>>>>>>>>>>> depends
>>>>>
>>>>>> on
>>>>>>>
>>>>>>>> resource
>>>>>>>>>>>>
>>>>>>>>>>>>> availability
>>>>>>>>>>>>>> The former development branch (HBASE-7912) is obsolete and
>>>>>>>>>>>>>>
>>>>>>>>>>>>> will
>>>>>
>>>>>> be
>>>>>>>
>>>>>>>> closed/deleted after the merge.
>>>>>>>>>>>>>> We want backup to be a GA feature in 2.0
>>>>>>>>>>>>>> We are going to support full backward compatibility for
>>>>>>>>>>>>>>
>>>>>>>>>>>>> backup
>>>>
>>>>> tool in
>>>>>>>>>
>>>>>>>>>> 2.0
>>>>>>>>>>>>
>>>>>>>>>>>>> and onwards.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> **** Configuration
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Backup is disabled, by default. To enable it, the
>>>>>>>>>>>>>>
>>>>>>>>>>>>> following
>>>
>>>> configuration
>>>>>>>>>>>>
>>>>>>>>>>>>> properties must be added to hbase-site.xml:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> hbase.backup.enable=true
>>>>>>>>>>>>>> hbase.master.logcleaner.plugins=YOUR_PLUGINS,org.
>>>>>>>>>>>>>> apache.hadoop.hbase.backup.master.BackupLogCleaner
>>>>>>>>>>>>>> hbase.procedure.master.classes=YOUR_CLASSES,org.
>>>>>>>>>>>>>> apache.hadoop.hbase.backup.master.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> LogRollMasterProcedureManager
>>>>>
>>>>>> hbase.procedure.regionserver.classes=YOUR_CLASSES,org.
>>>>>>>>>>>>>> apache.hadoop.hbase.backup.regionserver.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> LogRollRegionServerProcedureMa
>>>>>>>>>>
>>>>>>>>>>> nager
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I would like to thank IBM team and Jerry He for original
>>>>>>>>>>>>>>
>>>>>>>>>>>>> work,
>>>>
>>>>> Enis, Ted, Stack, Matteo, Jerry for time spent on code
>>>>>>>>>>>>>>
>>>>>>>>>>>>> reviews
>>>>
>>>>> Special thanks to Ted Yu for his co-development work.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> References:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-7912
>>>>>>>>>>>>>>
>>>>>>>>>>>>> (original
>>>
>>>> IBM,
>>>>>
>>>>>> contains
>>>>>>>>>>>>
>>>>>>>>>>>>> design doc)
>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-14030 (Phase
>>>>>>>>>>>>>>
>>>>>>>>>>>>> 1)
>>>
>>>> https://issues.apache.org/jira/browse/HBASE-14123 (Phase
>>>>>>>>>>>>>>
>>>>>>>>>>>>> 2)
>>>
>>>> https://issues.apache.org/jira/browse/HBASE-14414 (Phase
>>>>>>>>>>>>>>
>>>>>>>>>>>>> 3)
>>>
>>>> Please vote +1/-1 by midnight Pacific Time (00:00
>>>>>>>>>>>>>> -0800 GMT) on March 11th on whether or not we should
>>>>>>>>>>>>>>
>>>>>>>>>>>>> merge
>>>
>>>> this
>>>>>>>
>>>>>>>> into
>>>>>>>>>
>>>>>>>>>> the
>>>>>>>>>>>>
>>>>>>>>>>>>> current master.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -Vladimir Rodionov
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Andy
>>>>>>>>>>>>>
>>>>>>>>>>>>> If you are given a choice, you believe you have acted
>>>>>>>>>>>>>
>>>>>>>>>>>> freely. -
>>>>
>>>>> Raymond
>>>>>>>>>
>>>>>>>>>> Teller (via Peter Watts)
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Best regards,
>>>>>>>>>>>
>>>>>>>>>>> - Andy
>>>>>>>>>>>
>>>>>>>>>>> If you are given a choice, you believe you have acted
>>>>>>>>>>>
>>>>>>>>>> freely. -
>>>
>>>> Raymond
>>>>>>>>>
>>>>>>>>>> Teller (via Peter Watts)
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Best regards,
>>>>>>>>>
>>>>>>>>> - Andy
>>>>>>>>>
>>>>>>>>> If you are given a choice, you believe you have acted freely. -
>>>>>>>>>
>>>>>>>> Raymond
>>>>>
>>>>>> Teller (via Peter Watts)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>
>>
>>
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
Posted by Josh Elser <el...@apache.org>.
I took a moment to read through the "blockers" as originally identified
by Vlad, and (to echo Enis' take) I read the majority of them as being
blockers not for the next release, but for a "full-fledged feature". I'm
going to intentional avoid addressing the discussion of shipping partial
features (related, but not relevant at the moment).
HBASE-15227 is actually the one that bothers me the most, with
HBASE-17133 coming in close behind. Vlad, is there any documentation you
can point me to about what the current issues are with the current
implementation? For example, what happens now if the system has some
kind of "partial completion state"?
Documentation is one of those that is really hard to judge. We want to
get this code out for people to use (and to free up our strained dev
resources), but what good is some feature if the docs are
missing/incomplete?
I think I could stomach the docs being inaccurate (with a clear
disclaimer that the chapter is incomplete -- that's a 5min task). But, I
think I need an answer about how the feature handles our common dist-sys
category of problems 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
problem as an (ignorant) user ;)
Andrew Purtell wrote:
> I don't like that issues were identified as "blockers" but now there is an
> attempt to walk that back.
>
> I don't like that development of this feature has lingered for a long time
> in this unfinished state when this work could have been done by now, now
> 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 look at the current state and be nonplussed. This will be yet
> another half finished thing in 2.0 when this merge happens. Promises to
> finish the unfinished work are nice but not 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 2.0 release to slip further.
>
> Also, marking something experimental should be done on the merits of that
> evaluation, not simply to justify dropping unfinished work into a release
> branch.
>
> I will change my vote to -0.
>
>
> On Mon, Mar 13, 2017 at 4:05 PM, Enis S�ztutar<en...@apache.org> wrote:
>
>> I think there is some misconception of using the term "blockers" for
>> referring to those jiras. My understanding is that those three jiras are
>> blockers for the backup functionality to be more mature and more usable.
>> But they are not release blockers. Let's say we merged the code in, and for
>> some reason those did not get addressed in time. We can still do the 2.0
>> release without having to wait for the commits. We can instead mark the
>> "backup" feature as experimental with known issues and go on with the
>> release. In that sense they are not real release 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
>> luxury of having to wait another couple of months and doing yet another
>> giant round of reviews because the code base is a moving target.
>>
>> Enis
>>
>> On Mon, Mar 13, 2017 at 3:46 PM, Devaraj Das<dd...@hortonworks.com> 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 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 to make the list of remaining work more complete by
>> citing
>>> that as pending work.
>>> ________________________________________
>>> From: Vladimir Rodionov<vl...@gmail.com>
>>> 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 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 (including moving backup/restore
>> out
>>> of
>>>>> core to live in its own module).
>>> For those who were not following our lengthy conversation on a review
>>> board, separation of a backup code into a separate module has been
>>> done last year, but has been reverted back by request of a reviewer.
>>>
>>>
>>> -Vladimir
>>>
>>> On Mon, Mar 13, 2017 at 2:23 PM, Stack<st...@duboce.net> wrote:
>>>
>>>> On Fri, Mar 10, 2017 at 9:09 PM, Stack<st...@duboce.net> wrote:
>>>>
>>>>> On Fri, Mar 10, 2017 at 6:01 PM, Ted Yu<yu...@gmail.com> 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 burned a bunch of dev resource).
>>>>>
>>>>> The patch as is is now in a state where it is too big for our infra;
>> rb
>>>>> and JIRA are creaking under the size and # of iterations.
>>>>>
>>>>> Adding finish of new JIRAs to this merge implies a new round of
>> review
>>>> and
>>>>> test of an already massive patch. Who is going to do this work?
>>>>>
>>>>> Going back to a new branch seems wrong route to take.
>>>>>
>>>>> St.Ack
>>>>>
>>>>>
>>>>>
>>>> To be more explicit, this patch was developed on a branch and then a
>>> bunch
>>>> of dev resources were burned getting it into a state where it could be
>>>> merged to master. Going back to a branch to bulk up the merge so it
>>>> includes more JIRAs than the many it already incorporates is the wrong
>>>> direction for us to be headed in. It ignores the feedback given and the
>>>> work done by Vladimir slimming down an already over-broad scope. It is
>>> also
>>>> predicated on abundant review and testing resource being on tap to
>> cycle
>>> on
>>>> a feature that is useful, but non-core.
>>>>
>>>> The patch is ready for merge IMO. Geoffrey makes a nice list of what is
>>>> still to do though IIRC, the list is incomplete because a bunch of
>>>> follow-ons came of the review cycle (including moving backup/restore
>> out
>>> of
>>>> core to live in its own module).
>>>>
>>>> The patch needs three votes to merge. I am not against merge but I am
>> not
>>>> voting for the patch because I do have any more time to spend on this
>>>> non-core feature and feel that a vote will have me assume a
>>> responsibility
>>>> I will not shirk.
>>>>
>>>> S
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>> FYI
>>>>>>
>>>>>> On Fri, Mar 10, 2017 at 3:30 PM, Ted Yu<yu...@gmail.com>
>> 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 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,
>>> we
>>>>>>> propose to community for merging into branch-2 (master branch, if
>>>>>> branch-2
>>>>>>> doesn't materialize for whatever reason) again
>>>>>>>
>>>>>>> Cheers
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Mar 10, 2017 at 3:01 PM, Andrew Purtell<
>>> apurtell@apache.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> 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 the documentation issue is important but not actually a
>>>>>> blocker.
>>>>>>>> That may be a controversial opinion, but documentation can be
>>>>>> back-filled
>>>>>>>> worst case. So take HBASE-17133 off the list.
>>>>>>>>
>>>>>>>> Remaining are effectively HBASE-14417, HBASE-14141, and
>>> HBASE-15227.
>>>>>> They
>>>>>>>> all have patches attached to the respective JIRAs so completing
>>> this
>>>>>> work
>>>>>>>> won't be onerous. Get these committed and I will lift my -1. The
>>>> others
>>>>>>>> who
>>>>>>>> voted +1 on this thread surely can help with that.
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Mar 10, 2017 at 2:32 PM, Vladimir Rodionov<
>>>>>>>> vladrodionov@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> No problem I will downgrade Blockers to Majors if it scares
>> you,
>>>>>> Andrew
>>>>>>>> \U0001f642
>>>>>>>>> Sent from my iPhone
>>>>>>>>>
>>>>>>>>>> On Mar 10, 2017, at 1:52 PM, Andrew Purtell<
>>> apurtell@apache.org
>>>>>>>> wrote:
>>>>>>>>>> \u200bI 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 prevent that release because these blockers will
>> be
>>>>>>>> there. I
>>>>>>>>> am
>>>>>>>>>> inclined to veto. Probably we should not propose branch
>> merges
>>>> into
>>>>>>>> code
>>>>>>>>> we
>>>>>>>>>> are trying to get out the door with known blockers. Why not
>> do
>>>> that
>>>>>>>> work
>>>>>>>>>> first? It seems an obvious question. Perhaps I am missing
>>>>>> something.
>>>>>>>>>> If we can branch for 2.0 now and then merge this, and not
>> into
>>>> the
>>>>>> 2.0
>>>>>>>>>> branch, I would vote +1 for branch merge even with known
>>> blockers
>>>>>>>>> pending.
>>>>>>>>>> \u200b
>>>>>>>>>>
>>>>>>>>>> On Fri, Mar 10, 2017 at 1:42 PM, Vladimir Rodionov<
>>>>>>>>> vladrodionov@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> 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<
>>>> apurtell@apache.org
>>>>>>>>> wrote:
>>>>>>>>>>>>> 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<
>>>>>>>>>>> vladrodionov@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> 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 reviews
>>> and
>>>>>> has
>>>>>>>>>>> probably
>>>>>>>>>>>>> the most lengthy discussion thread on Apache JIRA
>>>> (HBASE-14123)
>>>>>> :)
>>>>>>>>>>>>> The work has been split into 3 phases (HBASE-14030, 14123,
>>>>>> 14414)
>>>>>>>> Two
>>>>>>>>>>> first
>>>>>>>>>>>>> are complete, third one is still in progress.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> *** Summary of work HBASE-14123
>>>>>>>>>>>>>
>>>>>>>>>>>>> The new feature introduces new command-line extensions to
>>> the
>>>>>> hbase
>>>>>>>>>>> command
>>>>>>>>>>>>> and, from the client side, is accessible through
>>> command-line
>>>>>> only
>>>>>>>>>>>>> Operations:
>>>>>>>>>>>>> * Create full backup on a list of tables or backup set
>>>>>>>>>>>>> * Create incremental backup image for table list or backup
>>> set
>>>>>>>>>>>>> * Restore list of tables from a given backup image
>>>>>>>>>>>>> * Show current backup progress
>>>>>>>>>>>>> * Delete backup image and all related images
>>>>>>>>>>>>> * Show history of backups
>>>>>>>>>>>>> * Backup set operations: create backup set, add/remove
>> table
>>>>>>>> to/from
>>>>>>>>>>> backup
>>>>>>>>>>>>> set, etc
>>>>>>>>>>>>>
>>>>>>>>>>>>> In the current implementation, the feature is already
>>> usable,
>>>>>>>> meaning
>>>>>>>>>>> that
>>>>>>>>>>>>> users can backup tables and restore them using provided
>>>>>>>> command-line
>>>>>>>>>>> tools.
>>>>>>>>>>>>> Both: full and incremental backups are supported.
>>>>>>>>>>>>> This work is based on original work of IBM team
>>> (HBASE-7912).
>>>>>> The
>>>>>>>> full
>>>>>>>>>>> list
>>>>>>>>>>>>> of JIRAs included in this mega patch can be found in three
>>>>>> umbrella
>>>>>>>>>>> JIRAs:
>>>>>>>>>>>>> HBASE-14030 (Phase 1), HBASE-14123 (Phase 2) and
>> HBASE-14414
>>>>>>>> (Phase 3
>>>>>>>>> -
>>>>>>>>>>> all
>>>>>>>>>>>>> resolved ones made it into the patch)
>>>>>>>>>>>>>
>>>>>>>>>>>>> *** What are the remaining work items
>>>>>>>>>>>>>
>>>>>>>>>>>>> All remaining items can be found in Phase 3 umbrella JIRA:
>>>>>>>>> HBASE-14414.
>>>>>>>>>>>>> They are split into 3 groups: BLOCKER, CRITICAL, MAJOR
>>>>>>>>>>>>> Only BLOCKERs and CRITICALs are guaranteed for HBase 2.0
>>>>>> release.
>>>>>>>>>>>>> ***** BLOCKER
>>>>>>>>>>>>>
>>>>>>>>>>>>> * HBASE-14417 Incremental backup and bulk loading ( Patch
>>>>>>>> available)
>>>>>>>>>>>>> * HBASE-14135 HBase Backup/Restore Phase 3: Merge backup
>>>> images
>>>>>>>>>>>>> * HBASE-14141 HBase Backup/Restore Phase 3: Filter WALs on
>>>>>> backup
>>>>>>>> to
>>>>>>>>>>>>> include only edits from backup tables (Patch available)
>>>>>>>>>>>>> * HBASE-17133 Backup documentation
>>>>>>>>>>>>> * HBASE-15227 Fault tolerance support
>>>>>>>>>>>>>
>>>>>>>>>>>>> ***** CRITICAL
>>>>>>>>>>>>>
>>>>>>>>>>>>> * HBASE-16465 Disable split/merges during backup
>>>>>>>>>>>>>
>>>>>>>>>>>>> We have umbrella JIRA (HBASE-14414) to track all the
>>> remaining
>>>>>> work
>>>>>>>>>>>>> All the BLOCKER and CRITICAL JIRAs currently in open state
>>>> will
>>>>>> be
>>>>>>>>>>>>> implemented by 2.0 release time. Some MAJOR too, but it
>>>> depends
>>>>>> on
>>>>>>>>>>> resource
>>>>>>>>>>>>> availability
>>>>>>>>>>>>> The former development branch (HBASE-7912) is obsolete and
>>>> will
>>>>>> be
>>>>>>>>>>>>> closed/deleted after the merge.
>>>>>>>>>>>>> We want backup to be a GA feature in 2.0
>>>>>>>>>>>>> We are going to support full backward compatibility for
>>> backup
>>>>>>>> tool in
>>>>>>>>>>> 2.0
>>>>>>>>>>>>> and onwards.
>>>>>>>>>>>>>
>>>>>>>>>>>>> **** Configuration
>>>>>>>>>>>>>
>>>>>>>>>>>>> Backup is disabled, by default. To enable it, the
>> following
>>>>>>>>>>> configuration
>>>>>>>>>>>>> properties must be added to hbase-site.xml:
>>>>>>>>>>>>>
>>>>>>>>>>>>> hbase.backup.enable=true
>>>>>>>>>>>>> hbase.master.logcleaner.plugins=YOUR_PLUGINS,org.
>>>>>>>>>>>>> apache.hadoop.hbase.backup.master.BackupLogCleaner
>>>>>>>>>>>>> hbase.procedure.master.classes=YOUR_CLASSES,org.
>>>>>>>>>>>>> apache.hadoop.hbase.backup.master.
>>>> LogRollMasterProcedureManager
>>>>>>>>>>>>> hbase.procedure.regionserver.classes=YOUR_CLASSES,org.
>>>>>>>>>>>>> apache.hadoop.hbase.backup.regionserver.
>>>>>>>>> LogRollRegionServerProcedureMa
>>>>>>>>>>>>> nager
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I would like to thank IBM team and Jerry He for original
>>> work,
>>>>>>>>>>>>> Enis, Ted, Stack, Matteo, Jerry for time spent on code
>>> reviews
>>>>>>>>>>>>> Special thanks to Ted Yu for his co-development work.
>>>>>>>>>>>>>
>>>>>>>>>>>>> References:
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-7912
>> (original
>>>> IBM,
>>>>>>>>>>> contains
>>>>>>>>>>>>> design doc)
>>>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-14030 (Phase
>> 1)
>>>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-14123 (Phase
>> 2)
>>>>>>>>>>>>> https://issues.apache.org/jira/browse/HBASE-14414 (Phase
>> 3)
>>>>>>>>>>>>> Please vote +1/-1 by midnight Pacific Time (00:00
>>>>>>>>>>>>> -0800 GMT) on March 11th \u200bon whether or not we should
>> merge
>>>>>> this
>>>>>>>> into
>>>>>>>>>>> the
>>>>>>>>>>>>> current master.
>>>>>>>>>>>>>
>>>>>>>>>>>>> -Vladimir Rodionov
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>
>>>>>>>>>>>> - Andy
>>>>>>>>>>>>
>>>>>>>>>>>> If you are given a choice, you believe you have acted
>>> freely. -
>>>>>>>> Raymond
>>>>>>>>>>>> Teller (via Peter Watts)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Best regards,
>>>>>>>>>>
>>>>>>>>>> - Andy
>>>>>>>>>>
>>>>>>>>>> If you are given a choice, you believe you have acted
>> freely. -
>>>>>>>> Raymond
>>>>>>>>>> Teller (via Peter Watts)
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>> - Andy
>>>>>>>>
>>>>>>>> If you are given a choice, you believe you have acted freely. -
>>>> Raymond
>>>>>>>> Teller (via Peter Watts)
>>>>>>>>
>>>>>>>
>>>>>
>
>
>
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
Posted by Andrew Purtell <ap...@apache.org>.
I don't like that issues were identified as "blockers" but now there is an
attempt to walk that back.
I don't like that development of this feature has lingered for a long time
in this unfinished state when this work could have been done by now, now
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 look at the current state and be nonplussed. This will be yet
another half finished thing in 2.0 when this merge happens. Promises to
finish the unfinished work are nice but not 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 2.0 release to slip further.
Also, marking something experimental should be done on the merits of that
evaluation, not simply to justify dropping unfinished work into a release
branch.
I will change my vote to -0.
On Mon, Mar 13, 2017 at 4:05 PM, Enis Söztutar <en...@apache.org> wrote:
> I think there is some misconception of using the term "blockers" for
> referring to those jiras. My understanding is that those three jiras are
> blockers for the backup functionality to be more mature and more usable.
> But they are not release blockers. Let's say we merged the code in, and for
> some reason those did not get addressed in time. We can still do the 2.0
> release without having to wait for the commits. We can instead mark the
> "backup" feature as experimental with known issues and go on with the
> release. In that sense they are not real release 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
> luxury of having to wait another couple of months and doing yet another
> giant round of reviews because the code base is a moving target.
>
> Enis
>
> On Mon, Mar 13, 2017 at 3:46 PM, Devaraj Das <dd...@hortonworks.com> 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 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 to make the list of remaining work more complete by
> citing
> > that as pending work.
> > ________________________________________
> > From: Vladimir Rodionov <vl...@gmail.com>
> > 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 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 (including moving backup/restore
> out
> > of
> > >> core to live in its own module).
> >
> > For those who were not following our lengthy conversation on a review
> > board, separation of a backup code into a separate module has been
> > done last year, but has been reverted back by request of a reviewer.
> >
> >
> > -Vladimir
> >
> > On Mon, Mar 13, 2017 at 2:23 PM, Stack <st...@duboce.net> wrote:
> >
> > > On Fri, Mar 10, 2017 at 9:09 PM, Stack <st...@duboce.net> wrote:
> > >
> > > > On Fri, Mar 10, 2017 at 6:01 PM, Ted Yu <yu...@gmail.com> 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 burned a bunch of dev resource).
> > > >
> > > > The patch as is is now in a state where it is too big for our infra;
> rb
> > > > and JIRA are creaking under the size and # of iterations.
> > > >
> > > > Adding finish of new JIRAs to this merge implies a new round of
> review
> > > and
> > > > test of an already massive patch. Who is going to do this work?
> > > >
> > > > Going back to a new branch seems wrong route to take.
> > > >
> > > > St.Ack
> > > >
> > > >
> > > >
> > > To be more explicit, this patch was developed on a branch and then a
> > bunch
> > > of dev resources were burned getting it into a state where it could be
> > > merged to master. Going back to a branch to bulk up the merge so it
> > > includes more JIRAs than the many it already incorporates is the wrong
> > > direction for us to be headed in. It ignores the feedback given and the
> > > work done by Vladimir slimming down an already over-broad scope. It is
> > also
> > > predicated on abundant review and testing resource being on tap to
> cycle
> > on
> > > a feature that is useful, but non-core.
> > >
> > > The patch is ready for merge IMO. Geoffrey makes a nice list of what is
> > > still to do though IIRC, the list is incomplete because a bunch of
> > > follow-ons came of the review cycle (including moving backup/restore
> out
> > of
> > > core to live in its own module).
> > >
> > > The patch needs three votes to merge. I am not against merge but I am
> not
> > > voting for the patch because I do have any more time to spend on this
> > > non-core feature and feel that a vote will have me assume a
> > responsibility
> > > I will not shirk.
> > >
> > > S
> > >
> > >
> > >
> > > >
> > > >
> > > >
> > > >> FYI
> > > >>
> > > >> On Fri, Mar 10, 2017 at 3:30 PM, Ted Yu <yu...@gmail.com>
> 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 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,
> > we
> > > >> > propose to community for merging into branch-2 (master branch, if
> > > >> branch-2
> > > >> > doesn't materialize for whatever reason) again
> > > >> >
> > > >> > Cheers
> > > >> >
> > > >> >
> > > >> > On Fri, Mar 10, 2017 at 3:01 PM, Andrew Purtell <
> > apurtell@apache.org>
> > > >> > wrote:
> > > >> >
> > > >> >> 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 the documentation issue is important but not actually a
> > > >> blocker.
> > > >> >> That may be a controversial opinion, but documentation can be
> > > >> back-filled
> > > >> >> worst case. So take HBASE-17133 off the list.
> > > >> >>
> > > >> >> Remaining are effectively HBASE-14417, HBASE-14141, and
> > HBASE-15227.
> > > >> They
> > > >> >> all have patches attached to the respective JIRAs so completing
> > this
> > > >> work
> > > >> >> won't be onerous. Get these committed and I will lift my -1. The
> > > others
> > > >> >> who
> > > >> >> voted +1 on this thread surely can help with that.
> > > >> >>
> > > >> >> Thanks.
> > > >> >>
> > > >> >>
> > > >> >> On Fri, Mar 10, 2017 at 2:32 PM, Vladimir Rodionov <
> > > >> >> vladrodionov@gmail.com>
> > > >> >> wrote:
> > > >> >>
> > > >> >> > 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 <
> > apurtell@apache.org
> > > >
> > > >> >> 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
> > > >> 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 prevent that release because these blockers will
> be
> > > >> >> there. I
> > > >> >> > am
> > > >> >> > > inclined to veto. Probably we should not propose branch
> merges
> > > into
> > > >> >> code
> > > >> >> > we
> > > >> >> > > are trying to get out the door with known blockers. Why not
> do
> > > that
> > > >> >> work
> > > >> >> > > first? It seems an obvious question. Perhaps I am missing
> > > >> something.
> > > >> >> > >
> > > >> >> > > If we can branch for 2.0 now and then merge this, and not
> into
> > > the
> > > >> 2.0
> > > >> >> > > branch, I would vote +1 for branch merge even with known
> > blockers
> > > >> >> > pending.
> > > >> >> > >
> > > >> >> > >
> > > >> >> > > On Fri, Mar 10, 2017 at 1:42 PM, Vladimir Rodionov <
> > > >> >> > vladrodionov@gmail.com>
> > > >> >> > > wrote:
> > > >> >> > >
> > > >> >> > >> 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 <
> > > apurtell@apache.org
> > > >> >
> > > >> >> > wrote:
> > > >> >> > >>
> > > >> >> > >>>> 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 <
> > > >> >> > >> vladrodionov@gmail.com>
> > > >> >> > >>> wrote:
> > > >> >> > >>>
> > > >> >> > >>>> 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 reviews
> > and
> > > >> has
> > > >> >> > >> probably
> > > >> >> > >>>> the most lengthy discussion thread on Apache JIRA
> > > (HBASE-14123)
> > > >> :)
> > > >> >> > >>>>
> > > >> >> > >>>> The work has been split into 3 phases (HBASE-14030, 14123,
> > > >> 14414)
> > > >> >> Two
> > > >> >> > >> first
> > > >> >> > >>>> are complete, third one is still in progress.
> > > >> >> > >>>>
> > > >> >> > >>>>
> > > >> >> > >>>> *** Summary of work HBASE-14123
> > > >> >> > >>>>
> > > >> >> > >>>> The new feature introduces new command-line extensions to
> > the
> > > >> hbase
> > > >> >> > >> command
> > > >> >> > >>>> and, from the client side, is accessible through
> > command-line
> > > >> only
> > > >> >> > >>>> Operations:
> > > >> >> > >>>> * Create full backup on a list of tables or backup set
> > > >> >> > >>>> * Create incremental backup image for table list or backup
> > set
> > > >> >> > >>>> * Restore list of tables from a given backup image
> > > >> >> > >>>> * Show current backup progress
> > > >> >> > >>>> * Delete backup image and all related images
> > > >> >> > >>>> * Show history of backups
> > > >> >> > >>>> * Backup set operations: create backup set, add/remove
> table
> > > >> >> to/from
> > > >> >> > >> backup
> > > >> >> > >>>> set, etc
> > > >> >> > >>>>
> > > >> >> > >>>> In the current implementation, the feature is already
> > usable,
> > > >> >> meaning
> > > >> >> > >> that
> > > >> >> > >>>> users can backup tables and restore them using provided
> > > >> >> command-line
> > > >> >> > >> tools.
> > > >> >> > >>>> Both: full and incremental backups are supported.
> > > >> >> > >>>> This work is based on original work of IBM team
> > (HBASE-7912).
> > > >> The
> > > >> >> full
> > > >> >> > >> list
> > > >> >> > >>>> of JIRAs included in this mega patch can be found in three
> > > >> umbrella
> > > >> >> > >> JIRAs:
> > > >> >> > >>>> HBASE-14030 (Phase 1), HBASE-14123 (Phase 2) and
> HBASE-14414
> > > >> >> (Phase 3
> > > >> >> > -
> > > >> >> > >> all
> > > >> >> > >>>> resolved ones made it into the patch)
> > > >> >> > >>>>
> > > >> >> > >>>> *** What are the remaining work items
> > > >> >> > >>>>
> > > >> >> > >>>> All remaining items can be found in Phase 3 umbrella JIRA:
> > > >> >> > HBASE-14414.
> > > >> >> > >>>> They are split into 3 groups: BLOCKER, CRITICAL, MAJOR
> > > >> >> > >>>> Only BLOCKERs and CRITICALs are guaranteed for HBase 2.0
> > > >> release.
> > > >> >> > >>>>
> > > >> >> > >>>> ***** BLOCKER
> > > >> >> > >>>>
> > > >> >> > >>>> * HBASE-14417 Incremental backup and bulk loading ( Patch
> > > >> >> available)
> > > >> >> > >>>> * HBASE-14135 HBase Backup/Restore Phase 3: Merge backup
> > > images
> > > >> >> > >>>> * HBASE-14141 HBase Backup/Restore Phase 3: Filter WALs on
> > > >> backup
> > > >> >> to
> > > >> >> > >>>> include only edits from backup tables (Patch available)
> > > >> >> > >>>> * HBASE-17133 Backup documentation
> > > >> >> > >>>> * HBASE-15227 Fault tolerance support
> > > >> >> > >>>>
> > > >> >> > >>>> ***** CRITICAL
> > > >> >> > >>>>
> > > >> >> > >>>> * HBASE-16465 Disable split/merges during backup
> > > >> >> > >>>>
> > > >> >> > >>>> We have umbrella JIRA (HBASE-14414) to track all the
> > remaining
> > > >> work
> > > >> >> > >>>> All the BLOCKER and CRITICAL JIRAs currently in open state
> > > will
> > > >> be
> > > >> >> > >>>> implemented by 2.0 release time. Some MAJOR too, but it
> > > depends
> > > >> on
> > > >> >> > >> resource
> > > >> >> > >>>> availability
> > > >> >> > >>>> The former development branch (HBASE-7912) is obsolete and
> > > will
> > > >> be
> > > >> >> > >>>> closed/deleted after the merge.
> > > >> >> > >>>> We want backup to be a GA feature in 2.0
> > > >> >> > >>>> We are going to support full backward compatibility for
> > backup
> > > >> >> tool in
> > > >> >> > >> 2.0
> > > >> >> > >>>> and onwards.
> > > >> >> > >>>>
> > > >> >> > >>>> **** Configuration
> > > >> >> > >>>>
> > > >> >> > >>>> Backup is disabled, by default. To enable it, the
> following
> > > >> >> > >> configuration
> > > >> >> > >>>> properties must be added to hbase-site.xml:
> > > >> >> > >>>>
> > > >> >> > >>>> hbase.backup.enable=true
> > > >> >> > >>>> hbase.master.logcleaner.plugins=YOUR_PLUGINS,org.
> > > >> >> > >>>> apache.hadoop.hbase.backup.master.BackupLogCleaner
> > > >> >> > >>>> hbase.procedure.master.classes=YOUR_CLASSES,org.
> > > >> >> > >>>> apache.hadoop.hbase.backup.master.
> > > LogRollMasterProcedureManager
> > > >> >> > >>>> hbase.procedure.regionserver.classes=YOUR_CLASSES,org.
> > > >> >> > >>>> apache.hadoop.hbase.backup.regionserver.
> > > >> >> > LogRollRegionServerProcedureMa
> > > >> >> > >>>> nager
> > > >> >> > >>>>
> > > >> >> > >>>>
> > > >> >> > >>>> I would like to thank IBM team and Jerry He for original
> > work,
> > > >> >> > >>>>
> > > >> >> > >>>> Enis, Ted, Stack, Matteo, Jerry for time spent on code
> > reviews
> > > >> >> > >>>>
> > > >> >> > >>>> Special thanks to Ted Yu for his co-development work.
> > > >> >> > >>>>
> > > >> >> > >>>> References:
> > > >> >> > >>>>
> > > >> >> > >>>> https://issues.apache.org/jira/browse/HBASE-7912
> (original
> > > IBM,
> > > >> >> > >> contains
> > > >> >> > >>>> design doc)
> > > >> >> > >>>> https://issues.apache.org/jira/browse/HBASE-14030 (Phase
> 1)
> > > >> >> > >>>> https://issues.apache.org/jira/browse/HBASE-14123 (Phase
> 2)
> > > >> >> > >>>> https://issues.apache.org/jira/browse/HBASE-14414 (Phase
> 3)
> > > >> >> > >>>>
> > > >> >> > >>>> Please vote +1/-1 by midnight Pacific Time (00:00
> > > >> >> > >>>> -0800 GMT) on March 11th on whether or not we should
> merge
> > > >> this
> > > >> >> into
> > > >> >> > >> the
> > > >> >> > >>>> current master.
> > > >> >> > >>>>
> > > >> >> > >>>> -Vladimir Rodionov
> > > >> >> > >>>>
> > > >> >> > >>>
> > > >> >> > >>>
> > > >> >> > >>>
> > > >> >> > >>> --
> > > >> >> > >>> Best regards,
> > > >> >> > >>>
> > > >> >> > >>> - Andy
> > > >> >> > >>>
> > > >> >> > >>> If you are given a choice, you believe you have acted
> > freely. -
> > > >> >> Raymond
> > > >> >> > >>> Teller (via Peter Watts)
> > > >> >> > >>
> > > >> >> > >
> > > >> >> > >
> > > >> >> > >
> > > >> >> > > --
> > > >> >> > > Best regards,
> > > >> >> > >
> > > >> >> > > - Andy
> > > >> >> > >
> > > >> >> > > If you are given a choice, you believe you have acted
> freely. -
> > > >> >> Raymond
> > > >> >> > > Teller (via Peter Watts)
> > > >> >> >
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >> --
> > > >> >> Best regards,
> > > >> >>
> > > >> >> - Andy
> > > >> >>
> > > >> >> If you are given a choice, you believe you have acted freely. -
> > > Raymond
> > > >> >> Teller (via Peter Watts)
> > > >> >>
> > > >> >
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
>
--
Best regards,
- Andy
If you are given a choice, you believe you have acted freely. - Raymond
Teller (via Peter Watts)
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
Posted by Enis Söztutar <en...@apache.org>.
I think there is some misconception of using the term "blockers" for
referring to those jiras. My understanding is that those three jiras are
blockers for the backup functionality to be more mature and more usable.
But they are not release blockers. Let's say we merged the code in, and for
some reason those did not get addressed in time. We can still do the 2.0
release without having to wait for the commits. We can instead mark the
"backup" feature as experimental with known issues and go on with the
release. In that sense they are not real release 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
luxury of having to wait another couple of months and doing yet another
giant round of reviews because the code base is a moving target.
Enis
On Mon, Mar 13, 2017 at 3:46 PM, Devaraj Das <dd...@hortonworks.com> 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 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 to make the list of remaining work more complete by citing
> that as pending work.
> ________________________________________
> From: Vladimir Rodionov <vl...@gmail.com>
> 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 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 (including moving backup/restore out
> of
> >> core to live in its own module).
>
> For those who were not following our lengthy conversation on a review
> board, separation of a backup code into a separate module has been
> done last year, but has been reverted back by request of a reviewer.
>
>
> -Vladimir
>
> On Mon, Mar 13, 2017 at 2:23 PM, Stack <st...@duboce.net> wrote:
>
> > On Fri, Mar 10, 2017 at 9:09 PM, Stack <st...@duboce.net> wrote:
> >
> > > On Fri, Mar 10, 2017 at 6:01 PM, Ted Yu <yu...@gmail.com> 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 burned a bunch of dev resource).
> > >
> > > The patch as is is now in a state where it is too big for our infra; rb
> > > and JIRA are creaking under the size and # of iterations.
> > >
> > > Adding finish of new JIRAs to this merge implies a new round of review
> > and
> > > test of an already massive patch. Who is going to do this work?
> > >
> > > Going back to a new branch seems wrong route to take.
> > >
> > > St.Ack
> > >
> > >
> > >
> > To be more explicit, this patch was developed on a branch and then a
> bunch
> > of dev resources were burned getting it into a state where it could be
> > merged to master. Going back to a branch to bulk up the merge so it
> > includes more JIRAs than the many it already incorporates is the wrong
> > direction for us to be headed in. It ignores the feedback given and the
> > work done by Vladimir slimming down an already over-broad scope. It is
> also
> > predicated on abundant review and testing resource being on tap to cycle
> on
> > a feature that is useful, but non-core.
> >
> > The patch is ready for merge IMO. Geoffrey makes a nice list of what is
> > still to do though IIRC, the list is incomplete because a bunch of
> > follow-ons came of the review cycle (including moving backup/restore out
> of
> > core to live in its own module).
> >
> > The patch needs three votes to merge. I am not against merge but I am not
> > voting for the patch because I do have any more time to spend on this
> > non-core feature and feel that a vote will have me assume a
> responsibility
> > I will not shirk.
> >
> > S
> >
> >
> >
> > >
> > >
> > >
> > >> FYI
> > >>
> > >> On Fri, Mar 10, 2017 at 3:30 PM, Ted Yu <yu...@gmail.com> 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 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,
> we
> > >> > propose to community for merging into branch-2 (master branch, if
> > >> branch-2
> > >> > doesn't materialize for whatever reason) again
> > >> >
> > >> > Cheers
> > >> >
> > >> >
> > >> > On Fri, Mar 10, 2017 at 3:01 PM, Andrew Purtell <
> apurtell@apache.org>
> > >> > wrote:
> > >> >
> > >> >> 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 the documentation issue is important but not actually a
> > >> blocker.
> > >> >> That may be a controversial opinion, but documentation can be
> > >> back-filled
> > >> >> worst case. So take HBASE-17133 off the list.
> > >> >>
> > >> >> Remaining are effectively HBASE-14417, HBASE-14141, and
> HBASE-15227.
> > >> They
> > >> >> all have patches attached to the respective JIRAs so completing
> this
> > >> work
> > >> >> won't be onerous. Get these committed and I will lift my -1. The
> > others
> > >> >> who
> > >> >> voted +1 on this thread surely can help with that.
> > >> >>
> > >> >> Thanks.
> > >> >>
> > >> >>
> > >> >> On Fri, Mar 10, 2017 at 2:32 PM, Vladimir Rodionov <
> > >> >> vladrodionov@gmail.com>
> > >> >> wrote:
> > >> >>
> > >> >> > 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 <
> apurtell@apache.org
> > >
> > >> >> 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
> > >> 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 prevent that release because these blockers will be
> > >> >> there. I
> > >> >> > am
> > >> >> > > inclined to veto. Probably we should not propose branch merges
> > into
> > >> >> code
> > >> >> > we
> > >> >> > > are trying to get out the door with known blockers. Why not do
> > that
> > >> >> work
> > >> >> > > first? It seems an obvious question. Perhaps I am missing
> > >> something.
> > >> >> > >
> > >> >> > > If we can branch for 2.0 now and then merge this, and not into
> > the
> > >> 2.0
> > >> >> > > branch, I would vote +1 for branch merge even with known
> blockers
> > >> >> > pending.
> > >> >> > >
> > >> >> > >
> > >> >> > > On Fri, Mar 10, 2017 at 1:42 PM, Vladimir Rodionov <
> > >> >> > vladrodionov@gmail.com>
> > >> >> > > wrote:
> > >> >> > >
> > >> >> > >> 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 <
> > apurtell@apache.org
> > >> >
> > >> >> > wrote:
> > >> >> > >>
> > >> >> > >>>> 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 <
> > >> >> > >> vladrodionov@gmail.com>
> > >> >> > >>> wrote:
> > >> >> > >>>
> > >> >> > >>>> 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 reviews
> and
> > >> has
> > >> >> > >> probably
> > >> >> > >>>> the most lengthy discussion thread on Apache JIRA
> > (HBASE-14123)
> > >> :)
> > >> >> > >>>>
> > >> >> > >>>> The work has been split into 3 phases (HBASE-14030, 14123,
> > >> 14414)
> > >> >> Two
> > >> >> > >> first
> > >> >> > >>>> are complete, third one is still in progress.
> > >> >> > >>>>
> > >> >> > >>>>
> > >> >> > >>>> *** Summary of work HBASE-14123
> > >> >> > >>>>
> > >> >> > >>>> The new feature introduces new command-line extensions to
> the
> > >> hbase
> > >> >> > >> command
> > >> >> > >>>> and, from the client side, is accessible through
> command-line
> > >> only
> > >> >> > >>>> Operations:
> > >> >> > >>>> * Create full backup on a list of tables or backup set
> > >> >> > >>>> * Create incremental backup image for table list or backup
> set
> > >> >> > >>>> * Restore list of tables from a given backup image
> > >> >> > >>>> * Show current backup progress
> > >> >> > >>>> * Delete backup image and all related images
> > >> >> > >>>> * Show history of backups
> > >> >> > >>>> * Backup set operations: create backup set, add/remove table
> > >> >> to/from
> > >> >> > >> backup
> > >> >> > >>>> set, etc
> > >> >> > >>>>
> > >> >> > >>>> In the current implementation, the feature is already
> usable,
> > >> >> meaning
> > >> >> > >> that
> > >> >> > >>>> users can backup tables and restore them using provided
> > >> >> command-line
> > >> >> > >> tools.
> > >> >> > >>>> Both: full and incremental backups are supported.
> > >> >> > >>>> This work is based on original work of IBM team
> (HBASE-7912).
> > >> The
> > >> >> full
> > >> >> > >> list
> > >> >> > >>>> of JIRAs included in this mega patch can be found in three
> > >> umbrella
> > >> >> > >> JIRAs:
> > >> >> > >>>> HBASE-14030 (Phase 1), HBASE-14123 (Phase 2) and HBASE-14414
> > >> >> (Phase 3
> > >> >> > -
> > >> >> > >> all
> > >> >> > >>>> resolved ones made it into the patch)
> > >> >> > >>>>
> > >> >> > >>>> *** What are the remaining work items
> > >> >> > >>>>
> > >> >> > >>>> All remaining items can be found in Phase 3 umbrella JIRA:
> > >> >> > HBASE-14414.
> > >> >> > >>>> They are split into 3 groups: BLOCKER, CRITICAL, MAJOR
> > >> >> > >>>> Only BLOCKERs and CRITICALs are guaranteed for HBase 2.0
> > >> release.
> > >> >> > >>>>
> > >> >> > >>>> ***** BLOCKER
> > >> >> > >>>>
> > >> >> > >>>> * HBASE-14417 Incremental backup and bulk loading ( Patch
> > >> >> available)
> > >> >> > >>>> * HBASE-14135 HBase Backup/Restore Phase 3: Merge backup
> > images
> > >> >> > >>>> * HBASE-14141 HBase Backup/Restore Phase 3: Filter WALs on
> > >> backup
> > >> >> to
> > >> >> > >>>> include only edits from backup tables (Patch available)
> > >> >> > >>>> * HBASE-17133 Backup documentation
> > >> >> > >>>> * HBASE-15227 Fault tolerance support
> > >> >> > >>>>
> > >> >> > >>>> ***** CRITICAL
> > >> >> > >>>>
> > >> >> > >>>> * HBASE-16465 Disable split/merges during backup
> > >> >> > >>>>
> > >> >> > >>>> We have umbrella JIRA (HBASE-14414) to track all the
> remaining
> > >> work
> > >> >> > >>>> All the BLOCKER and CRITICAL JIRAs currently in open state
> > will
> > >> be
> > >> >> > >>>> implemented by 2.0 release time. Some MAJOR too, but it
> > depends
> > >> on
> > >> >> > >> resource
> > >> >> > >>>> availability
> > >> >> > >>>> The former development branch (HBASE-7912) is obsolete and
> > will
> > >> be
> > >> >> > >>>> closed/deleted after the merge.
> > >> >> > >>>> We want backup to be a GA feature in 2.0
> > >> >> > >>>> We are going to support full backward compatibility for
> backup
> > >> >> tool in
> > >> >> > >> 2.0
> > >> >> > >>>> and onwards.
> > >> >> > >>>>
> > >> >> > >>>> **** Configuration
> > >> >> > >>>>
> > >> >> > >>>> Backup is disabled, by default. To enable it, the following
> > >> >> > >> configuration
> > >> >> > >>>> properties must be added to hbase-site.xml:
> > >> >> > >>>>
> > >> >> > >>>> hbase.backup.enable=true
> > >> >> > >>>> hbase.master.logcleaner.plugins=YOUR_PLUGINS,org.
> > >> >> > >>>> apache.hadoop.hbase.backup.master.BackupLogCleaner
> > >> >> > >>>> hbase.procedure.master.classes=YOUR_CLASSES,org.
> > >> >> > >>>> apache.hadoop.hbase.backup.master.
> > LogRollMasterProcedureManager
> > >> >> > >>>> hbase.procedure.regionserver.classes=YOUR_CLASSES,org.
> > >> >> > >>>> apache.hadoop.hbase.backup.regionserver.
> > >> >> > LogRollRegionServerProcedureMa
> > >> >> > >>>> nager
> > >> >> > >>>>
> > >> >> > >>>>
> > >> >> > >>>> I would like to thank IBM team and Jerry He for original
> work,
> > >> >> > >>>>
> > >> >> > >>>> Enis, Ted, Stack, Matteo, Jerry for time spent on code
> reviews
> > >> >> > >>>>
> > >> >> > >>>> Special thanks to Ted Yu for his co-development work.
> > >> >> > >>>>
> > >> >> > >>>> References:
> > >> >> > >>>>
> > >> >> > >>>> https://issues.apache.org/jira/browse/HBASE-7912 (original
> > IBM,
> > >> >> > >> contains
> > >> >> > >>>> design doc)
> > >> >> > >>>> https://issues.apache.org/jira/browse/HBASE-14030 (Phase 1)
> > >> >> > >>>> https://issues.apache.org/jira/browse/HBASE-14123 (Phase 2)
> > >> >> > >>>> https://issues.apache.org/jira/browse/HBASE-14414 (Phase 3)
> > >> >> > >>>>
> > >> >> > >>>> Please vote +1/-1 by midnight Pacific Time (00:00
> > >> >> > >>>> -0800 GMT) on March 11th on whether or not we should merge
> > >> this
> > >> >> into
> > >> >> > >> the
> > >> >> > >>>> current master.
> > >> >> > >>>>
> > >> >> > >>>> -Vladimir Rodionov
> > >> >> > >>>>
> > >> >> > >>>
> > >> >> > >>>
> > >> >> > >>>
> > >> >> > >>> --
> > >> >> > >>> Best regards,
> > >> >> > >>>
> > >> >> > >>> - Andy
> > >> >> > >>>
> > >> >> > >>> If you are given a choice, you believe you have acted
> freely. -
> > >> >> Raymond
> > >> >> > >>> Teller (via Peter Watts)
> > >> >> > >>
> > >> >> > >
> > >> >> > >
> > >> >> > >
> > >> >> > > --
> > >> >> > > Best regards,
> > >> >> > >
> > >> >> > > - Andy
> > >> >> > >
> > >> >> > > If you are given a choice, you believe you have acted freely. -
> > >> >> Raymond
> > >> >> > > Teller (via Peter Watts)
> > >> >> >
> > >> >>
> > >> >>
> > >> >>
> > >> >> --
> > >> >> Best regards,
> > >> >>
> > >> >> - Andy
> > >> >>
> > >> >> If you are given a choice, you believe you have acted freely. -
> > Raymond
> > >> >> Teller (via Peter Watts)
> > >> >>
> > >> >
> > >> >
> > >>
> > >
> > >
> >
>
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing
3/11/2017
Posted by Devaraj Das <dd...@hortonworks.com>.
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 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 to make the list of remaining work more complete by citing that as pending work.
________________________________________
From: Vladimir Rodionov <vl...@gmail.com>
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 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 (including moving backup/restore out
of
>> core to live in its own module).
For those who were not following our lengthy conversation on a review
board, separation of a backup code into a separate module has been
done last year, but has been reverted back by request of a reviewer.
-Vladimir
On Mon, Mar 13, 2017 at 2:23 PM, Stack <st...@duboce.net> wrote:
> On Fri, Mar 10, 2017 at 9:09 PM, Stack <st...@duboce.net> wrote:
>
> > On Fri, Mar 10, 2017 at 6:01 PM, Ted Yu <yu...@gmail.com> 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 burned a bunch of dev resource).
> >
> > The patch as is is now in a state where it is too big for our infra; rb
> > and JIRA are creaking under the size and # of iterations.
> >
> > Adding finish of new JIRAs to this merge implies a new round of review
> and
> > test of an already massive patch. Who is going to do this work?
> >
> > Going back to a new branch seems wrong route to take.
> >
> > St.Ack
> >
> >
> >
> To be more explicit, this patch was developed on a branch and then a bunch
> of dev resources were burned getting it into a state where it could be
> merged to master. Going back to a branch to bulk up the merge so it
> includes more JIRAs than the many it already incorporates is the wrong
> direction for us to be headed in. It ignores the feedback given and the
> work done by Vladimir slimming down an already over-broad scope. It is also
> predicated on abundant review and testing resource being on tap to cycle on
> a feature that is useful, but non-core.
>
> The patch is ready for merge IMO. Geoffrey makes a nice list of what is
> still to do though IIRC, the list is incomplete because a bunch of
> follow-ons came of the review cycle (including moving backup/restore out of
> core to live in its own module).
>
> The patch needs three votes to merge. I am not against merge but I am not
> voting for the patch because I do have any more time to spend on this
> non-core feature and feel that a vote will have me assume a responsibility
> I will not shirk.
>
> S
>
>
>
> >
> >
> >
> >> FYI
> >>
> >> On Fri, Mar 10, 2017 at 3:30 PM, Ted Yu <yu...@gmail.com> 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 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, we
> >> > propose to community for merging into branch-2 (master branch, if
> >> branch-2
> >> > doesn't materialize for whatever reason) again
> >> >
> >> > Cheers
> >> >
> >> >
> >> > On Fri, Mar 10, 2017 at 3:01 PM, Andrew Purtell <ap...@apache.org>
> >> > wrote:
> >> >
> >> >> 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 the documentation issue is important but not actually a
> >> blocker.
> >> >> That may be a controversial opinion, but documentation can be
> >> back-filled
> >> >> worst case. So take HBASE-17133 off the list.
> >> >>
> >> >> Remaining are effectively HBASE-14417, HBASE-14141, and HBASE-15227.
> >> They
> >> >> all have patches attached to the respective JIRAs so completing this
> >> work
> >> >> won't be onerous. Get these committed and I will lift my -1. The
> others
> >> >> who
> >> >> voted +1 on this thread surely can help with that.
> >> >>
> >> >> Thanks.
> >> >>
> >> >>
> >> >> On Fri, Mar 10, 2017 at 2:32 PM, Vladimir Rodionov <
> >> >> vladrodionov@gmail.com>
> >> >> wrote:
> >> >>
> >> >> > 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 <apurtell@apache.org
> >
> >> >> 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
> >> 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 prevent that release because these blockers will be
> >> >> there. I
> >> >> > am
> >> >> > > inclined to veto. Probably we should not propose branch merges
> into
> >> >> code
> >> >> > we
> >> >> > > are trying to get out the door with known blockers. Why not do
> that
> >> >> work
> >> >> > > first? It seems an obvious question. Perhaps I am missing
> >> something.
> >> >> > >
> >> >> > > If we can branch for 2.0 now and then merge this, and not into
> the
> >> 2.0
> >> >> > > branch, I would vote +1 for branch merge even with known blockers
> >> >> > pending.
> >> >> > >
> >> >> > >
> >> >> > > On Fri, Mar 10, 2017 at 1:42 PM, Vladimir Rodionov <
> >> >> > vladrodionov@gmail.com>
> >> >> > > wrote:
> >> >> > >
> >> >> > >> 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 <
> apurtell@apache.org
> >> >
> >> >> > wrote:
> >> >> > >>
> >> >> > >>>> 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 <
> >> >> > >> vladrodionov@gmail.com>
> >> >> > >>> wrote:
> >> >> > >>>
> >> >> > >>>> 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 reviews and
> >> has
> >> >> > >> probably
> >> >> > >>>> the most lengthy discussion thread on Apache JIRA
> (HBASE-14123)
> >> :)
> >> >> > >>>>
> >> >> > >>>> The work has been split into 3 phases (HBASE-14030, 14123,
> >> 14414)
> >> >> Two
> >> >> > >> first
> >> >> > >>>> are complete, third one is still in progress.
> >> >> > >>>>
> >> >> > >>>>
> >> >> > >>>> *** Summary of work HBASE-14123
> >> >> > >>>>
> >> >> > >>>> The new feature introduces new command-line extensions to the
> >> hbase
> >> >> > >> command
> >> >> > >>>> and, from the client side, is accessible through command-line
> >> only
> >> >> > >>>> Operations:
> >> >> > >>>> * Create full backup on a list of tables or backup set
> >> >> > >>>> * Create incremental backup image for table list or backup set
> >> >> > >>>> * Restore list of tables from a given backup image
> >> >> > >>>> * Show current backup progress
> >> >> > >>>> * Delete backup image and all related images
> >> >> > >>>> * Show history of backups
> >> >> > >>>> * Backup set operations: create backup set, add/remove table
> >> >> to/from
> >> >> > >> backup
> >> >> > >>>> set, etc
> >> >> > >>>>
> >> >> > >>>> In the current implementation, the feature is already usable,
> >> >> meaning
> >> >> > >> that
> >> >> > >>>> users can backup tables and restore them using provided
> >> >> command-line
> >> >> > >> tools.
> >> >> > >>>> Both: full and incremental backups are supported.
> >> >> > >>>> This work is based on original work of IBM team (HBASE-7912).
> >> The
> >> >> full
> >> >> > >> list
> >> >> > >>>> of JIRAs included in this mega patch can be found in three
> >> umbrella
> >> >> > >> JIRAs:
> >> >> > >>>> HBASE-14030 (Phase 1), HBASE-14123 (Phase 2) and HBASE-14414
> >> >> (Phase 3
> >> >> > -
> >> >> > >> all
> >> >> > >>>> resolved ones made it into the patch)
> >> >> > >>>>
> >> >> > >>>> *** What are the remaining work items
> >> >> > >>>>
> >> >> > >>>> All remaining items can be found in Phase 3 umbrella JIRA:
> >> >> > HBASE-14414.
> >> >> > >>>> They are split into 3 groups: BLOCKER, CRITICAL, MAJOR
> >> >> > >>>> Only BLOCKERs and CRITICALs are guaranteed for HBase 2.0
> >> release.
> >> >> > >>>>
> >> >> > >>>> ***** BLOCKER
> >> >> > >>>>
> >> >> > >>>> * HBASE-14417 Incremental backup and bulk loading ( Patch
> >> >> available)
> >> >> > >>>> * HBASE-14135 HBase Backup/Restore Phase 3: Merge backup
> images
> >> >> > >>>> * HBASE-14141 HBase Backup/Restore Phase 3: Filter WALs on
> >> backup
> >> >> to
> >> >> > >>>> include only edits from backup tables (Patch available)
> >> >> > >>>> * HBASE-17133 Backup documentation
> >> >> > >>>> * HBASE-15227 Fault tolerance support
> >> >> > >>>>
> >> >> > >>>> ***** CRITICAL
> >> >> > >>>>
> >> >> > >>>> * HBASE-16465 Disable split/merges during backup
> >> >> > >>>>
> >> >> > >>>> We have umbrella JIRA (HBASE-14414) to track all the remaining
> >> work
> >> >> > >>>> All the BLOCKER and CRITICAL JIRAs currently in open state
> will
> >> be
> >> >> > >>>> implemented by 2.0 release time. Some MAJOR too, but it
> depends
> >> on
> >> >> > >> resource
> >> >> > >>>> availability
> >> >> > >>>> The former development branch (HBASE-7912) is obsolete and
> will
> >> be
> >> >> > >>>> closed/deleted after the merge.
> >> >> > >>>> We want backup to be a GA feature in 2.0
> >> >> > >>>> We are going to support full backward compatibility for backup
> >> >> tool in
> >> >> > >> 2.0
> >> >> > >>>> and onwards.
> >> >> > >>>>
> >> >> > >>>> **** Configuration
> >> >> > >>>>
> >> >> > >>>> Backup is disabled, by default. To enable it, the following
> >> >> > >> configuration
> >> >> > >>>> properties must be added to hbase-site.xml:
> >> >> > >>>>
> >> >> > >>>> hbase.backup.enable=true
> >> >> > >>>> hbase.master.logcleaner.plugins=YOUR_PLUGINS,org.
> >> >> > >>>> apache.hadoop.hbase.backup.master.BackupLogCleaner
> >> >> > >>>> hbase.procedure.master.classes=YOUR_CLASSES,org.
> >> >> > >>>> apache.hadoop.hbase.backup.master.
> LogRollMasterProcedureManager
> >> >> > >>>> hbase.procedure.regionserver.classes=YOUR_CLASSES,org.
> >> >> > >>>> apache.hadoop.hbase.backup.regionserver.
> >> >> > LogRollRegionServerProcedureMa
> >> >> > >>>> nager
> >> >> > >>>>
> >> >> > >>>>
> >> >> > >>>> I would like to thank IBM team and Jerry He for original work,
> >> >> > >>>>
> >> >> > >>>> Enis, Ted, Stack, Matteo, Jerry for time spent on code reviews
> >> >> > >>>>
> >> >> > >>>> Special thanks to Ted Yu for his co-development work.
> >> >> > >>>>
> >> >> > >>>> References:
> >> >> > >>>>
> >> >> > >>>> https://issues.apache.org/jira/browse/HBASE-7912 (original
> IBM,
> >> >> > >> contains
> >> >> > >>>> design doc)
> >> >> > >>>> https://issues.apache.org/jira/browse/HBASE-14030 (Phase 1)
> >> >> > >>>> https://issues.apache.org/jira/browse/HBASE-14123 (Phase 2)
> >> >> > >>>> https://issues.apache.org/jira/browse/HBASE-14414 (Phase 3)
> >> >> > >>>>
> >> >> > >>>> Please vote +1/-1 by midnight Pacific Time (00:00
> >> >> > >>>> -0800 GMT) on March 11th on whether or not we should merge
> >> this
> >> >> into
> >> >> > >> the
> >> >> > >>>> current master.
> >> >> > >>>>
> >> >> > >>>> -Vladimir Rodionov
> >> >> > >>>>
> >> >> > >>>
> >> >> > >>>
> >> >> > >>>
> >> >> > >>> --
> >> >> > >>> Best regards,
> >> >> > >>>
> >> >> > >>> - Andy
> >> >> > >>>
> >> >> > >>> If you are given a choice, you believe you have acted freely. -
> >> >> Raymond
> >> >> > >>> Teller (via Peter Watts)
> >> >> > >>
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > > --
> >> >> > > Best regards,
> >> >> > >
> >> >> > > - Andy
> >> >> > >
> >> >> > > If you are given a choice, you believe you have acted freely. -
> >> >> Raymond
> >> >> > > Teller (via Peter Watts)
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Best regards,
> >> >>
> >> >> - Andy
> >> >>
> >> >> If you are given a choice, you believe you have acted freely. -
> Raymond
> >> >> Teller (via Peter Watts)
> >> >>
> >> >
> >> >
> >>
> >
> >
>
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
Posted by Vladimir Rodionov <vl...@gmail.com>.
>> 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 (including moving backup/restore out
of
>> core to live in its own module).
For those who were not following our lengthy conversation on a review
board, separation of a backup code into a separate module has been
done last year, but has been reverted back by request of a reviewer.
-Vladimir
On Mon, Mar 13, 2017 at 2:23 PM, Stack <st...@duboce.net> wrote:
> On Fri, Mar 10, 2017 at 9:09 PM, Stack <st...@duboce.net> wrote:
>
> > On Fri, Mar 10, 2017 at 6:01 PM, Ted Yu <yu...@gmail.com> 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 burned a bunch of dev resource).
> >
> > The patch as is is now in a state where it is too big for our infra; rb
> > and JIRA are creaking under the size and # of iterations.
> >
> > Adding finish of new JIRAs to this merge implies a new round of review
> and
> > test of an already massive patch. Who is going to do this work?
> >
> > Going back to a new branch seems wrong route to take.
> >
> > St.Ack
> >
> >
> >
> To be more explicit, this patch was developed on a branch and then a bunch
> of dev resources were burned getting it into a state where it could be
> merged to master. Going back to a branch to bulk up the merge so it
> includes more JIRAs than the many it already incorporates is the wrong
> direction for us to be headed in. It ignores the feedback given and the
> work done by Vladimir slimming down an already over-broad scope. It is also
> predicated on abundant review and testing resource being on tap to cycle on
> a feature that is useful, but non-core.
>
> The patch is ready for merge IMO. Geoffrey makes a nice list of what is
> still to do though IIRC, the list is incomplete because a bunch of
> follow-ons came of the review cycle (including moving backup/restore out of
> core to live in its own module).
>
> The patch needs three votes to merge. I am not against merge but I am not
> voting for the patch because I do have any more time to spend on this
> non-core feature and feel that a vote will have me assume a responsibility
> I will not shirk.
>
> S
>
>
>
> >
> >
> >
> >> FYI
> >>
> >> On Fri, Mar 10, 2017 at 3:30 PM, Ted Yu <yu...@gmail.com> 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 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, we
> >> > propose to community for merging into branch-2 (master branch, if
> >> branch-2
> >> > doesn't materialize for whatever reason) again
> >> >
> >> > Cheers
> >> >
> >> >
> >> > On Fri, Mar 10, 2017 at 3:01 PM, Andrew Purtell <ap...@apache.org>
> >> > wrote:
> >> >
> >> >> 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 the documentation issue is important but not actually a
> >> blocker.
> >> >> That may be a controversial opinion, but documentation can be
> >> back-filled
> >> >> worst case. So take HBASE-17133 off the list.
> >> >>
> >> >> Remaining are effectively HBASE-14417, HBASE-14141, and HBASE-15227.
> >> They
> >> >> all have patches attached to the respective JIRAs so completing this
> >> work
> >> >> won't be onerous. Get these committed and I will lift my -1. The
> others
> >> >> who
> >> >> voted +1 on this thread surely can help with that.
> >> >>
> >> >> Thanks.
> >> >>
> >> >>
> >> >> On Fri, Mar 10, 2017 at 2:32 PM, Vladimir Rodionov <
> >> >> vladrodionov@gmail.com>
> >> >> wrote:
> >> >>
> >> >> > 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 <apurtell@apache.org
> >
> >> >> 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
> >> 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 prevent that release because these blockers will be
> >> >> there. I
> >> >> > am
> >> >> > > inclined to veto. Probably we should not propose branch merges
> into
> >> >> code
> >> >> > we
> >> >> > > are trying to get out the door with known blockers. Why not do
> that
> >> >> work
> >> >> > > first? It seems an obvious question. Perhaps I am missing
> >> something.
> >> >> > >
> >> >> > > If we can branch for 2.0 now and then merge this, and not into
> the
> >> 2.0
> >> >> > > branch, I would vote +1 for branch merge even with known blockers
> >> >> > pending.
> >> >> > >
> >> >> > >
> >> >> > > On Fri, Mar 10, 2017 at 1:42 PM, Vladimir Rodionov <
> >> >> > vladrodionov@gmail.com>
> >> >> > > wrote:
> >> >> > >
> >> >> > >> 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 <
> apurtell@apache.org
> >> >
> >> >> > wrote:
> >> >> > >>
> >> >> > >>>> 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 <
> >> >> > >> vladrodionov@gmail.com>
> >> >> > >>> wrote:
> >> >> > >>>
> >> >> > >>>> 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 reviews and
> >> has
> >> >> > >> probably
> >> >> > >>>> the most lengthy discussion thread on Apache JIRA
> (HBASE-14123)
> >> :)
> >> >> > >>>>
> >> >> > >>>> The work has been split into 3 phases (HBASE-14030, 14123,
> >> 14414)
> >> >> Two
> >> >> > >> first
> >> >> > >>>> are complete, third one is still in progress.
> >> >> > >>>>
> >> >> > >>>>
> >> >> > >>>> *** Summary of work HBASE-14123
> >> >> > >>>>
> >> >> > >>>> The new feature introduces new command-line extensions to the
> >> hbase
> >> >> > >> command
> >> >> > >>>> and, from the client side, is accessible through command-line
> >> only
> >> >> > >>>> Operations:
> >> >> > >>>> * Create full backup on a list of tables or backup set
> >> >> > >>>> * Create incremental backup image for table list or backup set
> >> >> > >>>> * Restore list of tables from a given backup image
> >> >> > >>>> * Show current backup progress
> >> >> > >>>> * Delete backup image and all related images
> >> >> > >>>> * Show history of backups
> >> >> > >>>> * Backup set operations: create backup set, add/remove table
> >> >> to/from
> >> >> > >> backup
> >> >> > >>>> set, etc
> >> >> > >>>>
> >> >> > >>>> In the current implementation, the feature is already usable,
> >> >> meaning
> >> >> > >> that
> >> >> > >>>> users can backup tables and restore them using provided
> >> >> command-line
> >> >> > >> tools.
> >> >> > >>>> Both: full and incremental backups are supported.
> >> >> > >>>> This work is based on original work of IBM team (HBASE-7912).
> >> The
> >> >> full
> >> >> > >> list
> >> >> > >>>> of JIRAs included in this mega patch can be found in three
> >> umbrella
> >> >> > >> JIRAs:
> >> >> > >>>> HBASE-14030 (Phase 1), HBASE-14123 (Phase 2) and HBASE-14414
> >> >> (Phase 3
> >> >> > -
> >> >> > >> all
> >> >> > >>>> resolved ones made it into the patch)
> >> >> > >>>>
> >> >> > >>>> *** What are the remaining work items
> >> >> > >>>>
> >> >> > >>>> All remaining items can be found in Phase 3 umbrella JIRA:
> >> >> > HBASE-14414.
> >> >> > >>>> They are split into 3 groups: BLOCKER, CRITICAL, MAJOR
> >> >> > >>>> Only BLOCKERs and CRITICALs are guaranteed for HBase 2.0
> >> release.
> >> >> > >>>>
> >> >> > >>>> ***** BLOCKER
> >> >> > >>>>
> >> >> > >>>> * HBASE-14417 Incremental backup and bulk loading ( Patch
> >> >> available)
> >> >> > >>>> * HBASE-14135 HBase Backup/Restore Phase 3: Merge backup
> images
> >> >> > >>>> * HBASE-14141 HBase Backup/Restore Phase 3: Filter WALs on
> >> backup
> >> >> to
> >> >> > >>>> include only edits from backup tables (Patch available)
> >> >> > >>>> * HBASE-17133 Backup documentation
> >> >> > >>>> * HBASE-15227 Fault tolerance support
> >> >> > >>>>
> >> >> > >>>> ***** CRITICAL
> >> >> > >>>>
> >> >> > >>>> * HBASE-16465 Disable split/merges during backup
> >> >> > >>>>
> >> >> > >>>> We have umbrella JIRA (HBASE-14414) to track all the remaining
> >> work
> >> >> > >>>> All the BLOCKER and CRITICAL JIRAs currently in open state
> will
> >> be
> >> >> > >>>> implemented by 2.0 release time. Some MAJOR too, but it
> depends
> >> on
> >> >> > >> resource
> >> >> > >>>> availability
> >> >> > >>>> The former development branch (HBASE-7912) is obsolete and
> will
> >> be
> >> >> > >>>> closed/deleted after the merge.
> >> >> > >>>> We want backup to be a GA feature in 2.0
> >> >> > >>>> We are going to support full backward compatibility for backup
> >> >> tool in
> >> >> > >> 2.0
> >> >> > >>>> and onwards.
> >> >> > >>>>
> >> >> > >>>> **** Configuration
> >> >> > >>>>
> >> >> > >>>> Backup is disabled, by default. To enable it, the following
> >> >> > >> configuration
> >> >> > >>>> properties must be added to hbase-site.xml:
> >> >> > >>>>
> >> >> > >>>> hbase.backup.enable=true
> >> >> > >>>> hbase.master.logcleaner.plugins=YOUR_PLUGINS,org.
> >> >> > >>>> apache.hadoop.hbase.backup.master.BackupLogCleaner
> >> >> > >>>> hbase.procedure.master.classes=YOUR_CLASSES,org.
> >> >> > >>>> apache.hadoop.hbase.backup.master.
> LogRollMasterProcedureManager
> >> >> > >>>> hbase.procedure.regionserver.classes=YOUR_CLASSES,org.
> >> >> > >>>> apache.hadoop.hbase.backup.regionserver.
> >> >> > LogRollRegionServerProcedureMa
> >> >> > >>>> nager
> >> >> > >>>>
> >> >> > >>>>
> >> >> > >>>> I would like to thank IBM team and Jerry He for original work,
> >> >> > >>>>
> >> >> > >>>> Enis, Ted, Stack, Matteo, Jerry for time spent on code reviews
> >> >> > >>>>
> >> >> > >>>> Special thanks to Ted Yu for his co-development work.
> >> >> > >>>>
> >> >> > >>>> References:
> >> >> > >>>>
> >> >> > >>>> https://issues.apache.org/jira/browse/HBASE-7912 (original
> IBM,
> >> >> > >> contains
> >> >> > >>>> design doc)
> >> >> > >>>> https://issues.apache.org/jira/browse/HBASE-14030 (Phase 1)
> >> >> > >>>> https://issues.apache.org/jira/browse/HBASE-14123 (Phase 2)
> >> >> > >>>> https://issues.apache.org/jira/browse/HBASE-14414 (Phase 3)
> >> >> > >>>>
> >> >> > >>>> Please vote +1/-1 by midnight Pacific Time (00:00
> >> >> > >>>> -0800 GMT) on March 11th on whether or not we should merge
> >> this
> >> >> into
> >> >> > >> the
> >> >> > >>>> current master.
> >> >> > >>>>
> >> >> > >>>> -Vladimir Rodionov
> >> >> > >>>>
> >> >> > >>>
> >> >> > >>>
> >> >> > >>>
> >> >> > >>> --
> >> >> > >>> Best regards,
> >> >> > >>>
> >> >> > >>> - Andy
> >> >> > >>>
> >> >> > >>> If you are given a choice, you believe you have acted freely. -
> >> >> Raymond
> >> >> > >>> Teller (via Peter Watts)
> >> >> > >>
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > > --
> >> >> > > Best regards,
> >> >> > >
> >> >> > > - Andy
> >> >> > >
> >> >> > > If you are given a choice, you believe you have acted freely. -
> >> >> Raymond
> >> >> > > Teller (via Peter Watts)
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Best regards,
> >> >>
> >> >> - Andy
> >> >>
> >> >> If you are given a choice, you believe you have acted freely. -
> Raymond
> >> >> Teller (via Peter Watts)
> >> >>
> >> >
> >> >
> >>
> >
> >
>
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
Posted by Stack <st...@duboce.net>.
On Fri, Mar 10, 2017 at 9:09 PM, Stack <st...@duboce.net> wrote:
> On Fri, Mar 10, 2017 at 6:01 PM, Ted Yu <yu...@gmail.com> 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 burned a bunch of dev resource).
>
> The patch as is is now in a state where it is too big for our infra; rb
> and JIRA are creaking under the size and # of iterations.
>
> Adding finish of new JIRAs to this merge implies a new round of review and
> test of an already massive patch. Who is going to do this work?
>
> Going back to a new branch seems wrong route to take.
>
> St.Ack
>
>
>
To be more explicit, this patch was developed on a branch and then a bunch
of dev resources were burned getting it into a state where it could be
merged to master. Going back to a branch to bulk up the merge so it
includes more JIRAs than the many it already incorporates is the wrong
direction for us to be headed in. It ignores the feedback given and the
work done by Vladimir slimming down an already over-broad scope. It is also
predicated on abundant review and testing resource being on tap to cycle on
a feature that is useful, but non-core.
The patch is ready for merge IMO. Geoffrey makes a nice list of what is
still to do though IIRC, the list is incomplete because a bunch of
follow-ons came of the review cycle (including moving backup/restore out of
core to live in its own module).
The patch needs three votes to merge. I am not against merge but I am not
voting for the patch because I do have any more time to spend on this
non-core feature and feel that a vote will have me assume a responsibility
I will not shirk.
S
>
>
>
>> FYI
>>
>> On Fri, Mar 10, 2017 at 3:30 PM, Ted Yu <yu...@gmail.com> 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 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, we
>> > propose to community for merging into branch-2 (master branch, if
>> branch-2
>> > doesn't materialize for whatever reason) again
>> >
>> > Cheers
>> >
>> >
>> > On Fri, Mar 10, 2017 at 3:01 PM, Andrew Purtell <ap...@apache.org>
>> > wrote:
>> >
>> >> 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 the documentation issue is important but not actually a
>> blocker.
>> >> That may be a controversial opinion, but documentation can be
>> back-filled
>> >> worst case. So take HBASE-17133 off the list.
>> >>
>> >> Remaining are effectively HBASE-14417, HBASE-14141, and HBASE-15227.
>> They
>> >> all have patches attached to the respective JIRAs so completing this
>> work
>> >> won't be onerous. Get these committed and I will lift my -1. The others
>> >> who
>> >> voted +1 on this thread surely can help with that.
>> >>
>> >> Thanks.
>> >>
>> >>
>> >> On Fri, Mar 10, 2017 at 2:32 PM, Vladimir Rodionov <
>> >> vladrodionov@gmail.com>
>> >> wrote:
>> >>
>> >> > 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 <ap...@apache.org>
>> >> 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
>> 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 prevent that release because these blockers will be
>> >> there. I
>> >> > am
>> >> > > inclined to veto. Probably we should not propose branch merges into
>> >> code
>> >> > we
>> >> > > are trying to get out the door with known blockers. Why not do that
>> >> work
>> >> > > first? It seems an obvious question. Perhaps I am missing
>> something.
>> >> > >
>> >> > > If we can branch for 2.0 now and then merge this, and not into the
>> 2.0
>> >> > > branch, I would vote +1 for branch merge even with known blockers
>> >> > pending.
>> >> > >
>> >> > >
>> >> > > On Fri, Mar 10, 2017 at 1:42 PM, Vladimir Rodionov <
>> >> > vladrodionov@gmail.com>
>> >> > > wrote:
>> >> > >
>> >> > >> 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 <apurtell@apache.org
>> >
>> >> > wrote:
>> >> > >>
>> >> > >>>> 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 <
>> >> > >> vladrodionov@gmail.com>
>> >> > >>> wrote:
>> >> > >>>
>> >> > >>>> 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 reviews and
>> has
>> >> > >> probably
>> >> > >>>> the most lengthy discussion thread on Apache JIRA (HBASE-14123)
>> :)
>> >> > >>>>
>> >> > >>>> The work has been split into 3 phases (HBASE-14030, 14123,
>> 14414)
>> >> Two
>> >> > >> first
>> >> > >>>> are complete, third one is still in progress.
>> >> > >>>>
>> >> > >>>>
>> >> > >>>> *** Summary of work HBASE-14123
>> >> > >>>>
>> >> > >>>> The new feature introduces new command-line extensions to the
>> hbase
>> >> > >> command
>> >> > >>>> and, from the client side, is accessible through command-line
>> only
>> >> > >>>> Operations:
>> >> > >>>> * Create full backup on a list of tables or backup set
>> >> > >>>> * Create incremental backup image for table list or backup set
>> >> > >>>> * Restore list of tables from a given backup image
>> >> > >>>> * Show current backup progress
>> >> > >>>> * Delete backup image and all related images
>> >> > >>>> * Show history of backups
>> >> > >>>> * Backup set operations: create backup set, add/remove table
>> >> to/from
>> >> > >> backup
>> >> > >>>> set, etc
>> >> > >>>>
>> >> > >>>> In the current implementation, the feature is already usable,
>> >> meaning
>> >> > >> that
>> >> > >>>> users can backup tables and restore them using provided
>> >> command-line
>> >> > >> tools.
>> >> > >>>> Both: full and incremental backups are supported.
>> >> > >>>> This work is based on original work of IBM team (HBASE-7912).
>> The
>> >> full
>> >> > >> list
>> >> > >>>> of JIRAs included in this mega patch can be found in three
>> umbrella
>> >> > >> JIRAs:
>> >> > >>>> HBASE-14030 (Phase 1), HBASE-14123 (Phase 2) and HBASE-14414
>> >> (Phase 3
>> >> > -
>> >> > >> all
>> >> > >>>> resolved ones made it into the patch)
>> >> > >>>>
>> >> > >>>> *** What are the remaining work items
>> >> > >>>>
>> >> > >>>> All remaining items can be found in Phase 3 umbrella JIRA:
>> >> > HBASE-14414.
>> >> > >>>> They are split into 3 groups: BLOCKER, CRITICAL, MAJOR
>> >> > >>>> Only BLOCKERs and CRITICALs are guaranteed for HBase 2.0
>> release.
>> >> > >>>>
>> >> > >>>> ***** BLOCKER
>> >> > >>>>
>> >> > >>>> * HBASE-14417 Incremental backup and bulk loading ( Patch
>> >> available)
>> >> > >>>> * HBASE-14135 HBase Backup/Restore Phase 3: Merge backup images
>> >> > >>>> * HBASE-14141 HBase Backup/Restore Phase 3: Filter WALs on
>> backup
>> >> to
>> >> > >>>> include only edits from backup tables (Patch available)
>> >> > >>>> * HBASE-17133 Backup documentation
>> >> > >>>> * HBASE-15227 Fault tolerance support
>> >> > >>>>
>> >> > >>>> ***** CRITICAL
>> >> > >>>>
>> >> > >>>> * HBASE-16465 Disable split/merges during backup
>> >> > >>>>
>> >> > >>>> We have umbrella JIRA (HBASE-14414) to track all the remaining
>> work
>> >> > >>>> All the BLOCKER and CRITICAL JIRAs currently in open state will
>> be
>> >> > >>>> implemented by 2.0 release time. Some MAJOR too, but it depends
>> on
>> >> > >> resource
>> >> > >>>> availability
>> >> > >>>> The former development branch (HBASE-7912) is obsolete and will
>> be
>> >> > >>>> closed/deleted after the merge.
>> >> > >>>> We want backup to be a GA feature in 2.0
>> >> > >>>> We are going to support full backward compatibility for backup
>> >> tool in
>> >> > >> 2.0
>> >> > >>>> and onwards.
>> >> > >>>>
>> >> > >>>> **** Configuration
>> >> > >>>>
>> >> > >>>> Backup is disabled, by default. To enable it, the following
>> >> > >> configuration
>> >> > >>>> properties must be added to hbase-site.xml:
>> >> > >>>>
>> >> > >>>> hbase.backup.enable=true
>> >> > >>>> hbase.master.logcleaner.plugins=YOUR_PLUGINS,org.
>> >> > >>>> apache.hadoop.hbase.backup.master.BackupLogCleaner
>> >> > >>>> hbase.procedure.master.classes=YOUR_CLASSES,org.
>> >> > >>>> apache.hadoop.hbase.backup.master.LogRollMasterProcedureManager
>> >> > >>>> hbase.procedure.regionserver.classes=YOUR_CLASSES,org.
>> >> > >>>> apache.hadoop.hbase.backup.regionserver.
>> >> > LogRollRegionServerProcedureMa
>> >> > >>>> nager
>> >> > >>>>
>> >> > >>>>
>> >> > >>>> I would like to thank IBM team and Jerry He for original work,
>> >> > >>>>
>> >> > >>>> Enis, Ted, Stack, Matteo, Jerry for time spent on code reviews
>> >> > >>>>
>> >> > >>>> Special thanks to Ted Yu for his co-development work.
>> >> > >>>>
>> >> > >>>> References:
>> >> > >>>>
>> >> > >>>> https://issues.apache.org/jira/browse/HBASE-7912 (original IBM,
>> >> > >> contains
>> >> > >>>> design doc)
>> >> > >>>> https://issues.apache.org/jira/browse/HBASE-14030 (Phase 1)
>> >> > >>>> https://issues.apache.org/jira/browse/HBASE-14123 (Phase 2)
>> >> > >>>> https://issues.apache.org/jira/browse/HBASE-14414 (Phase 3)
>> >> > >>>>
>> >> > >>>> Please vote +1/-1 by midnight Pacific Time (00:00
>> >> > >>>> -0800 GMT) on March 11th on whether or not we should merge
>> this
>> >> into
>> >> > >> the
>> >> > >>>> current master.
>> >> > >>>>
>> >> > >>>> -Vladimir Rodionov
>> >> > >>>>
>> >> > >>>
>> >> > >>>
>> >> > >>>
>> >> > >>> --
>> >> > >>> Best regards,
>> >> > >>>
>> >> > >>> - Andy
>> >> > >>>
>> >> > >>> If you are given a choice, you believe you have acted freely. -
>> >> Raymond
>> >> > >>> Teller (via Peter Watts)
>> >> > >>
>> >> > >
>> >> > >
>> >> > >
>> >> > > --
>> >> > > Best regards,
>> >> > >
>> >> > > - Andy
>> >> > >
>> >> > > If you are given a choice, you believe you have acted freely. -
>> >> Raymond
>> >> > > Teller (via Peter Watts)
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Best regards,
>> >>
>> >> - Andy
>> >>
>> >> If you are given a choice, you believe you have acted freely. - Raymond
>> >> Teller (via Peter Watts)
>> >>
>> >
>> >
>>
>
>
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
Posted by Stack <st...@duboce.net>.
On Fri, Mar 10, 2017 at 6:01 PM, Ted Yu <yu...@gmail.com> 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 burned a bunch of dev resource).
The patch as is is now in a state where it is too big for our infra; rb and
JIRA are creaking under the size and # of iterations.
Adding finish of new JIRAs to this merge implies a new round of review and
test of an already massive patch. Who is going to do this work?
Going back to a new branch seems wrong route to take.
St.Ack
> FYI
>
> On Fri, Mar 10, 2017 at 3:30 PM, Ted Yu <yu...@gmail.com> 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 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, we
> > propose to community for merging into branch-2 (master branch, if
> branch-2
> > doesn't materialize for whatever reason) again
> >
> > Cheers
> >
> >
> > On Fri, Mar 10, 2017 at 3:01 PM, Andrew Purtell <ap...@apache.org>
> > wrote:
> >
> >> 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 the documentation issue is important but not actually a blocker.
> >> That may be a controversial opinion, but documentation can be
> back-filled
> >> worst case. So take HBASE-17133 off the list.
> >>
> >> Remaining are effectively HBASE-14417, HBASE-14141, and HBASE-15227.
> They
> >> all have patches attached to the respective JIRAs so completing this
> work
> >> won't be onerous. Get these committed and I will lift my -1. The others
> >> who
> >> voted +1 on this thread surely can help with that.
> >>
> >> Thanks.
> >>
> >>
> >> On Fri, Mar 10, 2017 at 2:32 PM, Vladimir Rodionov <
> >> vladrodionov@gmail.com>
> >> wrote:
> >>
> >> > 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 <ap...@apache.org>
> >> 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
> 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 prevent that release because these blockers will be
> >> there. I
> >> > am
> >> > > inclined to veto. Probably we should not propose branch merges into
> >> code
> >> > we
> >> > > are trying to get out the door with known blockers. Why not do that
> >> work
> >> > > first? It seems an obvious question. Perhaps I am missing something.
> >> > >
> >> > > If we can branch for 2.0 now and then merge this, and not into the
> 2.0
> >> > > branch, I would vote +1 for branch merge even with known blockers
> >> > pending.
> >> > >
> >> > >
> >> > > On Fri, Mar 10, 2017 at 1:42 PM, Vladimir Rodionov <
> >> > vladrodionov@gmail.com>
> >> > > wrote:
> >> > >
> >> > >> 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 <ap...@apache.org>
> >> > wrote:
> >> > >>
> >> > >>>> 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 <
> >> > >> vladrodionov@gmail.com>
> >> > >>> wrote:
> >> > >>>
> >> > >>>> 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 reviews and
> has
> >> > >> probably
> >> > >>>> the most lengthy discussion thread on Apache JIRA (HBASE-14123)
> :)
> >> > >>>>
> >> > >>>> The work has been split into 3 phases (HBASE-14030, 14123, 14414)
> >> Two
> >> > >> first
> >> > >>>> are complete, third one is still in progress.
> >> > >>>>
> >> > >>>>
> >> > >>>> *** Summary of work HBASE-14123
> >> > >>>>
> >> > >>>> The new feature introduces new command-line extensions to the
> hbase
> >> > >> command
> >> > >>>> and, from the client side, is accessible through command-line
> only
> >> > >>>> Operations:
> >> > >>>> * Create full backup on a list of tables or backup set
> >> > >>>> * Create incremental backup image for table list or backup set
> >> > >>>> * Restore list of tables from a given backup image
> >> > >>>> * Show current backup progress
> >> > >>>> * Delete backup image and all related images
> >> > >>>> * Show history of backups
> >> > >>>> * Backup set operations: create backup set, add/remove table
> >> to/from
> >> > >> backup
> >> > >>>> set, etc
> >> > >>>>
> >> > >>>> In the current implementation, the feature is already usable,
> >> meaning
> >> > >> that
> >> > >>>> users can backup tables and restore them using provided
> >> command-line
> >> > >> tools.
> >> > >>>> Both: full and incremental backups are supported.
> >> > >>>> This work is based on original work of IBM team (HBASE-7912). The
> >> full
> >> > >> list
> >> > >>>> of JIRAs included in this mega patch can be found in three
> umbrella
> >> > >> JIRAs:
> >> > >>>> HBASE-14030 (Phase 1), HBASE-14123 (Phase 2) and HBASE-14414
> >> (Phase 3
> >> > -
> >> > >> all
> >> > >>>> resolved ones made it into the patch)
> >> > >>>>
> >> > >>>> *** What are the remaining work items
> >> > >>>>
> >> > >>>> All remaining items can be found in Phase 3 umbrella JIRA:
> >> > HBASE-14414.
> >> > >>>> They are split into 3 groups: BLOCKER, CRITICAL, MAJOR
> >> > >>>> Only BLOCKERs and CRITICALs are guaranteed for HBase 2.0 release.
> >> > >>>>
> >> > >>>> ***** BLOCKER
> >> > >>>>
> >> > >>>> * HBASE-14417 Incremental backup and bulk loading ( Patch
> >> available)
> >> > >>>> * HBASE-14135 HBase Backup/Restore Phase 3: Merge backup images
> >> > >>>> * HBASE-14141 HBase Backup/Restore Phase 3: Filter WALs on backup
> >> to
> >> > >>>> include only edits from backup tables (Patch available)
> >> > >>>> * HBASE-17133 Backup documentation
> >> > >>>> * HBASE-15227 Fault tolerance support
> >> > >>>>
> >> > >>>> ***** CRITICAL
> >> > >>>>
> >> > >>>> * HBASE-16465 Disable split/merges during backup
> >> > >>>>
> >> > >>>> We have umbrella JIRA (HBASE-14414) to track all the remaining
> work
> >> > >>>> All the BLOCKER and CRITICAL JIRAs currently in open state will
> be
> >> > >>>> implemented by 2.0 release time. Some MAJOR too, but it depends
> on
> >> > >> resource
> >> > >>>> availability
> >> > >>>> The former development branch (HBASE-7912) is obsolete and will
> be
> >> > >>>> closed/deleted after the merge.
> >> > >>>> We want backup to be a GA feature in 2.0
> >> > >>>> We are going to support full backward compatibility for backup
> >> tool in
> >> > >> 2.0
> >> > >>>> and onwards.
> >> > >>>>
> >> > >>>> **** Configuration
> >> > >>>>
> >> > >>>> Backup is disabled, by default. To enable it, the following
> >> > >> configuration
> >> > >>>> properties must be added to hbase-site.xml:
> >> > >>>>
> >> > >>>> hbase.backup.enable=true
> >> > >>>> hbase.master.logcleaner.plugins=YOUR_PLUGINS,org.
> >> > >>>> apache.hadoop.hbase.backup.master.BackupLogCleaner
> >> > >>>> hbase.procedure.master.classes=YOUR_CLASSES,org.
> >> > >>>> apache.hadoop.hbase.backup.master.LogRollMasterProcedureManager
> >> > >>>> hbase.procedure.regionserver.classes=YOUR_CLASSES,org.
> >> > >>>> apache.hadoop.hbase.backup.regionserver.
> >> > LogRollRegionServerProcedureMa
> >> > >>>> nager
> >> > >>>>
> >> > >>>>
> >> > >>>> I would like to thank IBM team and Jerry He for original work,
> >> > >>>>
> >> > >>>> Enis, Ted, Stack, Matteo, Jerry for time spent on code reviews
> >> > >>>>
> >> > >>>> Special thanks to Ted Yu for his co-development work.
> >> > >>>>
> >> > >>>> References:
> >> > >>>>
> >> > >>>> https://issues.apache.org/jira/browse/HBASE-7912 (original IBM,
> >> > >> contains
> >> > >>>> design doc)
> >> > >>>> https://issues.apache.org/jira/browse/HBASE-14030 (Phase 1)
> >> > >>>> https://issues.apache.org/jira/browse/HBASE-14123 (Phase 2)
> >> > >>>> https://issues.apache.org/jira/browse/HBASE-14414 (Phase 3)
> >> > >>>>
> >> > >>>> Please vote +1/-1 by midnight Pacific Time (00:00
> >> > >>>> -0800 GMT) on March 11th on whether or not we should merge this
> >> into
> >> > >> the
> >> > >>>> current master.
> >> > >>>>
> >> > >>>> -Vladimir Rodionov
> >> > >>>>
> >> > >>>
> >> > >>>
> >> > >>>
> >> > >>> --
> >> > >>> Best regards,
> >> > >>>
> >> > >>> - Andy
> >> > >>>
> >> > >>> If you are given a choice, you believe you have acted freely. -
> >> Raymond
> >> > >>> Teller (via Peter Watts)
> >> > >>
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > Best regards,
> >> > >
> >> > > - Andy
> >> > >
> >> > > If you are given a choice, you believe you have acted freely. -
> >> Raymond
> >> > > Teller (via Peter Watts)
> >> >
> >>
> >>
> >>
> >> --
> >> Best regards,
> >>
> >> - Andy
> >>
> >> If you are given a choice, you believe you have acted freely. - Raymond
> >> Teller (via Peter Watts)
> >>
> >
> >
>
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
Posted by Ted Yu <yu...@gmail.com>.
HBASE-14123 branch has been created, with Vlad's mega patch v61.
FYI
On Fri, Mar 10, 2017 at 3:30 PM, Ted Yu <yu...@gmail.com> 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 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, we
> propose to community for merging into branch-2 (master branch, if branch-2
> doesn't materialize for whatever reason) again
>
> Cheers
>
>
> On Fri, Mar 10, 2017 at 3:01 PM, Andrew Purtell <ap...@apache.org>
> wrote:
>
>> 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 the documentation issue is important but not actually a blocker.
>> That may be a controversial opinion, but documentation can be back-filled
>> worst case. So take HBASE-17133 off the list.
>>
>> Remaining are effectively HBASE-14417, HBASE-14141, and HBASE-15227. They
>> all have patches attached to the respective JIRAs so completing this work
>> won't be onerous. Get these committed and I will lift my -1. The others
>> who
>> voted +1 on this thread surely can help with that.
>>
>> Thanks.
>>
>>
>> On Fri, Mar 10, 2017 at 2:32 PM, Vladimir Rodionov <
>> vladrodionov@gmail.com>
>> wrote:
>>
>> > 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 <ap...@apache.org>
>> 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 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 prevent that release because these blockers will be
>> there. I
>> > am
>> > > inclined to veto. Probably we should not propose branch merges into
>> code
>> > we
>> > > are trying to get out the door with known blockers. Why not do that
>> work
>> > > first? It seems an obvious question. Perhaps I am missing something.
>> > >
>> > > If we can branch for 2.0 now and then merge this, and not into the 2.0
>> > > branch, I would vote +1 for branch merge even with known blockers
>> > pending.
>> > >
>> > >
>> > > On Fri, Mar 10, 2017 at 1:42 PM, Vladimir Rodionov <
>> > vladrodionov@gmail.com>
>> > > wrote:
>> > >
>> > >> 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 <ap...@apache.org>
>> > wrote:
>> > >>
>> > >>>> 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 <
>> > >> vladrodionov@gmail.com>
>> > >>> wrote:
>> > >>>
>> > >>>> 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 reviews and has
>> > >> probably
>> > >>>> the most lengthy discussion thread on Apache JIRA (HBASE-14123) :)
>> > >>>>
>> > >>>> The work has been split into 3 phases (HBASE-14030, 14123, 14414)
>> Two
>> > >> first
>> > >>>> are complete, third one is still in progress.
>> > >>>>
>> > >>>>
>> > >>>> *** Summary of work HBASE-14123
>> > >>>>
>> > >>>> The new feature introduces new command-line extensions to the hbase
>> > >> command
>> > >>>> and, from the client side, is accessible through command-line only
>> > >>>> Operations:
>> > >>>> * Create full backup on a list of tables or backup set
>> > >>>> * Create incremental backup image for table list or backup set
>> > >>>> * Restore list of tables from a given backup image
>> > >>>> * Show current backup progress
>> > >>>> * Delete backup image and all related images
>> > >>>> * Show history of backups
>> > >>>> * Backup set operations: create backup set, add/remove table
>> to/from
>> > >> backup
>> > >>>> set, etc
>> > >>>>
>> > >>>> In the current implementation, the feature is already usable,
>> meaning
>> > >> that
>> > >>>> users can backup tables and restore them using provided
>> command-line
>> > >> tools.
>> > >>>> Both: full and incremental backups are supported.
>> > >>>> This work is based on original work of IBM team (HBASE-7912). The
>> full
>> > >> list
>> > >>>> of JIRAs included in this mega patch can be found in three umbrella
>> > >> JIRAs:
>> > >>>> HBASE-14030 (Phase 1), HBASE-14123 (Phase 2) and HBASE-14414
>> (Phase 3
>> > -
>> > >> all
>> > >>>> resolved ones made it into the patch)
>> > >>>>
>> > >>>> *** What are the remaining work items
>> > >>>>
>> > >>>> All remaining items can be found in Phase 3 umbrella JIRA:
>> > HBASE-14414.
>> > >>>> They are split into 3 groups: BLOCKER, CRITICAL, MAJOR
>> > >>>> Only BLOCKERs and CRITICALs are guaranteed for HBase 2.0 release.
>> > >>>>
>> > >>>> ***** BLOCKER
>> > >>>>
>> > >>>> * HBASE-14417 Incremental backup and bulk loading ( Patch
>> available)
>> > >>>> * HBASE-14135 HBase Backup/Restore Phase 3: Merge backup images
>> > >>>> * HBASE-14141 HBase Backup/Restore Phase 3: Filter WALs on backup
>> to
>> > >>>> include only edits from backup tables (Patch available)
>> > >>>> * HBASE-17133 Backup documentation
>> > >>>> * HBASE-15227 Fault tolerance support
>> > >>>>
>> > >>>> ***** CRITICAL
>> > >>>>
>> > >>>> * HBASE-16465 Disable split/merges during backup
>> > >>>>
>> > >>>> We have umbrella JIRA (HBASE-14414) to track all the remaining work
>> > >>>> All the BLOCKER and CRITICAL JIRAs currently in open state will be
>> > >>>> implemented by 2.0 release time. Some MAJOR too, but it depends on
>> > >> resource
>> > >>>> availability
>> > >>>> The former development branch (HBASE-7912) is obsolete and will be
>> > >>>> closed/deleted after the merge.
>> > >>>> We want backup to be a GA feature in 2.0
>> > >>>> We are going to support full backward compatibility for backup
>> tool in
>> > >> 2.0
>> > >>>> and onwards.
>> > >>>>
>> > >>>> **** Configuration
>> > >>>>
>> > >>>> Backup is disabled, by default. To enable it, the following
>> > >> configuration
>> > >>>> properties must be added to hbase-site.xml:
>> > >>>>
>> > >>>> hbase.backup.enable=true
>> > >>>> hbase.master.logcleaner.plugins=YOUR_PLUGINS,org.
>> > >>>> apache.hadoop.hbase.backup.master.BackupLogCleaner
>> > >>>> hbase.procedure.master.classes=YOUR_CLASSES,org.
>> > >>>> apache.hadoop.hbase.backup.master.LogRollMasterProcedureManager
>> > >>>> hbase.procedure.regionserver.classes=YOUR_CLASSES,org.
>> > >>>> apache.hadoop.hbase.backup.regionserver.
>> > LogRollRegionServerProcedureMa
>> > >>>> nager
>> > >>>>
>> > >>>>
>> > >>>> I would like to thank IBM team and Jerry He for original work,
>> > >>>>
>> > >>>> Enis, Ted, Stack, Matteo, Jerry for time spent on code reviews
>> > >>>>
>> > >>>> Special thanks to Ted Yu for his co-development work.
>> > >>>>
>> > >>>> References:
>> > >>>>
>> > >>>> https://issues.apache.org/jira/browse/HBASE-7912 (original IBM,
>> > >> contains
>> > >>>> design doc)
>> > >>>> https://issues.apache.org/jira/browse/HBASE-14030 (Phase 1)
>> > >>>> https://issues.apache.org/jira/browse/HBASE-14123 (Phase 2)
>> > >>>> https://issues.apache.org/jira/browse/HBASE-14414 (Phase 3)
>> > >>>>
>> > >>>> Please vote +1/-1 by midnight Pacific Time (00:00
>> > >>>> -0800 GMT) on March 11th on whether or not we should merge this
>> into
>> > >> the
>> > >>>> current master.
>> > >>>>
>> > >>>> -Vladimir Rodionov
>> > >>>>
>> > >>>
>> > >>>
>> > >>>
>> > >>> --
>> > >>> Best regards,
>> > >>>
>> > >>> - Andy
>> > >>>
>> > >>> If you are given a choice, you believe you have acted freely. -
>> Raymond
>> > >>> Teller (via Peter Watts)
>> > >>
>> > >
>> > >
>> > >
>> > > --
>> > > Best regards,
>> > >
>> > > - Andy
>> > >
>> > > If you are given a choice, you believe you have acted freely. -
>> Raymond
>> > > Teller (via Peter Watts)
>> >
>>
>>
>>
>> --
>> Best regards,
>>
>> - Andy
>>
>> If you are given a choice, you believe you have acted freely. - Raymond
>> Teller (via Peter Watts)
>>
>
>
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
Posted by Ted Yu <yu...@gmail.com>.
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, we
propose to community for merging into branch-2 (master branch, if branch-2
doesn't materialize for whatever reason) again
Cheers
On Fri, Mar 10, 2017 at 3:01 PM, Andrew Purtell <ap...@apache.org> wrote:
> 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 the documentation issue is important but not actually a blocker.
> That may be a controversial opinion, but documentation can be back-filled
> worst case. So take HBASE-17133 off the list.
>
> Remaining are effectively HBASE-14417, HBASE-14141, and HBASE-15227. They
> all have patches attached to the respective JIRAs so completing this work
> won't be onerous. Get these committed and I will lift my -1. The others who
> voted +1 on this thread surely can help with that.
>
> Thanks.
>
>
> On Fri, Mar 10, 2017 at 2:32 PM, Vladimir Rodionov <vladrodionov@gmail.com
> >
> wrote:
>
> > 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 <ap...@apache.org>
> 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 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 prevent that release because these blockers will be there.
> I
> > am
> > > inclined to veto. Probably we should not propose branch merges into
> code
> > we
> > > are trying to get out the door with known blockers. Why not do that
> work
> > > first? It seems an obvious question. Perhaps I am missing something.
> > >
> > > If we can branch for 2.0 now and then merge this, and not into the 2.0
> > > branch, I would vote +1 for branch merge even with known blockers
> > pending.
> > >
> > >
> > > On Fri, Mar 10, 2017 at 1:42 PM, Vladimir Rodionov <
> > vladrodionov@gmail.com>
> > > wrote:
> > >
> > >> 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 <ap...@apache.org>
> > wrote:
> > >>
> > >>>> 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 <
> > >> vladrodionov@gmail.com>
> > >>> wrote:
> > >>>
> > >>>> 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 reviews and has
> > >> probably
> > >>>> the most lengthy discussion thread on Apache JIRA (HBASE-14123) :)
> > >>>>
> > >>>> The work has been split into 3 phases (HBASE-14030, 14123, 14414)
> Two
> > >> first
> > >>>> are complete, third one is still in progress.
> > >>>>
> > >>>>
> > >>>> *** Summary of work HBASE-14123
> > >>>>
> > >>>> The new feature introduces new command-line extensions to the hbase
> > >> command
> > >>>> and, from the client side, is accessible through command-line only
> > >>>> Operations:
> > >>>> * Create full backup on a list of tables or backup set
> > >>>> * Create incremental backup image for table list or backup set
> > >>>> * Restore list of tables from a given backup image
> > >>>> * Show current backup progress
> > >>>> * Delete backup image and all related images
> > >>>> * Show history of backups
> > >>>> * Backup set operations: create backup set, add/remove table to/from
> > >> backup
> > >>>> set, etc
> > >>>>
> > >>>> In the current implementation, the feature is already usable,
> meaning
> > >> that
> > >>>> users can backup tables and restore them using provided command-line
> > >> tools.
> > >>>> Both: full and incremental backups are supported.
> > >>>> This work is based on original work of IBM team (HBASE-7912). The
> full
> > >> list
> > >>>> of JIRAs included in this mega patch can be found in three umbrella
> > >> JIRAs:
> > >>>> HBASE-14030 (Phase 1), HBASE-14123 (Phase 2) and HBASE-14414 (Phase
> 3
> > -
> > >> all
> > >>>> resolved ones made it into the patch)
> > >>>>
> > >>>> *** What are the remaining work items
> > >>>>
> > >>>> All remaining items can be found in Phase 3 umbrella JIRA:
> > HBASE-14414.
> > >>>> They are split into 3 groups: BLOCKER, CRITICAL, MAJOR
> > >>>> Only BLOCKERs and CRITICALs are guaranteed for HBase 2.0 release.
> > >>>>
> > >>>> ***** BLOCKER
> > >>>>
> > >>>> * HBASE-14417 Incremental backup and bulk loading ( Patch available)
> > >>>> * HBASE-14135 HBase Backup/Restore Phase 3: Merge backup images
> > >>>> * HBASE-14141 HBase Backup/Restore Phase 3: Filter WALs on backup to
> > >>>> include only edits from backup tables (Patch available)
> > >>>> * HBASE-17133 Backup documentation
> > >>>> * HBASE-15227 Fault tolerance support
> > >>>>
> > >>>> ***** CRITICAL
> > >>>>
> > >>>> * HBASE-16465 Disable split/merges during backup
> > >>>>
> > >>>> We have umbrella JIRA (HBASE-14414) to track all the remaining work
> > >>>> All the BLOCKER and CRITICAL JIRAs currently in open state will be
> > >>>> implemented by 2.0 release time. Some MAJOR too, but it depends on
> > >> resource
> > >>>> availability
> > >>>> The former development branch (HBASE-7912) is obsolete and will be
> > >>>> closed/deleted after the merge.
> > >>>> We want backup to be a GA feature in 2.0
> > >>>> We are going to support full backward compatibility for backup tool
> in
> > >> 2.0
> > >>>> and onwards.
> > >>>>
> > >>>> **** Configuration
> > >>>>
> > >>>> Backup is disabled, by default. To enable it, the following
> > >> configuration
> > >>>> properties must be added to hbase-site.xml:
> > >>>>
> > >>>> hbase.backup.enable=true
> > >>>> hbase.master.logcleaner.plugins=YOUR_PLUGINS,org.
> > >>>> apache.hadoop.hbase.backup.master.BackupLogCleaner
> > >>>> hbase.procedure.master.classes=YOUR_CLASSES,org.
> > >>>> apache.hadoop.hbase.backup.master.LogRollMasterProcedureManager
> > >>>> hbase.procedure.regionserver.classes=YOUR_CLASSES,org.
> > >>>> apache.hadoop.hbase.backup.regionserver.
> > LogRollRegionServerProcedureMa
> > >>>> nager
> > >>>>
> > >>>>
> > >>>> I would like to thank IBM team and Jerry He for original work,
> > >>>>
> > >>>> Enis, Ted, Stack, Matteo, Jerry for time spent on code reviews
> > >>>>
> > >>>> Special thanks to Ted Yu for his co-development work.
> > >>>>
> > >>>> References:
> > >>>>
> > >>>> https://issues.apache.org/jira/browse/HBASE-7912 (original IBM,
> > >> contains
> > >>>> design doc)
> > >>>> https://issues.apache.org/jira/browse/HBASE-14030 (Phase 1)
> > >>>> https://issues.apache.org/jira/browse/HBASE-14123 (Phase 2)
> > >>>> https://issues.apache.org/jira/browse/HBASE-14414 (Phase 3)
> > >>>>
> > >>>> Please vote +1/-1 by midnight Pacific Time (00:00
> > >>>> -0800 GMT) on March 11th on whether or not we should merge this
> into
> > >> the
> > >>>> current master.
> > >>>>
> > >>>> -Vladimir Rodionov
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> Best regards,
> > >>>
> > >>> - Andy
> > >>>
> > >>> If you are given a choice, you believe you have acted freely. -
> Raymond
> > >>> Teller (via Peter Watts)
> > >>
> > >
> > >
> > >
> > > --
> > > Best regards,
> > >
> > > - Andy
> > >
> > > If you are given a choice, you believe you have acted freely. - Raymond
> > > Teller (via Peter Watts)
> >
>
>
>
> --
> Best regards,
>
> - Andy
>
> If you are given a choice, you believe you have acted freely. - Raymond
> Teller (via Peter Watts)
>
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
Posted by Andrew Purtell <ap...@apache.org>.
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 the documentation issue is important but not actually a blocker.
That may be a controversial opinion, but documentation can be back-filled
worst case. So take HBASE-17133 off the list.
Remaining are effectively HBASE-14417, HBASE-14141, and HBASE-15227. They
all have patches attached to the respective JIRAs so completing this work
won't be onerous. Get these committed and I will lift my -1. The others who
voted +1 on this thread surely can help with that.
Thanks.
On Fri, Mar 10, 2017 at 2:32 PM, Vladimir Rodionov <vl...@gmail.com>
wrote:
> 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 <ap...@apache.org> 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 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 prevent that release because these blockers will be there. I
> am
> > inclined to veto. Probably we should not propose branch merges into code
> we
> > are trying to get out the door with known blockers. Why not do that work
> > first? It seems an obvious question. Perhaps I am missing something.
> >
> > If we can branch for 2.0 now and then merge this, and not into the 2.0
> > branch, I would vote +1 for branch merge even with known blockers
> pending.
> >
> >
> > On Fri, Mar 10, 2017 at 1:42 PM, Vladimir Rodionov <
> vladrodionov@gmail.com>
> > wrote:
> >
> >> 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 <ap...@apache.org>
> wrote:
> >>
> >>>> 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 <
> >> vladrodionov@gmail.com>
> >>> wrote:
> >>>
> >>>> 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 reviews and has
> >> probably
> >>>> the most lengthy discussion thread on Apache JIRA (HBASE-14123) :)
> >>>>
> >>>> The work has been split into 3 phases (HBASE-14030, 14123, 14414) Two
> >> first
> >>>> are complete, third one is still in progress.
> >>>>
> >>>>
> >>>> *** Summary of work HBASE-14123
> >>>>
> >>>> The new feature introduces new command-line extensions to the hbase
> >> command
> >>>> and, from the client side, is accessible through command-line only
> >>>> Operations:
> >>>> * Create full backup on a list of tables or backup set
> >>>> * Create incremental backup image for table list or backup set
> >>>> * Restore list of tables from a given backup image
> >>>> * Show current backup progress
> >>>> * Delete backup image and all related images
> >>>> * Show history of backups
> >>>> * Backup set operations: create backup set, add/remove table to/from
> >> backup
> >>>> set, etc
> >>>>
> >>>> In the current implementation, the feature is already usable, meaning
> >> that
> >>>> users can backup tables and restore them using provided command-line
> >> tools.
> >>>> Both: full and incremental backups are supported.
> >>>> This work is based on original work of IBM team (HBASE-7912). The full
> >> list
> >>>> of JIRAs included in this mega patch can be found in three umbrella
> >> JIRAs:
> >>>> HBASE-14030 (Phase 1), HBASE-14123 (Phase 2) and HBASE-14414 (Phase 3
> -
> >> all
> >>>> resolved ones made it into the patch)
> >>>>
> >>>> *** What are the remaining work items
> >>>>
> >>>> All remaining items can be found in Phase 3 umbrella JIRA:
> HBASE-14414.
> >>>> They are split into 3 groups: BLOCKER, CRITICAL, MAJOR
> >>>> Only BLOCKERs and CRITICALs are guaranteed for HBase 2.0 release.
> >>>>
> >>>> ***** BLOCKER
> >>>>
> >>>> * HBASE-14417 Incremental backup and bulk loading ( Patch available)
> >>>> * HBASE-14135 HBase Backup/Restore Phase 3: Merge backup images
> >>>> * HBASE-14141 HBase Backup/Restore Phase 3: Filter WALs on backup to
> >>>> include only edits from backup tables (Patch available)
> >>>> * HBASE-17133 Backup documentation
> >>>> * HBASE-15227 Fault tolerance support
> >>>>
> >>>> ***** CRITICAL
> >>>>
> >>>> * HBASE-16465 Disable split/merges during backup
> >>>>
> >>>> We have umbrella JIRA (HBASE-14414) to track all the remaining work
> >>>> All the BLOCKER and CRITICAL JIRAs currently in open state will be
> >>>> implemented by 2.0 release time. Some MAJOR too, but it depends on
> >> resource
> >>>> availability
> >>>> The former development branch (HBASE-7912) is obsolete and will be
> >>>> closed/deleted after the merge.
> >>>> We want backup to be a GA feature in 2.0
> >>>> We are going to support full backward compatibility for backup tool in
> >> 2.0
> >>>> and onwards.
> >>>>
> >>>> **** Configuration
> >>>>
> >>>> Backup is disabled, by default. To enable it, the following
> >> configuration
> >>>> properties must be added to hbase-site.xml:
> >>>>
> >>>> hbase.backup.enable=true
> >>>> hbase.master.logcleaner.plugins=YOUR_PLUGINS,org.
> >>>> apache.hadoop.hbase.backup.master.BackupLogCleaner
> >>>> hbase.procedure.master.classes=YOUR_CLASSES,org.
> >>>> apache.hadoop.hbase.backup.master.LogRollMasterProcedureManager
> >>>> hbase.procedure.regionserver.classes=YOUR_CLASSES,org.
> >>>> apache.hadoop.hbase.backup.regionserver.
> LogRollRegionServerProcedureMa
> >>>> nager
> >>>>
> >>>>
> >>>> I would like to thank IBM team and Jerry He for original work,
> >>>>
> >>>> Enis, Ted, Stack, Matteo, Jerry for time spent on code reviews
> >>>>
> >>>> Special thanks to Ted Yu for his co-development work.
> >>>>
> >>>> References:
> >>>>
> >>>> https://issues.apache.org/jira/browse/HBASE-7912 (original IBM,
> >> contains
> >>>> design doc)
> >>>> https://issues.apache.org/jira/browse/HBASE-14030 (Phase 1)
> >>>> https://issues.apache.org/jira/browse/HBASE-14123 (Phase 2)
> >>>> https://issues.apache.org/jira/browse/HBASE-14414 (Phase 3)
> >>>>
> >>>> Please vote +1/-1 by midnight Pacific Time (00:00
> >>>> -0800 GMT) on March 11th on whether or not we should merge this into
> >> the
> >>>> current master.
> >>>>
> >>>> -Vladimir Rodionov
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Best regards,
> >>>
> >>> - Andy
> >>>
> >>> If you are given a choice, you believe you have acted freely. - Raymond
> >>> Teller (via Peter Watts)
> >>
> >
> >
> >
> > --
> > Best regards,
> >
> > - Andy
> >
> > If you are given a choice, you believe you have acted freely. - Raymond
> > Teller (via Peter Watts)
>
--
Best regards,
- Andy
If you are given a choice, you believe you have acted freely. - Raymond
Teller (via Peter Watts)
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
Posted by Vladimir Rodionov <vl...@gmail.com>.
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 <ap...@apache.org> 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 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 prevent that release because these blockers will be there. I am
> inclined to veto. Probably we should not propose branch merges into code we
> are trying to get out the door with known blockers. Why not do that work
> first? It seems an obvious question. Perhaps I am missing something.
>
> If we can branch for 2.0 now and then merge this, and not into the 2.0
> branch, I would vote +1 for branch merge even with known blockers pending.
>
>
> On Fri, Mar 10, 2017 at 1:42 PM, Vladimir Rodionov <vl...@gmail.com>
> wrote:
>
>> 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 <ap...@apache.org> wrote:
>>
>>>> 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 <
>> vladrodionov@gmail.com>
>>> wrote:
>>>
>>>> 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 reviews and has
>> probably
>>>> the most lengthy discussion thread on Apache JIRA (HBASE-14123) :)
>>>>
>>>> The work has been split into 3 phases (HBASE-14030, 14123, 14414) Two
>> first
>>>> are complete, third one is still in progress.
>>>>
>>>>
>>>> *** Summary of work HBASE-14123
>>>>
>>>> The new feature introduces new command-line extensions to the hbase
>> command
>>>> and, from the client side, is accessible through command-line only
>>>> Operations:
>>>> * Create full backup on a list of tables or backup set
>>>> * Create incremental backup image for table list or backup set
>>>> * Restore list of tables from a given backup image
>>>> * Show current backup progress
>>>> * Delete backup image and all related images
>>>> * Show history of backups
>>>> * Backup set operations: create backup set, add/remove table to/from
>> backup
>>>> set, etc
>>>>
>>>> In the current implementation, the feature is already usable, meaning
>> that
>>>> users can backup tables and restore them using provided command-line
>> tools.
>>>> Both: full and incremental backups are supported.
>>>> This work is based on original work of IBM team (HBASE-7912). The full
>> list
>>>> of JIRAs included in this mega patch can be found in three umbrella
>> JIRAs:
>>>> HBASE-14030 (Phase 1), HBASE-14123 (Phase 2) and HBASE-14414 (Phase 3 -
>> all
>>>> resolved ones made it into the patch)
>>>>
>>>> *** What are the remaining work items
>>>>
>>>> All remaining items can be found in Phase 3 umbrella JIRA: HBASE-14414.
>>>> They are split into 3 groups: BLOCKER, CRITICAL, MAJOR
>>>> Only BLOCKERs and CRITICALs are guaranteed for HBase 2.0 release.
>>>>
>>>> ***** BLOCKER
>>>>
>>>> * HBASE-14417 Incremental backup and bulk loading ( Patch available)
>>>> * HBASE-14135 HBase Backup/Restore Phase 3: Merge backup images
>>>> * HBASE-14141 HBase Backup/Restore Phase 3: Filter WALs on backup to
>>>> include only edits from backup tables (Patch available)
>>>> * HBASE-17133 Backup documentation
>>>> * HBASE-15227 Fault tolerance support
>>>>
>>>> ***** CRITICAL
>>>>
>>>> * HBASE-16465 Disable split/merges during backup
>>>>
>>>> We have umbrella JIRA (HBASE-14414) to track all the remaining work
>>>> All the BLOCKER and CRITICAL JIRAs currently in open state will be
>>>> implemented by 2.0 release time. Some MAJOR too, but it depends on
>> resource
>>>> availability
>>>> The former development branch (HBASE-7912) is obsolete and will be
>>>> closed/deleted after the merge.
>>>> We want backup to be a GA feature in 2.0
>>>> We are going to support full backward compatibility for backup tool in
>> 2.0
>>>> and onwards.
>>>>
>>>> **** Configuration
>>>>
>>>> Backup is disabled, by default. To enable it, the following
>> configuration
>>>> properties must be added to hbase-site.xml:
>>>>
>>>> hbase.backup.enable=true
>>>> hbase.master.logcleaner.plugins=YOUR_PLUGINS,org.
>>>> apache.hadoop.hbase.backup.master.BackupLogCleaner
>>>> hbase.procedure.master.classes=YOUR_CLASSES,org.
>>>> apache.hadoop.hbase.backup.master.LogRollMasterProcedureManager
>>>> hbase.procedure.regionserver.classes=YOUR_CLASSES,org.
>>>> apache.hadoop.hbase.backup.regionserver.LogRollRegionServerProcedureMa
>>>> nager
>>>>
>>>>
>>>> I would like to thank IBM team and Jerry He for original work,
>>>>
>>>> Enis, Ted, Stack, Matteo, Jerry for time spent on code reviews
>>>>
>>>> Special thanks to Ted Yu for his co-development work.
>>>>
>>>> References:
>>>>
>>>> https://issues.apache.org/jira/browse/HBASE-7912 (original IBM,
>> contains
>>>> design doc)
>>>> https://issues.apache.org/jira/browse/HBASE-14030 (Phase 1)
>>>> https://issues.apache.org/jira/browse/HBASE-14123 (Phase 2)
>>>> https://issues.apache.org/jira/browse/HBASE-14414 (Phase 3)
>>>>
>>>> Please vote +1/-1 by midnight Pacific Time (00:00
>>>> -0800 GMT) on March 11th on whether or not we should merge this into
>> the
>>>> current master.
>>>>
>>>> -Vladimir Rodionov
>>>>
>>>
>>>
>>>
>>> --
>>> Best regards,
>>>
>>> - Andy
>>>
>>> If you are given a choice, you believe you have acted freely. - Raymond
>>> Teller (via Peter Watts)
>>
>
>
>
> --
> Best regards,
>
> - Andy
>
> If you are given a choice, you believe you have acted freely. - Raymond
> Teller (via Peter Watts)
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
Posted by Andrew Purtell <ap...@apache.org>.
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 prevent that release because these blockers will be there. I am
inclined to veto. Probably we should not propose branch merges into code we
are trying to get out the door with known blockers. Why not do that work
first? It seems an obvious question. Perhaps I am missing something.
If we can branch for 2.0 now and then merge this, and not into the 2.0
branch, I would vote +1 for branch merge even with known blockers pending.
On Fri, Mar 10, 2017 at 1:42 PM, Vladimir Rodionov <vl...@gmail.com>
wrote:
> 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 <ap...@apache.org> wrote:
>
> >> 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 <
> vladrodionov@gmail.com>
> > wrote:
> >
> >> 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 reviews and has
> probably
> >> the most lengthy discussion thread on Apache JIRA (HBASE-14123) :)
> >>
> >> The work has been split into 3 phases (HBASE-14030, 14123, 14414) Two
> first
> >> are complete, third one is still in progress.
> >>
> >>
> >> *** Summary of work HBASE-14123
> >>
> >> The new feature introduces new command-line extensions to the hbase
> command
> >> and, from the client side, is accessible through command-line only
> >> Operations:
> >> * Create full backup on a list of tables or backup set
> >> * Create incremental backup image for table list or backup set
> >> * Restore list of tables from a given backup image
> >> * Show current backup progress
> >> * Delete backup image and all related images
> >> * Show history of backups
> >> * Backup set operations: create backup set, add/remove table to/from
> backup
> >> set, etc
> >>
> >> In the current implementation, the feature is already usable, meaning
> that
> >> users can backup tables and restore them using provided command-line
> tools.
> >> Both: full and incremental backups are supported.
> >> This work is based on original work of IBM team (HBASE-7912). The full
> list
> >> of JIRAs included in this mega patch can be found in three umbrella
> JIRAs:
> >> HBASE-14030 (Phase 1), HBASE-14123 (Phase 2) and HBASE-14414 (Phase 3 -
> all
> >> resolved ones made it into the patch)
> >>
> >> *** What are the remaining work items
> >>
> >> All remaining items can be found in Phase 3 umbrella JIRA: HBASE-14414.
> >> They are split into 3 groups: BLOCKER, CRITICAL, MAJOR
> >> Only BLOCKERs and CRITICALs are guaranteed for HBase 2.0 release.
> >>
> >> ***** BLOCKER
> >>
> >> * HBASE-14417 Incremental backup and bulk loading ( Patch available)
> >> * HBASE-14135 HBase Backup/Restore Phase 3: Merge backup images
> >> * HBASE-14141 HBase Backup/Restore Phase 3: Filter WALs on backup to
> >> include only edits from backup tables (Patch available)
> >> * HBASE-17133 Backup documentation
> >> * HBASE-15227 Fault tolerance support
> >>
> >> ***** CRITICAL
> >>
> >> * HBASE-16465 Disable split/merges during backup
> >>
> >> We have umbrella JIRA (HBASE-14414) to track all the remaining work
> >> All the BLOCKER and CRITICAL JIRAs currently in open state will be
> >> implemented by 2.0 release time. Some MAJOR too, but it depends on
> resource
> >> availability
> >> The former development branch (HBASE-7912) is obsolete and will be
> >> closed/deleted after the merge.
> >> We want backup to be a GA feature in 2.0
> >> We are going to support full backward compatibility for backup tool in
> 2.0
> >> and onwards.
> >>
> >> **** Configuration
> >>
> >> Backup is disabled, by default. To enable it, the following
> configuration
> >> properties must be added to hbase-site.xml:
> >>
> >> hbase.backup.enable=true
> >> hbase.master.logcleaner.plugins=YOUR_PLUGINS,org.
> >> apache.hadoop.hbase.backup.master.BackupLogCleaner
> >> hbase.procedure.master.classes=YOUR_CLASSES,org.
> >> apache.hadoop.hbase.backup.master.LogRollMasterProcedureManager
> >> hbase.procedure.regionserver.classes=YOUR_CLASSES,org.
> >> apache.hadoop.hbase.backup.regionserver.LogRollRegionServerProcedureMa
> >> nager
> >>
> >>
> >> I would like to thank IBM team and Jerry He for original work,
> >>
> >> Enis, Ted, Stack, Matteo, Jerry for time spent on code reviews
> >>
> >> Special thanks to Ted Yu for his co-development work.
> >>
> >> References:
> >>
> >> https://issues.apache.org/jira/browse/HBASE-7912 (original IBM,
> contains
> >> design doc)
> >> https://issues.apache.org/jira/browse/HBASE-14030 (Phase 1)
> >> https://issues.apache.org/jira/browse/HBASE-14123 (Phase 2)
> >> https://issues.apache.org/jira/browse/HBASE-14414 (Phase 3)
> >>
> >> Please vote +1/-1 by midnight Pacific Time (00:00
> >> -0800 GMT) on March 11th on whether or not we should merge this into
> the
> >> current master.
> >>
> >> -Vladimir Rodionov
> >>
> >
> >
> >
> > --
> > Best regards,
> >
> > - Andy
> >
> > If you are given a choice, you believe you have acted freely. - Raymond
> > Teller (via Peter Watts)
>
--
Best regards,
- Andy
If you are given a choice, you believe you have acted freely. - Raymond
Teller (via Peter Watts)
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
Posted by Vladimir Rodionov <vl...@gmail.com>.
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 <ap...@apache.org> wrote:
>> 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 <vl...@gmail.com>
> wrote:
>
>> 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 reviews and has probably
>> the most lengthy discussion thread on Apache JIRA (HBASE-14123) :)
>>
>> The work has been split into 3 phases (HBASE-14030, 14123, 14414) Two first
>> are complete, third one is still in progress.
>>
>>
>> *** Summary of work HBASE-14123
>>
>> The new feature introduces new command-line extensions to the hbase command
>> and, from the client side, is accessible through command-line only
>> Operations:
>> * Create full backup on a list of tables or backup set
>> * Create incremental backup image for table list or backup set
>> * Restore list of tables from a given backup image
>> * Show current backup progress
>> * Delete backup image and all related images
>> * Show history of backups
>> * Backup set operations: create backup set, add/remove table to/from backup
>> set, etc
>>
>> In the current implementation, the feature is already usable, meaning that
>> users can backup tables and restore them using provided command-line tools.
>> Both: full and incremental backups are supported.
>> This work is based on original work of IBM team (HBASE-7912). The full list
>> of JIRAs included in this mega patch can be found in three umbrella JIRAs:
>> HBASE-14030 (Phase 1), HBASE-14123 (Phase 2) and HBASE-14414 (Phase 3 - all
>> resolved ones made it into the patch)
>>
>> *** What are the remaining work items
>>
>> All remaining items can be found in Phase 3 umbrella JIRA: HBASE-14414.
>> They are split into 3 groups: BLOCKER, CRITICAL, MAJOR
>> Only BLOCKERs and CRITICALs are guaranteed for HBase 2.0 release.
>>
>> ***** BLOCKER
>>
>> * HBASE-14417 Incremental backup and bulk loading ( Patch available)
>> * HBASE-14135 HBase Backup/Restore Phase 3: Merge backup images
>> * HBASE-14141 HBase Backup/Restore Phase 3: Filter WALs on backup to
>> include only edits from backup tables (Patch available)
>> * HBASE-17133 Backup documentation
>> * HBASE-15227 Fault tolerance support
>>
>> ***** CRITICAL
>>
>> * HBASE-16465 Disable split/merges during backup
>>
>> We have umbrella JIRA (HBASE-14414) to track all the remaining work
>> All the BLOCKER and CRITICAL JIRAs currently in open state will be
>> implemented by 2.0 release time. Some MAJOR too, but it depends on resource
>> availability
>> The former development branch (HBASE-7912) is obsolete and will be
>> closed/deleted after the merge.
>> We want backup to be a GA feature in 2.0
>> We are going to support full backward compatibility for backup tool in 2.0
>> and onwards.
>>
>> **** Configuration
>>
>> Backup is disabled, by default. To enable it, the following configuration
>> properties must be added to hbase-site.xml:
>>
>> hbase.backup.enable=true
>> hbase.master.logcleaner.plugins=YOUR_PLUGINS,org.
>> apache.hadoop.hbase.backup.master.BackupLogCleaner
>> hbase.procedure.master.classes=YOUR_CLASSES,org.
>> apache.hadoop.hbase.backup.master.LogRollMasterProcedureManager
>> hbase.procedure.regionserver.classes=YOUR_CLASSES,org.
>> apache.hadoop.hbase.backup.regionserver.LogRollRegionServerProcedureMa
>> nager
>>
>>
>> I would like to thank IBM team and Jerry He for original work,
>>
>> Enis, Ted, Stack, Matteo, Jerry for time spent on code reviews
>>
>> Special thanks to Ted Yu for his co-development work.
>>
>> References:
>>
>> https://issues.apache.org/jira/browse/HBASE-7912 (original IBM, contains
>> design doc)
>> https://issues.apache.org/jira/browse/HBASE-14030 (Phase 1)
>> https://issues.apache.org/jira/browse/HBASE-14123 (Phase 2)
>> https://issues.apache.org/jira/browse/HBASE-14414 (Phase 3)
>>
>> Please vote +1/-1 by midnight Pacific Time (00:00
>> -0800 GMT) on March 11th on whether or not we should merge this into the
>> current master.
>>
>> -Vladimir Rodionov
>>
>
>
>
> --
> Best regards,
>
> - Andy
>
> If you are given a choice, you believe you have acted freely. - Raymond
> Teller (via Peter Watts)
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
Posted by Andrew Purtell <ap...@apache.org>.
> 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 <vl...@gmail.com>
wrote:
> 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 reviews and has probably
> the most lengthy discussion thread on Apache JIRA (HBASE-14123) :)
>
> The work has been split into 3 phases (HBASE-14030, 14123, 14414) Two first
> are complete, third one is still in progress.
>
>
> *** Summary of work HBASE-14123
>
> The new feature introduces new command-line extensions to the hbase command
> and, from the client side, is accessible through command-line only
> Operations:
> * Create full backup on a list of tables or backup set
> * Create incremental backup image for table list or backup set
> * Restore list of tables from a given backup image
> * Show current backup progress
> * Delete backup image and all related images
> * Show history of backups
> * Backup set operations: create backup set, add/remove table to/from backup
> set, etc
>
> In the current implementation, the feature is already usable, meaning that
> users can backup tables and restore them using provided command-line tools.
> Both: full and incremental backups are supported.
> This work is based on original work of IBM team (HBASE-7912). The full list
> of JIRAs included in this mega patch can be found in three umbrella JIRAs:
> HBASE-14030 (Phase 1), HBASE-14123 (Phase 2) and HBASE-14414 (Phase 3 - all
> resolved ones made it into the patch)
>
> *** What are the remaining work items
>
> All remaining items can be found in Phase 3 umbrella JIRA: HBASE-14414.
> They are split into 3 groups: BLOCKER, CRITICAL, MAJOR
> Only BLOCKERs and CRITICALs are guaranteed for HBase 2.0 release.
>
> ***** BLOCKER
>
> * HBASE-14417 Incremental backup and bulk loading ( Patch available)
> * HBASE-14135 HBase Backup/Restore Phase 3: Merge backup images
> * HBASE-14141 HBase Backup/Restore Phase 3: Filter WALs on backup to
> include only edits from backup tables (Patch available)
> * HBASE-17133 Backup documentation
> * HBASE-15227 Fault tolerance support
>
> ***** CRITICAL
>
> * HBASE-16465 Disable split/merges during backup
>
> We have umbrella JIRA (HBASE-14414) to track all the remaining work
> All the BLOCKER and CRITICAL JIRAs currently in open state will be
> implemented by 2.0 release time. Some MAJOR too, but it depends on resource
> availability
> The former development branch (HBASE-7912) is obsolete and will be
> closed/deleted after the merge.
> We want backup to be a GA feature in 2.0
> We are going to support full backward compatibility for backup tool in 2.0
> and onwards.
>
> **** Configuration
>
> Backup is disabled, by default. To enable it, the following configuration
> properties must be added to hbase-site.xml:
>
> hbase.backup.enable=true
> hbase.master.logcleaner.plugins=YOUR_PLUGINS,org.
> apache.hadoop.hbase.backup.master.BackupLogCleaner
> hbase.procedure.master.classes=YOUR_CLASSES,org.
> apache.hadoop.hbase.backup.master.LogRollMasterProcedureManager
> hbase.procedure.regionserver.classes=YOUR_CLASSES,org.
> apache.hadoop.hbase.backup.regionserver.LogRollRegionServerProcedureMa
> nager
>
>
> I would like to thank IBM team and Jerry He for original work,
>
> Enis, Ted, Stack, Matteo, Jerry for time spent on code reviews
>
> Special thanks to Ted Yu for his co-development work.
>
> References:
>
> https://issues.apache.org/jira/browse/HBASE-7912 (original IBM, contains
> design doc)
> https://issues.apache.org/jira/browse/HBASE-14030 (Phase 1)
> https://issues.apache.org/jira/browse/HBASE-14123 (Phase 2)
> https://issues.apache.org/jira/browse/HBASE-14414 (Phase 3)
>
> Please vote +1/-1 by midnight Pacific Time (00:00
> -0800 GMT) on March 11th on whether or not we should merge this into the
> current master.
>
> -Vladimir Rodionov
>
--
Best regards,
- Andy
If you are given a choice, you believe you have acted freely. - Raymond
Teller (via Peter Watts)
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
Posted by Vladimir Rodionov <vl...@gmail.com>.
bump
On Wed, Mar 8, 2017 at 3:52 PM, Vladimir Rodionov <vl...@gmail.com>
wrote:
> No problem, we can extend deadline.
>
> On Wed, Mar 8, 2017 at 3:31 PM, Ted Yu <yu...@gmail.com> 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 <vladrodionov@gmail.com
>> >
>> wrote:
>>
>> > 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 reviews and has
>> probably
>> > the most lengthy discussion thread on Apache JIRA (HBASE-14123) :)
>> >
>> > The work has been split into 3 phases (HBASE-14030, 14123, 14414) Two
>> first
>> > are complete, third one is still in progress.
>> >
>> >
>> > *** Summary of work HBASE-14123
>> >
>> > The new feature introduces new command-line extensions to the hbase
>> command
>> > and, from the client side, is accessible through command-line only
>> > Operations:
>> > * Create full backup on a list of tables or backup set
>> > * Create incremental backup image for table list or backup set
>> > * Restore list of tables from a given backup image
>> > * Show current backup progress
>> > * Delete backup image and all related images
>> > * Show history of backups
>> > * Backup set operations: create backup set, add/remove table to/from
>> backup
>> > set, etc
>> >
>> > In the current implementation, the feature is already usable, meaning
>> that
>> > users can backup tables and restore them using provided command-line
>> tools.
>> > Both: full and incremental backups are supported.
>> > This work is based on original work of IBM team (HBASE-7912). The full
>> list
>> > of JIRAs included in this mega patch can be found in three umbrella
>> JIRAs:
>> > HBASE-14030 (Phase 1), HBASE-14123 (Phase 2) and HBASE-14414 (Phase 3 -
>> all
>> > resolved ones made it into the patch)
>> >
>> > *** What are the remaining work items
>> >
>> > All remaining items can be found in Phase 3 umbrella JIRA: HBASE-14414.
>> > They are split into 3 groups: BLOCKER, CRITICAL, MAJOR
>> > Only BLOCKERs and CRITICALs are guaranteed for HBase 2.0 release.
>> >
>> > ***** BLOCKER
>> >
>> > * HBASE-14417 Incremental backup and bulk loading ( Patch available)
>> > * HBASE-14135 HBase Backup/Restore Phase 3: Merge backup images
>> > * HBASE-14141 HBase Backup/Restore Phase 3: Filter WALs on backup to
>> > include only edits from backup tables (Patch available)
>> > * HBASE-17133 Backup documentation
>> > * HBASE-15227 Fault tolerance support
>> >
>> > ***** CRITICAL
>> >
>> > * HBASE-16465 Disable split/merges during backup
>> >
>> > We have umbrella JIRA (HBASE-14414) to track all the remaining work
>> > All the BLOCKER and CRITICAL JIRAs currently in open state will be
>> > implemented by 2.0 release time. Some MAJOR too, but it depends on
>> resource
>> > availability
>> > The former development branch (HBASE-7912) is obsolete and will be
>> > closed/deleted after the merge.
>> > We want backup to be a GA feature in 2.0
>> > We are going to support full backward compatibility for backup tool in
>> 2.0
>> > and onwards.
>> >
>> > **** Configuration
>> >
>> > Backup is disabled, by default. To enable it, the following
>> configuration
>> > properties must be added to hbase-site.xml:
>> >
>> > hbase.backup.enable=true
>> > hbase.master.logcleaner.plugins=YOUR_PLUGINS,org.
>> > apache.hadoop.hbase.backup.master.BackupLogCleaner
>> > hbase.procedure.master.classes=YOUR_CLASSES,org.
>> > apache.hadoop.hbase.backup.master.LogRollMasterProcedureManager
>> > hbase.procedure.regionserver.classes=YOUR_CLASSES,org.
>> > apache.hadoop.hbase.backup.regionserver.LogRollRegionServerProcedureMa
>> > nager
>> >
>> >
>> > I would like to thank IBM team and Jerry He for original work,
>> >
>> > Enis, Ted, Stack, Matteo, Jerry for time spent on code reviews
>> >
>> > Special thanks to Ted Yu for his co-development work.
>> >
>> > References:
>> >
>> > https://issues.apache.org/jira/browse/HBASE-7912 (original IBM,
>> contains
>> > design doc)
>> > https://issues.apache.org/jira/browse/HBASE-14030 (Phase 1)
>> > https://issues.apache.org/jira/browse/HBASE-14123 (Phase 2)
>> > https://issues.apache.org/jira/browse/HBASE-14414 (Phase 3)
>> >
>> > Please vote +1/-1 by midnight Pacific Time (00:00
>> > -0800 GMT) on March 11th on whether or not we should merge this into
>> the
>> > current master.
>> >
>> > -Vladimir Rodionov
>> >
>>
>
>
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
Posted by Vladimir Rodionov <vl...@gmail.com>.
No problem, we can extend deadline.
On Wed, Mar 8, 2017 at 3:31 PM, Ted Yu <yu...@gmail.com> 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 <vl...@gmail.com>
> wrote:
>
> > 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 reviews and has
> probably
> > the most lengthy discussion thread on Apache JIRA (HBASE-14123) :)
> >
> > The work has been split into 3 phases (HBASE-14030, 14123, 14414) Two
> first
> > are complete, third one is still in progress.
> >
> >
> > *** Summary of work HBASE-14123
> >
> > The new feature introduces new command-line extensions to the hbase
> command
> > and, from the client side, is accessible through command-line only
> > Operations:
> > * Create full backup on a list of tables or backup set
> > * Create incremental backup image for table list or backup set
> > * Restore list of tables from a given backup image
> > * Show current backup progress
> > * Delete backup image and all related images
> > * Show history of backups
> > * Backup set operations: create backup set, add/remove table to/from
> backup
> > set, etc
> >
> > In the current implementation, the feature is already usable, meaning
> that
> > users can backup tables and restore them using provided command-line
> tools.
> > Both: full and incremental backups are supported.
> > This work is based on original work of IBM team (HBASE-7912). The full
> list
> > of JIRAs included in this mega patch can be found in three umbrella
> JIRAs:
> > HBASE-14030 (Phase 1), HBASE-14123 (Phase 2) and HBASE-14414 (Phase 3 -
> all
> > resolved ones made it into the patch)
> >
> > *** What are the remaining work items
> >
> > All remaining items can be found in Phase 3 umbrella JIRA: HBASE-14414.
> > They are split into 3 groups: BLOCKER, CRITICAL, MAJOR
> > Only BLOCKERs and CRITICALs are guaranteed for HBase 2.0 release.
> >
> > ***** BLOCKER
> >
> > * HBASE-14417 Incremental backup and bulk loading ( Patch available)
> > * HBASE-14135 HBase Backup/Restore Phase 3: Merge backup images
> > * HBASE-14141 HBase Backup/Restore Phase 3: Filter WALs on backup to
> > include only edits from backup tables (Patch available)
> > * HBASE-17133 Backup documentation
> > * HBASE-15227 Fault tolerance support
> >
> > ***** CRITICAL
> >
> > * HBASE-16465 Disable split/merges during backup
> >
> > We have umbrella JIRA (HBASE-14414) to track all the remaining work
> > All the BLOCKER and CRITICAL JIRAs currently in open state will be
> > implemented by 2.0 release time. Some MAJOR too, but it depends on
> resource
> > availability
> > The former development branch (HBASE-7912) is obsolete and will be
> > closed/deleted after the merge.
> > We want backup to be a GA feature in 2.0
> > We are going to support full backward compatibility for backup tool in
> 2.0
> > and onwards.
> >
> > **** Configuration
> >
> > Backup is disabled, by default. To enable it, the following configuration
> > properties must be added to hbase-site.xml:
> >
> > hbase.backup.enable=true
> > hbase.master.logcleaner.plugins=YOUR_PLUGINS,org.
> > apache.hadoop.hbase.backup.master.BackupLogCleaner
> > hbase.procedure.master.classes=YOUR_CLASSES,org.
> > apache.hadoop.hbase.backup.master.LogRollMasterProcedureManager
> > hbase.procedure.regionserver.classes=YOUR_CLASSES,org.
> > apache.hadoop.hbase.backup.regionserver.LogRollRegionServerProcedureMa
> > nager
> >
> >
> > I would like to thank IBM team and Jerry He for original work,
> >
> > Enis, Ted, Stack, Matteo, Jerry for time spent on code reviews
> >
> > Special thanks to Ted Yu for his co-development work.
> >
> > References:
> >
> > https://issues.apache.org/jira/browse/HBASE-7912 (original IBM, contains
> > design doc)
> > https://issues.apache.org/jira/browse/HBASE-14030 (Phase 1)
> > https://issues.apache.org/jira/browse/HBASE-14123 (Phase 2)
> > https://issues.apache.org/jira/browse/HBASE-14414 (Phase 3)
> >
> > Please vote +1/-1 by midnight Pacific Time (00:00
> > -0800 GMT) on March 11th on whether or not we should merge this into
> the
> > current master.
> >
> > -Vladimir Rodionov
> >
>
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
Posted by Ted Yu <yu...@gmail.com>.
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 <vl...@gmail.com>
wrote:
> 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 reviews and has probably
> the most lengthy discussion thread on Apache JIRA (HBASE-14123) :)
>
> The work has been split into 3 phases (HBASE-14030, 14123, 14414) Two first
> are complete, third one is still in progress.
>
>
> *** Summary of work HBASE-14123
>
> The new feature introduces new command-line extensions to the hbase command
> and, from the client side, is accessible through command-line only
> Operations:
> * Create full backup on a list of tables or backup set
> * Create incremental backup image for table list or backup set
> * Restore list of tables from a given backup image
> * Show current backup progress
> * Delete backup image and all related images
> * Show history of backups
> * Backup set operations: create backup set, add/remove table to/from backup
> set, etc
>
> In the current implementation, the feature is already usable, meaning that
> users can backup tables and restore them using provided command-line tools.
> Both: full and incremental backups are supported.
> This work is based on original work of IBM team (HBASE-7912). The full list
> of JIRAs included in this mega patch can be found in three umbrella JIRAs:
> HBASE-14030 (Phase 1), HBASE-14123 (Phase 2) and HBASE-14414 (Phase 3 - all
> resolved ones made it into the patch)
>
> *** What are the remaining work items
>
> All remaining items can be found in Phase 3 umbrella JIRA: HBASE-14414.
> They are split into 3 groups: BLOCKER, CRITICAL, MAJOR
> Only BLOCKERs and CRITICALs are guaranteed for HBase 2.0 release.
>
> ***** BLOCKER
>
> * HBASE-14417 Incremental backup and bulk loading ( Patch available)
> * HBASE-14135 HBase Backup/Restore Phase 3: Merge backup images
> * HBASE-14141 HBase Backup/Restore Phase 3: Filter WALs on backup to
> include only edits from backup tables (Patch available)
> * HBASE-17133 Backup documentation
> * HBASE-15227 Fault tolerance support
>
> ***** CRITICAL
>
> * HBASE-16465 Disable split/merges during backup
>
> We have umbrella JIRA (HBASE-14414) to track all the remaining work
> All the BLOCKER and CRITICAL JIRAs currently in open state will be
> implemented by 2.0 release time. Some MAJOR too, but it depends on resource
> availability
> The former development branch (HBASE-7912) is obsolete and will be
> closed/deleted after the merge.
> We want backup to be a GA feature in 2.0
> We are going to support full backward compatibility for backup tool in 2.0
> and onwards.
>
> **** Configuration
>
> Backup is disabled, by default. To enable it, the following configuration
> properties must be added to hbase-site.xml:
>
> hbase.backup.enable=true
> hbase.master.logcleaner.plugins=YOUR_PLUGINS,org.
> apache.hadoop.hbase.backup.master.BackupLogCleaner
> hbase.procedure.master.classes=YOUR_CLASSES,org.
> apache.hadoop.hbase.backup.master.LogRollMasterProcedureManager
> hbase.procedure.regionserver.classes=YOUR_CLASSES,org.
> apache.hadoop.hbase.backup.regionserver.LogRollRegionServerProcedureMa
> nager
>
>
> I would like to thank IBM team and Jerry He for original work,
>
> Enis, Ted, Stack, Matteo, Jerry for time spent on code reviews
>
> Special thanks to Ted Yu for his co-development work.
>
> References:
>
> https://issues.apache.org/jira/browse/HBASE-7912 (original IBM, contains
> design doc)
> https://issues.apache.org/jira/browse/HBASE-14030 (Phase 1)
> https://issues.apache.org/jira/browse/HBASE-14123 (Phase 2)
> https://issues.apache.org/jira/browse/HBASE-14414 (Phase 3)
>
> Please vote +1/-1 by midnight Pacific Time (00:00
> -0800 GMT) on March 11th on whether or not we should merge this into the
> current master.
>
> -Vladimir Rodionov
>
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
Posted by Vladimir Rodionov <vl...@gmail.com>.
Still need one more +1
On Thu, Mar 9, 2017 at 11:27 PM, Vladimir Rodionov <vl...@gmail.com>
wrote:
> bump
>
> On Thu, Mar 9, 2017 at 10:11 AM, Ted Yu <yu...@gmail.com> wrote:
>
>> +1 from me as well.
>>
>> On Wed, Mar 8, 2017 at 3:48 PM, Enis Söztutar <en...@apache.org> 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
>> > development can continue in master, and there is more exposure for
>> testing,
>> > etc.
>> >
>> > Enis
>> >
>> > On Wed, Mar 8, 2017 at 1:32 PM, Vladimir Rodionov <
>> vladrodionov@gmail.com>
>> > wrote:
>> >
>> > > 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 reviews and has
>> > probably
>> > > the most lengthy discussion thread on Apache JIRA (HBASE-14123) :)
>> > >
>> > > The work has been split into 3 phases (HBASE-14030, 14123, 14414) Two
>> > first
>> > > are complete, third one is still in progress.
>> > >
>> > >
>> > > *** Summary of work HBASE-14123
>> > >
>> > > The new feature introduces new command-line extensions to the hbase
>> > command
>> > > and, from the client side, is accessible through command-line only
>> > > Operations:
>> > > * Create full backup on a list of tables or backup set
>> > > * Create incremental backup image for table list or backup set
>> > > * Restore list of tables from a given backup image
>> > > * Show current backup progress
>> > > * Delete backup image and all related images
>> > > * Show history of backups
>> > > * Backup set operations: create backup set, add/remove table to/from
>> > backup
>> > > set, etc
>> > >
>> > > In the current implementation, the feature is already usable, meaning
>> > that
>> > > users can backup tables and restore them using provided command-line
>> > tools.
>> > > Both: full and incremental backups are supported.
>> > > This work is based on original work of IBM team (HBASE-7912). The full
>> > list
>> > > of JIRAs included in this mega patch can be found in three umbrella
>> > JIRAs:
>> > > HBASE-14030 (Phase 1), HBASE-14123 (Phase 2) and HBASE-14414 (Phase 3
>> -
>> > all
>> > > resolved ones made it into the patch)
>> > >
>> > > *** What are the remaining work items
>> > >
>> > > All remaining items can be found in Phase 3 umbrella JIRA:
>> HBASE-14414.
>> > > They are split into 3 groups: BLOCKER, CRITICAL, MAJOR
>> > > Only BLOCKERs and CRITICALs are guaranteed for HBase 2.0 release.
>> > >
>> > > ***** BLOCKER
>> > >
>> > > * HBASE-14417 Incremental backup and bulk loading ( Patch available)
>> > > * HBASE-14135 HBase Backup/Restore Phase 3: Merge backup images
>> > > * HBASE-14141 HBase Backup/Restore Phase 3: Filter WALs on backup to
>> > > include only edits from backup tables (Patch available)
>> > > * HBASE-17133 Backup documentation
>> > > * HBASE-15227 Fault tolerance support
>> > >
>> > > ***** CRITICAL
>> > >
>> > > * HBASE-16465 Disable split/merges during backup
>> > >
>> > > We have umbrella JIRA (HBASE-14414) to track all the remaining work
>> > > All the BLOCKER and CRITICAL JIRAs currently in open state will be
>> > > implemented by 2.0 release time. Some MAJOR too, but it depends on
>> > resource
>> > > availability
>> > > The former development branch (HBASE-7912) is obsolete and will be
>> > > closed/deleted after the merge.
>> > > We want backup to be a GA feature in 2.0
>> > > We are going to support full backward compatibility for backup tool in
>> > 2.0
>> > > and onwards.
>> > >
>> > > **** Configuration
>> > >
>> > > Backup is disabled, by default. To enable it, the following
>> configuration
>> > > properties must be added to hbase-site.xml:
>> > >
>> > > hbase.backup.enable=true
>> > > hbase.master.logcleaner.plugins=YOUR_PLUGINS,org.
>> > > apache.hadoop.hbase.backup.master.BackupLogCleaner
>> > > hbase.procedure.master.classes=YOUR_CLASSES,org.
>> > > apache.hadoop.hbase.backup.master.LogRollMasterProcedureManager
>> > > hbase.procedure.regionserver.classes=YOUR_CLASSES,org.
>> > > apache.hadoop.hbase.backup.regionserver.LogRollRegionServerP
>> rocedureMa
>> > > nager
>> > >
>> > >
>> > > I would like to thank IBM team and Jerry He for original work,
>> > >
>> > > Enis, Ted, Stack, Matteo, Jerry for time spent on code reviews
>> > >
>> > > Special thanks to Ted Yu for his co-development work.
>> > >
>> > > References:
>> > >
>> > > https://issues.apache.org/jira/browse/HBASE-7912 (original IBM,
>> contains
>> > > design doc)
>> > > https://issues.apache.org/jira/browse/HBASE-14030 (Phase 1)
>> > > https://issues.apache.org/jira/browse/HBASE-14123 (Phase 2)
>> > > https://issues.apache.org/jira/browse/HBASE-14414 (Phase 3)
>> > >
>> > > Please vote +1/-1 by midnight Pacific Time (00:00
>> > > -0800 GMT) on March 11th on whether or not we should merge this into
>> > the
>> > > current master.
>> > >
>> > > -Vladimir Rodionov
>> > >
>> >
>>
>
>
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
Posted by Vladimir Rodionov <vl...@gmail.com>.
bump
On Thu, Mar 9, 2017 at 10:11 AM, Ted Yu <yu...@gmail.com> wrote:
> +1 from me as well.
>
> On Wed, Mar 8, 2017 at 3:48 PM, Enis Söztutar <en...@apache.org> 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
> > development can continue in master, and there is more exposure for
> testing,
> > etc.
> >
> > Enis
> >
> > On Wed, Mar 8, 2017 at 1:32 PM, Vladimir Rodionov <
> vladrodionov@gmail.com>
> > wrote:
> >
> > > 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 reviews and has
> > probably
> > > the most lengthy discussion thread on Apache JIRA (HBASE-14123) :)
> > >
> > > The work has been split into 3 phases (HBASE-14030, 14123, 14414) Two
> > first
> > > are complete, third one is still in progress.
> > >
> > >
> > > *** Summary of work HBASE-14123
> > >
> > > The new feature introduces new command-line extensions to the hbase
> > command
> > > and, from the client side, is accessible through command-line only
> > > Operations:
> > > * Create full backup on a list of tables or backup set
> > > * Create incremental backup image for table list or backup set
> > > * Restore list of tables from a given backup image
> > > * Show current backup progress
> > > * Delete backup image and all related images
> > > * Show history of backups
> > > * Backup set operations: create backup set, add/remove table to/from
> > backup
> > > set, etc
> > >
> > > In the current implementation, the feature is already usable, meaning
> > that
> > > users can backup tables and restore them using provided command-line
> > tools.
> > > Both: full and incremental backups are supported.
> > > This work is based on original work of IBM team (HBASE-7912). The full
> > list
> > > of JIRAs included in this mega patch can be found in three umbrella
> > JIRAs:
> > > HBASE-14030 (Phase 1), HBASE-14123 (Phase 2) and HBASE-14414 (Phase 3 -
> > all
> > > resolved ones made it into the patch)
> > >
> > > *** What are the remaining work items
> > >
> > > All remaining items can be found in Phase 3 umbrella JIRA: HBASE-14414.
> > > They are split into 3 groups: BLOCKER, CRITICAL, MAJOR
> > > Only BLOCKERs and CRITICALs are guaranteed for HBase 2.0 release.
> > >
> > > ***** BLOCKER
> > >
> > > * HBASE-14417 Incremental backup and bulk loading ( Patch available)
> > > * HBASE-14135 HBase Backup/Restore Phase 3: Merge backup images
> > > * HBASE-14141 HBase Backup/Restore Phase 3: Filter WALs on backup to
> > > include only edits from backup tables (Patch available)
> > > * HBASE-17133 Backup documentation
> > > * HBASE-15227 Fault tolerance support
> > >
> > > ***** CRITICAL
> > >
> > > * HBASE-16465 Disable split/merges during backup
> > >
> > > We have umbrella JIRA (HBASE-14414) to track all the remaining work
> > > All the BLOCKER and CRITICAL JIRAs currently in open state will be
> > > implemented by 2.0 release time. Some MAJOR too, but it depends on
> > resource
> > > availability
> > > The former development branch (HBASE-7912) is obsolete and will be
> > > closed/deleted after the merge.
> > > We want backup to be a GA feature in 2.0
> > > We are going to support full backward compatibility for backup tool in
> > 2.0
> > > and onwards.
> > >
> > > **** Configuration
> > >
> > > Backup is disabled, by default. To enable it, the following
> configuration
> > > properties must be added to hbase-site.xml:
> > >
> > > hbase.backup.enable=true
> > > hbase.master.logcleaner.plugins=YOUR_PLUGINS,org.
> > > apache.hadoop.hbase.backup.master.BackupLogCleaner
> > > hbase.procedure.master.classes=YOUR_CLASSES,org.
> > > apache.hadoop.hbase.backup.master.LogRollMasterProcedureManager
> > > hbase.procedure.regionserver.classes=YOUR_CLASSES,org.
> > > apache.hadoop.hbase.backup.regionserver.LogRollRegionServerProcedureMa
> > > nager
> > >
> > >
> > > I would like to thank IBM team and Jerry He for original work,
> > >
> > > Enis, Ted, Stack, Matteo, Jerry for time spent on code reviews
> > >
> > > Special thanks to Ted Yu for his co-development work.
> > >
> > > References:
> > >
> > > https://issues.apache.org/jira/browse/HBASE-7912 (original IBM,
> contains
> > > design doc)
> > > https://issues.apache.org/jira/browse/HBASE-14030 (Phase 1)
> > > https://issues.apache.org/jira/browse/HBASE-14123 (Phase 2)
> > > https://issues.apache.org/jira/browse/HBASE-14414 (Phase 3)
> > >
> > > Please vote +1/-1 by midnight Pacific Time (00:00
> > > -0800 GMT) on March 11th on whether or not we should merge this into
> > the
> > > current master.
> > >
> > > -Vladimir Rodionov
> > >
> >
>
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
Posted by Ted Yu <yu...@gmail.com>.
+1 from me as well.
On Wed, Mar 8, 2017 at 3:48 PM, Enis Söztutar <en...@apache.org> 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
> development can continue in master, and there is more exposure for testing,
> etc.
>
> Enis
>
> On Wed, Mar 8, 2017 at 1:32 PM, Vladimir Rodionov <vl...@gmail.com>
> wrote:
>
> > 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 reviews and has
> probably
> > the most lengthy discussion thread on Apache JIRA (HBASE-14123) :)
> >
> > The work has been split into 3 phases (HBASE-14030, 14123, 14414) Two
> first
> > are complete, third one is still in progress.
> >
> >
> > *** Summary of work HBASE-14123
> >
> > The new feature introduces new command-line extensions to the hbase
> command
> > and, from the client side, is accessible through command-line only
> > Operations:
> > * Create full backup on a list of tables or backup set
> > * Create incremental backup image for table list or backup set
> > * Restore list of tables from a given backup image
> > * Show current backup progress
> > * Delete backup image and all related images
> > * Show history of backups
> > * Backup set operations: create backup set, add/remove table to/from
> backup
> > set, etc
> >
> > In the current implementation, the feature is already usable, meaning
> that
> > users can backup tables and restore them using provided command-line
> tools.
> > Both: full and incremental backups are supported.
> > This work is based on original work of IBM team (HBASE-7912). The full
> list
> > of JIRAs included in this mega patch can be found in three umbrella
> JIRAs:
> > HBASE-14030 (Phase 1), HBASE-14123 (Phase 2) and HBASE-14414 (Phase 3 -
> all
> > resolved ones made it into the patch)
> >
> > *** What are the remaining work items
> >
> > All remaining items can be found in Phase 3 umbrella JIRA: HBASE-14414.
> > They are split into 3 groups: BLOCKER, CRITICAL, MAJOR
> > Only BLOCKERs and CRITICALs are guaranteed for HBase 2.0 release.
> >
> > ***** BLOCKER
> >
> > * HBASE-14417 Incremental backup and bulk loading ( Patch available)
> > * HBASE-14135 HBase Backup/Restore Phase 3: Merge backup images
> > * HBASE-14141 HBase Backup/Restore Phase 3: Filter WALs on backup to
> > include only edits from backup tables (Patch available)
> > * HBASE-17133 Backup documentation
> > * HBASE-15227 Fault tolerance support
> >
> > ***** CRITICAL
> >
> > * HBASE-16465 Disable split/merges during backup
> >
> > We have umbrella JIRA (HBASE-14414) to track all the remaining work
> > All the BLOCKER and CRITICAL JIRAs currently in open state will be
> > implemented by 2.0 release time. Some MAJOR too, but it depends on
> resource
> > availability
> > The former development branch (HBASE-7912) is obsolete and will be
> > closed/deleted after the merge.
> > We want backup to be a GA feature in 2.0
> > We are going to support full backward compatibility for backup tool in
> 2.0
> > and onwards.
> >
> > **** Configuration
> >
> > Backup is disabled, by default. To enable it, the following configuration
> > properties must be added to hbase-site.xml:
> >
> > hbase.backup.enable=true
> > hbase.master.logcleaner.plugins=YOUR_PLUGINS,org.
> > apache.hadoop.hbase.backup.master.BackupLogCleaner
> > hbase.procedure.master.classes=YOUR_CLASSES,org.
> > apache.hadoop.hbase.backup.master.LogRollMasterProcedureManager
> > hbase.procedure.regionserver.classes=YOUR_CLASSES,org.
> > apache.hadoop.hbase.backup.regionserver.LogRollRegionServerProcedureMa
> > nager
> >
> >
> > I would like to thank IBM team and Jerry He for original work,
> >
> > Enis, Ted, Stack, Matteo, Jerry for time spent on code reviews
> >
> > Special thanks to Ted Yu for his co-development work.
> >
> > References:
> >
> > https://issues.apache.org/jira/browse/HBASE-7912 (original IBM, contains
> > design doc)
> > https://issues.apache.org/jira/browse/HBASE-14030 (Phase 1)
> > https://issues.apache.org/jira/browse/HBASE-14123 (Phase 2)
> > https://issues.apache.org/jira/browse/HBASE-14414 (Phase 3)
> >
> > Please vote +1/-1 by midnight Pacific Time (00:00
> > -0800 GMT) on March 11th on whether or not we should merge this into
> the
> > current master.
> >
> > -Vladimir Rodionov
> >
>
Re: [VOTE] Backup/Restore feature for HBase 2.0, vote closing 3/11/2017
Posted by Enis Söztutar <en...@apache.org>.
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.
Enis
On Wed, Mar 8, 2017 at 1:32 PM, Vladimir Rodionov <vl...@gmail.com>
wrote:
> 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 reviews and has probably
> the most lengthy discussion thread on Apache JIRA (HBASE-14123) :)
>
> The work has been split into 3 phases (HBASE-14030, 14123, 14414) Two first
> are complete, third one is still in progress.
>
>
> *** Summary of work HBASE-14123
>
> The new feature introduces new command-line extensions to the hbase command
> and, from the client side, is accessible through command-line only
> Operations:
> * Create full backup on a list of tables or backup set
> * Create incremental backup image for table list or backup set
> * Restore list of tables from a given backup image
> * Show current backup progress
> * Delete backup image and all related images
> * Show history of backups
> * Backup set operations: create backup set, add/remove table to/from backup
> set, etc
>
> In the current implementation, the feature is already usable, meaning that
> users can backup tables and restore them using provided command-line tools.
> Both: full and incremental backups are supported.
> This work is based on original work of IBM team (HBASE-7912). The full list
> of JIRAs included in this mega patch can be found in three umbrella JIRAs:
> HBASE-14030 (Phase 1), HBASE-14123 (Phase 2) and HBASE-14414 (Phase 3 - all
> resolved ones made it into the patch)
>
> *** What are the remaining work items
>
> All remaining items can be found in Phase 3 umbrella JIRA: HBASE-14414.
> They are split into 3 groups: BLOCKER, CRITICAL, MAJOR
> Only BLOCKERs and CRITICALs are guaranteed for HBase 2.0 release.
>
> ***** BLOCKER
>
> * HBASE-14417 Incremental backup and bulk loading ( Patch available)
> * HBASE-14135 HBase Backup/Restore Phase 3: Merge backup images
> * HBASE-14141 HBase Backup/Restore Phase 3: Filter WALs on backup to
> include only edits from backup tables (Patch available)
> * HBASE-17133 Backup documentation
> * HBASE-15227 Fault tolerance support
>
> ***** CRITICAL
>
> * HBASE-16465 Disable split/merges during backup
>
> We have umbrella JIRA (HBASE-14414) to track all the remaining work
> All the BLOCKER and CRITICAL JIRAs currently in open state will be
> implemented by 2.0 release time. Some MAJOR too, but it depends on resource
> availability
> The former development branch (HBASE-7912) is obsolete and will be
> closed/deleted after the merge.
> We want backup to be a GA feature in 2.0
> We are going to support full backward compatibility for backup tool in 2.0
> and onwards.
>
> **** Configuration
>
> Backup is disabled, by default. To enable it, the following configuration
> properties must be added to hbase-site.xml:
>
> hbase.backup.enable=true
> hbase.master.logcleaner.plugins=YOUR_PLUGINS,org.
> apache.hadoop.hbase.backup.master.BackupLogCleaner
> hbase.procedure.master.classes=YOUR_CLASSES,org.
> apache.hadoop.hbase.backup.master.LogRollMasterProcedureManager
> hbase.procedure.regionserver.classes=YOUR_CLASSES,org.
> apache.hadoop.hbase.backup.regionserver.LogRollRegionServerProcedureMa
> nager
>
>
> I would like to thank IBM team and Jerry He for original work,
>
> Enis, Ted, Stack, Matteo, Jerry for time spent on code reviews
>
> Special thanks to Ted Yu for his co-development work.
>
> References:
>
> https://issues.apache.org/jira/browse/HBASE-7912 (original IBM, contains
> design doc)
> https://issues.apache.org/jira/browse/HBASE-14030 (Phase 1)
> https://issues.apache.org/jira/browse/HBASE-14123 (Phase 2)
> https://issues.apache.org/jira/browse/HBASE-14414 (Phase 3)
>
> Please vote +1/-1 by midnight Pacific Time (00:00
> -0800 GMT) on March 11th on whether or not we should merge this into the
> current master.
>
> -Vladimir Rodionov
>