hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: [DISCUSS] EOL 1.1 Release Branch
Date Fri, 04 Nov 2016 21:59:39 GMT
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 <olorinbant@gmail.com>
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 <apurtell@apache.org>
> 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 <apurtell@apache.org>
> > 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 <ndimiduk@apache.org>
> > 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)

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message