hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matteo Bertozzi <theo.berto...@gmail.com>
Subject Re: [DISCUSS] Backporting Regionserver Groups (HBASE-6721) to 1.x and 0.98
Date Thu, 17 Mar 2016 15:26:48 GMT
If we cut master now we have
 - no rolling upgrade (am switched to zkless only and the other code was
removed)
 - no api compatibility (we removed the deprecated)
 - Offheaping on the read path
 - Spark
 - MOB
 - RS Groups
 - some other stuff...

is that worth a major?
The offheaping work is probably the one that cannot be backported and it
may be nice to have.
but stuff like spark, mob and RS Groups can be in a 1.x and avoid migration
pain, and those are probably the ones that some people wants to try now.

If we have a 2.0 for features like Spark, Mob and RS Groups I'd like to
have it based on branch-1. At least users can move there without having to
worry about compatibility, even if the version number itself will probably
force the users to stick with the 1.x because the assumption is that
something will break or there is a migration required.

On Thu, Mar 17, 2016 at 8:05 AM, Andrew Purtell <andrew.purtell@gmail.com>
wrote:

> I don't think we need to do a major for RS groups.
>
> I do think Elliott's points can be addressed by getting a 2.0 out the door
> soon containing whatever we have on deck now to go in.
>
> Probably not going to satisfy everyone here - but maybe?
>
>
> > On Mar 17, 2016, at 7:48 AM, Matteo Bertozzi <theo.bertozzi@gmail.com>
> wrote:
> >
> > Why MOB and RegionServer Groups should be in a new major version and
> stuff
> > like the new RPC queue (HBASE-15136), date based tiered compactions
> > (HBASE-15181), special handling for system tables WALs (HBASE-13557),
> keep
> > table state in meta (HBASE-13017) or the Region Normalizer (HBASE-13103)
> > are considered for or already in 1.x?
> >
> > to me, and probably most of the users, a new Major version means that
> APIs
> > will break, wire may break, there may be an upgrade of some sort and so
> on.
> > which is not true for MOB and RS groups.
> >
> > In case we do a major for RS groups and Mob will that still based on the
> > 1.x branch?
> >
> > On Wed, Mar 16, 2016 at 11:23 PM, Andrew Purtell <
> andrew.purtell@gmail.com>
> > wrote:
> >
> >> I remember explicitly saying I was not against a backport of the MOB
> >> feature. You are misrepresenting my position a bit. Sure, I'm a skeptic.
> >> Not a big deal because I don't think we can or should seek a blanket
> rule.
> >> Sometimes a feature will have sufficient interest and applicability
> that a
> >> backport is worth considering, and then there's a question of what kind
> of
> >> risk the changes envisioned carry. RS groups as implemented are low
> risk.
> >> Meanwhile MOB is highly invasive. I think RS groups would have two large
> >> production users soon after introduction into branch-1. I'm not sure
> about
> >> MOB. They are worth consideration on their own merits and on user demand
> >> for them.
> >>
> >> Another thing we could do is get 2.0 started right now. Whatever major
> >> that doesn't make the cut could go into 3.0. I think the requests for
> these
> >> backports are coming because there is no near time horizon for a 2.0
> >> release. So set it soon?
> >>
> >>
> >>> On Mar 16, 2016, at 9:27 PM, Elliott Clark <eclark@apache.org> wrote:
> >>>
> >>> On Wed, Mar 16, 2016 at 6:26 PM, Andrew Purtell <
> >> andrew.purtell@gmail.com>
> >>> wrote:
> >>>
> >>>> Because I for one might well want to run RS groups in production with
> >>>> branch-1 code without waiting for or dealing with the other stuff
> >> coming in
> >>>> any 2.0.
> >>>
> >>>
> >>> This is the same email that I sent for MOB. Which you agreed with then.
> >> But
> >>> not now. There's nothing substantively different about this feature
> that
> >>> makes it different from any other feature. It's a large change that
> >> wasn't
> >>> there in 1.X line.
> >>>
> >>> I would like backups, and procedure v2 in 1.x. However even if it
> landed
> >>> tomorrow they shouldn't be back ported as it's a large feature that's
> not
> >>> ready. If we want anyone to ever upgrade major versions, then the new
> >>> features have to come along with the new apis. Other wise we will end
> up
> >> in
> >>> the same state that Hadoop has.
> >>
>

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