>> 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 <[email protected]> wrote: > On 11/1/17 5:52 PM, Stack wrote: > >> On Wed, Nov 1, 2017 at 12:25 PM, Vladimir Rodionov<[email protected] >> > >> 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 >
