hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <bus...@cloudera.com>
Subject Re: [DISCUSS] Backporting Regionserver Groups (HBASE-6721) to 1.x and 0.98
Date Mon, 21 Mar 2016 17:22:48 GMT
Hadoop's trunk branch hasn't had a release in a very very long time. So it
continues to accumulate changes that aren't in a release while folks drive
their particular desired features back into branch-2.

On Mon, Mar 21, 2016 at 12:01 PM, Francis Liu <toffer@apache.org> wrote:

> To summarize so far it seems the concerns for backporting are:
> 1. compatibility - api, wire, rolling upgradeabability2. stability -
> destabilizing code and deploys for those that don't want the new feature
> Is there anything else?
> Elliot what happened to hadoop? Is it neither of the two?
> Francis
>
>
>
>
>     On Thursday, March 17, 2016 12:01 PM, Enis Söztutar <enis@apache.org>
> wrote:
>
>
>  As long as there is interest in doing the backport work, maintaining and
> experimenting with the feature on an actual release (which seems to be the
> case for RSGroups and Spark at least) and keeping the code base for
> branch-1 stable, there is no reason not to backport. RsGroups (and I
> believe Spark support as well) is marked experimental in release notes
> which means that there is some room for our client-visible guarantees.
>
> 2.0 has it's own timeline and feature set and will come in time. Of course
> anybody can propose to cut a release and push for getting it sooner rather
> than later. We should all help the effort, but realistically, even if after
> 2.0 is released, there will be people running 1.x for years after that.
>
> Enis
>
> On Thu, Mar 17, 2016 at 11:28 AM, Mikhail Antonov <olorinbant@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 the differentiator would be "how much does it change the codebase
> > around". If all/most of code change is the code which is new/ignored when
> > feature is turned off, and by default it's off until well-tested by
> various
> > users - then it should be fine to include. In the list above MOBs
> probably
> > don't satisfy that, Spark and RS Groups probably do.
> >
> > If we make 2.0 release with just Mobs and RS Groups, that would mean new
> AM
> > would have to be postponed to 3.0? What about procsV2? Although we would
> > want rolling upgrade to 2.0, still it's our chance to release something
> > big, invasive and new (since as was mentioned, the user expectation
> anyway
> > would be that in new major version some incompatibilities would be
> present
> > and some migration may be required)?
> >
> > -Mikhail
> >
> > On Thu, 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.
> > > >
> > >
> >
> >
> >
> > --
> > Thanks,
> > Michael Antonov
> >
>
>
>
>



-- 
busbey

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