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 19:17:57 GMT
>>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 <stack@duboce.net> wrote:

> On Wed, Nov 1, 2017 at 11:53 AM, Josh Elser <elserj@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
> >>
> >>
>

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