On Wed, Nov 1, 2017 at 12:25 PM, Vladimir Rodionov <[email protected]> wrote:
> >>I've not done in-depth research so could be wrong about backup, but from > my > >>perch, I've seen the recent filings against backup, HBASE-19104-19109, > >>which strike me as pretty basic missing facility. The new issues go > without > >>comment (caveat a single question). I've seen no evidence of extensive > test > >>(scale?). The last issue I looked at has backup putting up two system > >>tables with presumptions about assignment order we do not (as yet) > support. > >>I've always had trouble eliciting state of the feature; summary of > >>capability and what is to do are hard to come by. > > 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. Thanks, St.Ack > On Wed, Nov 1, 2017 at 12:17 PM, Vladimir Rodionov <[email protected] > > > wrote: > > > >>I dont' want to get drawn into another unfriendly argument, but this is > > >>simply not true. We filed a bunch of JIRAs including one with serious > > >>concerns about scalability. > > > > Can you explain please how did you guys manage to file multiple JIRAs > > (trivials mostly) > > without testing backup/restore? > > > > What you are referring to is not a scalability (its scalable), but > > *possible* performance issue of incremental backup > > We have JIRA and partial patch to address this issue HBASE-17825. This > > will definitely make it into beta-1. > > > > > > On Wed, Nov 1, 2017 at 12:00 PM, Stack <[email protected]> wrote: > > > >> On Wed, Nov 1, 2017 at 11:53 AM, Josh Elser <[email protected]> wrote: > >> > >> > > >> > > >> > On 11/1/17 1:32 PM, Stack wrote: > >> > > >> >> I want to purge the below list of modules, features, and abandoned > code > >> >> from branch-2 before we make a beta-1 (4-5 weeks I'm thinking). Lets > >> >> discuss. Some are already scheduled for removal but listing anyways > for > >> >> completeness sake. Pushback or other suggestions on what else we > should > >> >> remove are welcome. > >> >> > >> >> Distributed Log Replay: Just last week, I heard of someone scheduling > >> >> testing of DLR. We need to better message that this never worked and > >> >> was/is > >> >> not supported. It's a good idea that we should implement but built > on a > >> >> different chasis (procedurev2?). Meantime, DLR is still scattered > about > >> >> the > >> >> codebase as an optional code path. Lets remove it. > >> >> > >> >> hbase-native-client: It is not done and won't be for 2.0.0. It can > >> come in > >> >> later when it is done (2.1 or 3.0). > >> >> > >> > > >> > I think that's fine. It's in a state where people can use it to do > basic > >> > read-write operations. While it would be nice to have this go out to > >> folks > >> > who would test it, forcing that to happen via inclusion in a release > >> isn't > >> > necessary. > >> > > >> > > >> > >> Grand. > >> > >> > >> > >> > hbase-prefix-tree: A visionary effort that unfortunately has had no > >> uptake > >> >> since its original wizard-author moved on. I don't believe it is used > >> >> anywhere. It has become a drag as global changes need to be applied > in > >> >> here > >> >> too by folks who are not up on how it works probably doing damage > along > >> >> the > >> >> way. This is like DLR in it should be first class but we've not done > >> the > >> >> work to keep it up. > >> >> > >> >> hbase-backup: Not done and it doesn't look like it will be done for > >> >> beta-1. > >> >> It can come in later in a 2.1 or 3.0 when it is finished. > >> >> > >> > > >> > Ditto to what Vlad said. AFAIK, just the one issue remains: > HBASE-17852. > >> > Didn't want to bother you with it while you were head-down on alpha4, > >> > Stack; can you take a look at the explanation Vlad has put up there so > >> we > >> > can try to move it forward? I don't think this needs to be punted out. > >> > > >> > > >> I'll take a look sir. > >> > >> > >> > >> > hbase-spark: Purging this makes me tear-up. > >> >> > >> > > >> > We had a talk about this a while back, didn't we? I forget if we had > >> > consensus about having it follow its own release schedule (rather than > >> > tying it to HBase "internals") -- I think I suggested that anyways :P. > >> > > >> > > >> Sean filed HBASE-18817 <https://issues.apache.org/ > jira/browse/HBASE-18817> > >> with > >> the result of that discussion. > >> > >> > >> > >> > Now that I'm thinking about it, I wonder if that's actually the proper > >> > route forward for hbase-native-client too... > >> > > >> > > >> And backup? > >> > >> Thanks Josh. > >> St.Ack > >> > >> > >> > >> > >> > What else? > >> >> > >> >> Thanks, > >> >> St.Ack > >> >> > >> >> > >> > > > > >
