hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Yu <yuzhih...@gmail.com>
Subject Re: [DISCUSS] Backporting Regionserver Groups (HBASE-6721) to 1.x and 0.98
Date Thu, 17 Mar 2016 15:53:33 GMT
For Spark, backporting to branch-1 makes sense since

it is in hbase-spark module - only adds one line to root pom.xml.
there has been frequent user query for when hbase-spark would be in an
hbase release

On Thu, Mar 17, 2016 at 8:26 AM, Matteo Bertozzi <theo.bertozzi@gmail.com>
wrote:

> 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