hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Rodionov <vladrodio...@gmail.com>
Subject Re: [DISCUSSION] Items to purge from branch-2 before we cut hbase-2.0.0-beta1.
Date Wed, 01 Nov 2017 22:33:38 GMT
>> HBASE-19106 at least is a fundamental

This new feature was requested 9 days ago (between alpha 3 and alpha 4
releases) It has never been on a list of features we has agreed to
implement for 2.0 release.
When backup started almost 2 years ago, we described what features and
capabilities will be implemented. We have had a discussions before and I do
not remember any
complaints from community that we lack important functionalities

You can not point to it as a blocker for 2.0 release, Stack.

Testing at scale (lack of) - the only real issue I see in B&R now. The
question: can it justify your willingness to postpone feature till  next
2.x release, Stack?

All blockers are resolved, including pending HBASE-17852 patch. All
functionality for 2.0  has been implemented.   Scalability and performance
improvements patch is in working
and expected to be ready next week. In any case, this is improvement - not
a new feature.

We have been testing B&R in our internal QA clusters for months. Others
(SF) have done testing as well. I am pretty confident in implementation.

On Wed, Nov 1, 2017 at 3:15 PM, Josh Elser <elserj@apache.org> wrote:

> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message