Eh, instead of split/compaction, meant split/merge
On Fri, Nov 4, 2016 at 2:59 PM, Andrew Purtell <[email protected]> wrote: > The behavior: Looks like failed split/compaction rollback: row(s) in META > without HRegionInfo, regions deployed without valid meta entries (at > first), regions on HDFS without valid meta entries (later, after RS > carrying them are killed by chaos), holes in the region chain leading to > timeouts and job failure. > > The cause: Still looking > > You'll know you have found it when on the ITBLL console its meta scanner > starts complaining about rows in meta without serialized HRegionInfo. > > I volunteer to maintain 1.1 if nobody else wants it, and like I said I > vote -1 on EOL at this time. > > > > > On Fri, Nov 4, 2016 at 2:31 PM, Mikhail Antonov <[email protected]> > wrote: > >> On the original topic - on one hand, the fewer code lines we maintain the >> better, as less volunteering time and efforts >> are spent on that. Also does postponing of EOL-ing of older releases slow >> down adoption of newer releases? >> >> On the other hand, if we believe ITBBL is broken / unreliable for some >> release this is a bad state to be in. >> >> @Andrew - I think this is also a question of what exactly is deemed wrong >> with ITBLL. What kind of issues do you observe >> on 1.2? Do you observe data loss (unref / undef keys after Verify run), >> or >> does job fail to complete because regions in transition / offline, >> or is it something else? How reproducible is that for you? Could you share >> some more details of your experiments >> (should it be a separate thread, probably?) >> >> -Mikhail >> >> On Fri, Nov 4, 2016 at 9:57 AM, Andrew Purtell <[email protected]> >> wrote: >> >> > Let me add I'd switch my thinking to +1 for retiring 1.1 if, now that we >> > have a 1.3.0RC0 shaping up, it turns out the 1.3 code line can survive >> the >> > same 1B ITBLL testing that 1.1 does (and 1.2 does not). >> > >> > On Fri, Nov 4, 2016 at 9:52 AM, Andrew Purtell <[email protected]> >> > wrote: >> > >> > > I'm -1 on this idea, for now. >> > > >> > > We have been evaluating 1.1 and 1.2 for upgrade and whereas 1.1 will >> > > survive all testing including large scale ITBLL tests, 1.2 will not - >> no >> > > 1.2, from 1.2.0 on up. I've found one issue (fixed), and am now >> trying to >> > > nail down another. >> > > >> > > I would like to see two things: >> > > >> > > 1. Others in the community step up to evaluate the stability of 1.1.7 >> > > versus 1.2.3 (or .4) using ITBLL with at least 1B rows of data, and >> > report >> > > in. Is it just me? >> > > >> > > 2. We do not declare 1.1 EOL until 1.2 is unquestionable stable >> according >> > > to the most practical rigor we can throw at it with our tooling. >> > Especially >> > > because I still plan to resign as 0.98 RM soon, which I think will >> > trigger >> > > an EOL of that code line. >> > > >> > > I will be resigning as 0.98 RM effective January 1 2017 and at that >> time >> > > the community can discuss what to do with 0.98. From my point of view, >> > I'm >> > > done with spending time on it. Happy to take some of the time freed up >> > and >> > > use it to carry 1.1 forward if we are still making releases off this >> code >> > > line then. >> > > >> > > >> > > On Fri, Nov 4, 2016 at 9:24 AM, Nick Dimiduk <[email protected]> >> > wrote: >> > > >> > >> Hello HBase Community! >> > >> >> > >> We have a small matter to discuss. >> > >> >> > >> HBase 1.2 has been formally marked as "stable" for the last couple >> > months. >> > >> HBase 1.3.0rc0 is just around the corner. I think it's time to start >> a >> > >> conversation about retiring the 1.1 line. The volunteer bandwidth for >> > >> maintaining multiple branches is precious and as we spread ourselves >> > more >> > >> thin, odds of decay increase. >> > >> >> > >> I propose discontinuing 1.1 with a single release following 1.3.1. >> > That'll >> > >> give us one last chance to back port any bug fixes discovered in the >> > >> diligence we're putting into the new minor release. Given the current >> > pace >> > >> of 1.3, I estimate this will happen in January or February of 2017. >> It's >> > >> not a lot of time for existing deployments to get around to >> upgrading, >> > but >> > >> the upgrade path is trivial and 1.2 has been available for quite some >> > >> time. This will probably make our last release from this branch at >> > 1.1.10 >> > >> or there abouts. >> > >> >> > >> Are there any objections or concerns with the above plan? Are there >> any >> > >> downstream communities who need our help moving onto 1.2? Please let >> us >> > >> know. >> > >> >> > >> Thanks, >> > >> Nick >> > >> >> > > >> > > >> > > >> > > -- >> > > Best regards, >> > > >> > > - Andy >> > > >> > > Problems worthy of attack prove their worth by hitting back. - Piet >> Hein >> > > (via Tom White) >> > > >> > >> > >> > >> > -- >> > Best regards, >> > >> > - Andy >> > >> > Problems worthy of attack prove their worth by hitting back. - Piet Hein >> > (via Tom White) >> > >> >> >> >> -- >> Thanks, >> Michael Antonov >> > > > > -- > Best regards, > > - Andy > > Problems worthy of attack prove their worth by hitting back. - Piet Hein > (via Tom White) > -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
