hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <bus...@apache.org>
Subject Re: [DISCUSSION] Merge Backup / Restore - Branch HBASE-7912
Date Wed, 07 Sep 2016 15:23:29 GMT
On Tue, Sep 6, 2016 at 10:36 PM, Josh Elser <josh.elser@gmail.com> wrote:
> So, the answer to Sean's original question is "as robust as snapshots
> presently are"? (independence of backup/restore failure tolerance from
> snapshot failure tolerance)
> Is this just a question WRT context of the change, or is it means for a veto
> from you, Sean? Just trying to make sure I'm following along adequately.

I'd say ATM I'm -0, bordering on -1 but not for reasons I can articulate well.

Here's an attempt.

We've been trying to move, as a community, towards minimizing risk to
downstream folks by getting "complete enough for use" gates in place
before we introduce new features. This was spurred by a some features
getting in half-baked and never making it to "can really use" status
(I'm thinking of distributed log replay and the zk-less assignment
stuff, I don't recall if there was more).

The gates, generally, included things like:

* have docs
* have sunny-day correctness tests
* have correctness-in-face-of-failure tests
* don't rely on things outside of HBase for normal operation (okay for
advanced operation)

As an example, we kept the MOB work off in a branch and out of master
until it could pass these criteria. The big exemption we've had to
this was the hbase-spark integration, where we all agreed it could
land in master because it was very well isolated (the slide away from
including docs as a first-class part of building up that integration
has led me to doubt the wisdom of this decision).

We've also been treating inclusion in a "probably will be released to
downstream" branches as a higher bar, requiring

* don't moderately impact performance when the feature isn't in use
* don't severely impact performance when the feature is in use
* either default-to-on or show enough demand to believe a non-trivial
number of folks will turn the feature on

The above has kept MOB and hbase-spark integration out of branch-1,
presumably while they've "gotten more stable" in master from the odd
vendor inclusion.

Are we going to have a 2.0 release before the end of the year? We're
coming up on 1.5 years since the release of version 1.0; seems like
it's about time, though I haven't seen any concrete plans this year.
Presuming we are going to have one by the end of the year, it seems a
bit close to still be adding in "features that need maturing" on the

The lack of a concrete plan for 2.0 keeps me from considering these
things blocker at the moment. But I know first hand how much trouble
folks have had with other features that have gone into downstream
facing releases without robustness checks (i.e. replication), and I'm
concerned about what we're setting up if 2.0 goes out with this
feature in its current state.

View raw message