>>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 On Wed, Nov 1, 2017 at 12:17 PM, Vladimir Rodionov <vladrodio...@gmail.com> 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 <st...@duboce.net> wrote: > >> On Wed, Nov 1, 2017 at 11:53 AM, Josh Elser <els...@apache.org> 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 >> >> >> >> >> > >
