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 <theo.berto...@gmail.com> wrote: > > 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. >>
