hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <els...@apache.org>
Subject Re: [DISCUSSION] Items to purge from branch-2 before we cut hbase-2.0.0-beta1.
Date Wed, 01 Nov 2017 22:15:23 GMT
On 11/1/17 5:52 PM, Stack wrote:
> On Wed, Nov 1, 2017 at 12:25 PM, Vladimir Rodionov<vladrodionov@gmail.com>
> wrote:
> 
>> 1. HBASE-19104 - 19109
>>
>> None of them are basic, Stack. These requests came from SF after discussion
>> we had with them recently
>> No single comments is because I was out of country last week.
>>
>> 2. Backup tables are not system ones, they belong to a separate namespace -
>> "backup"
>>
>> 3. We make no assumptions on assignment order of these tables.
>>
>> As for real scale testing and documentation , we still have time before
>> 2.0GA.  Can't be blocker IMO
>>
>>
> First off, wrong response.
> 
> Better would have been pointers to a description of the feature as it
> stands in branch-2 (a list of JIRAs is insufficient), what is to be done
> still, and evidence of heavy testing in particular at scale (as Josh
> reminds us, we agreed to last time backup-in-hbase2 was broached) ending
> with list of what will be done between here and beta-1 to assuage any
> concerns that backup is incomplete. As to the issues filed, IMO,
> HBASE-19106 at least is a fundamental. W/o it, how you even know backup
> works at anything above toy scale.
> 
> Pardon my mistake on 'system' tables. I'd made the statement 9 days ago up
> in HBASE-17852 trying to figure what was going on in the issue and it stood
> unchallenged (Josh did let me know later that you were traveling).
> 
> I'm not up for waiting till GA before we decide what is in the release.
> This DISCUSSION is about deciding now, before beta-1, whats in and whats
> out. Backup would be a great to have but it is currently on the chopping
> block. I've tried to spend time figuring what is there and where it stands
> but I always end up stymied (e.g. see HBASE-17852; see how it starts out;
> see the patch attached w/ no description of what it comprises or the
> approach decided upon; and so on). Maybe its me, but hey, unfortunately,
> its me who is the RM.

As much as it pains me, I can't argue with the lack of confidence via 
testing. While it feels like an eternity ago since we posited on B&R's 
scale/correctness testing, it's only been 1.5 months. In reality, 
getting to this was delayed by some of the (really good!) FT fixes that 
Vlad has made.

We set the bar for the feature and we missed it; there's not arguing 
that. Yes, it stinks. I see two paths forward: 1) come up with its own 
release to let those downstream use it now (risks withstanding) or 2) 
shoot for HBase 2.1.0. The latter is how we've approached this in the 
past. Building the test needs to happen regardless of the release vehicle.

New issues/feature-requests are always going to come in as people 
experiment with it. I hope to avoid getting bogged down in this -- I 
sincerely doubt that there is any single answer to what is "required" 
for an initial backup and restore implementation. I feel like anything 
more will turn into a battle of opinions. When we bring up the feature 
again, we should make a concerted effort to say "this is the state of 
the feature, with the design choices made, and this the result of our 
testing for correctness." Hopefully much of this is already contained in 
documentation and just needs to be collected/curated.

- Josh

Mime
View raw message