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 even if everything is under if isMobCF. so, I see why we may not want it just by looking at the code. API, and usefulness is another thing to consider but it doesn't look like we are discussing this in this thread. On Thu, Mar 17, 2016 at 8:53 AM, Ted Yu <yuzhih...@gmail.com> wrote: > 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.berto...@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.purt...@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.berto...@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.purt...@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 <ecl...@apache.org> > > wrote: > > > >>> > > > >>> On Wed, Mar 16, 2016 at 6:26 PM, Andrew Purtell < > > > >> andrew.purt...@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. > > > >> > > > > > >
