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 22:00:15 GMT
Eh, instead of split/compaction, meant split/merge


On Fri, Nov 4, 2016 at 2:59 PM, Andrew Purtell <apurtell@apache.org> 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 <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)
>



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