Re: [DISCUSS] Backporting Regionserver Groups (HBASE-6721) to 1.x and 0.98

bq. we instead focus on a releasable master +1 One of the hurdles to the above is that some unit tests in master are more flaky compared to their counterparts in branch-1. Smoothing out the flaky tests is non-trivial effort. On Mon, Mar 21, 2016 at 12:52 PM, Gary Helmling

Re: [DISCUSS] Backporting Regionserver Groups (HBASE-6721) to 1.x and 0.98

> > Tho based on this discussion there's a bunch of good features that users > want that won't fit the criteria for #1 and #2. So allowing a backport of > the few that can fit into the criteria shouldn't significantly affect > future release from trunk. This way we can have some progress on some >

Re: [DISCUSS] Backporting Regionserver Groups (HBASE-6721) to 1.x and 0.98

I see, that is indeed undesirable.  Tho based on this discussion there's a bunch of good features that users want that won't fit the criteria for #1 and #2. So allowing a backport of the few that can fit into the criteria shouldn't significantly affect future release from trunk. This way we can

Re: [DISCUSS] Backporting Regionserver Groups (HBASE-6721) to 1.x and 0.98

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 wrote: > To summarize so

Re: [DISCUSS] Backporting Regionserver Groups (HBASE-6721) to 1.x and 0.98

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

Re: [DISCUSS] Backporting Regionserver Groups (HBASE-6721) to 1.x and 0.98

RS groups is also pretty non-invasive. It's a cp and the core code is in a separate module.  On Thursday, March 17, 2016 9:06 AM, Andrew Purtell wrote: I also don't see why we can't have the spark connector module in a 1.x release. I know our internal users

Re: [DISCUSS] Backporting Regionserver Groups (HBASE-6721) to 1.x and 0.98

I just don't see a why we would back port. We're going to release a 2.0 when things are ready. It will be a major feature release. Region server groups is a major feature. Backporting to branch-1 seems like an end run around what sem ver is supposed to mean (not the api guarantees, the actual

Re: [DISCUSS] Backporting Regionserver Groups (HBASE-6721) to 1.x and 0.98

I think the requirements so far are fair enough (UT, doc). Other than assignment, there is nothing in the patch that touches core code (which is by design). So the risk is pretty low. We can do the backport and have a couple of ITBLL + ITLAV runs with CM to verify the stability. Enis On Wed,

Re: [DISCUSS] Backporting Regionserver Groups (HBASE-6721) to 1.x and 0.98

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

Re: [DISCUSS] Backporting Regionserver Groups (HBASE-6721) to 1.x and 0.98

I also don't see why we can't have the spark connector module in a 1.x release. I know our internal users would be delighted to have it available. > On Mar 17, 2016, at 9:00 AM, Matteo Bertozzi wrote: > > spark is no different than RS group for this discussion. > We

Re: [DISCUSS] Backporting Regionserver Groups (HBASE-6721) to 1.x and 0.98

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

Re: [DISCUSS] Backporting Regionserver Groups (HBASE-6721) to 1.x and 0.98

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. I might go so far as to fork if we end up needing it and a backport is prevented by any intransigent community element. > On Mar 16, 2016,

Re: [DISCUSS] Backporting Regionserver Groups (HBASE-6721) to 1.x and 0.98

bq. same things I asked for MOB: Functional, stability, and performance tests focused on the impact of the feature on those who don't want it. +1 on the above. On Wed, Mar 16, 2016 at 11:14 AM, Andrew Purtell wrote: > I would like to see the same things I asked for MOB:

Re: [DISCUSS] Backporting Regionserver Groups (HBASE-6721) to 1.x and 0.98

On Wed, Mar 16, 2016 at 6:26 PM, Andrew Purtell 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

[DISCUSS] Backporting Regionserver Groups (HBASE-6721) to 1.x and 0.98

Hi, HBASE-6721 is now committed to trunk. It'd be great if it can be backported to 1.x and 0.98 so that we can use it internally as well as push up features and fixes. We have been running an internal version for around 4 years. There's seems to be interest (HW, Bloomberg, Salesforce, etc).

Re: [DISCUSS] Backporting Regionserver Groups (HBASE-6721) to 1.x and 0.98

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

Re: [DISCUSS] Backporting Regionserver Groups (HBASE-6721) to 1.x and 0.98

spark is no different than RS group for this discussion. We forced francis to move everything in a module and use coprocessors to be external as possible. so, if RS group is not going to a 1.x we should have spark not going in for the same reason. MOB is deep into HRegion and all the other stuff

Re: [DISCUSS] Backporting Regionserver Groups (HBASE-6721) to 1.x and 0.98

I'd like to see the docs issue (HBASE-14856) handled before we backport to a release line. Getting the added integration test on the nightly build would also be good. On Wed, Mar 16, 2016 at 12:15 PM, Francis Liu wrote: > Hi, > HBASE-6721 is now committed to trunk.

Re: [DISCUSS] Backporting Regionserver Groups (HBASE-6721) to 1.x and 0.98

>>>"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

Re: [DISCUSS] Backporting Regionserver Groups (HBASE-6721) to 1.x and 0.98

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

Re: [DISCUSS] Backporting Regionserver Groups (HBASE-6721) to 1.x and 0.98

I would like to see the same things I asked for MOB: Functional, stability, and performance tests focused on the impact of the feature on those who don't want it. Can use the usual suspects: PE, LTT, YCSB, our ITs. Given how 6721 has been implemented I suspect favorable results will be easy to

Re: [DISCUSS] Backporting Regionserver Groups (HBASE-6721) to 1.x and 0.98

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 wrote: > If we

Re: [DISCUSS] Backporting Regionserver Groups (HBASE-6721) to 1.x and 0.98

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