hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: Current status of 1.2.0RC0
Date Thu, 09 Jul 2015 18:57:48 GMT
Just to be clear, of course this doesn't work if pv2 isn't opt out, so
that's the question I'm really asking - should we / can we do that?

On Thu, Jul 9, 2015 at 11:55 AM, Andrew Purtell <apurtell@apache.org> wrote:

> > I'm concerned about a sever side hbase rolling upgrade where masters and
> > rs's are different versions / settings.  E.g. Does a pv2 only master
> > failover properly with a nonpv2 master in the presence of mixed version
> > rs's.  Does the master failover test cover this situation?
>
> This is a valid concern certainly. How we handled this in the 0.98 era,
> which admittedly is looser by intent, is say that rolling upgrade are
> supported IF the server fleet does not toggle on any new feature until all
> server instances have been upgraded. Would that work here? I think it's a
> reasonable story.
>
>
> On Thu, Jul 9, 2015 at 6:47 AM, Jonathan Hsieh <jon@cloudera.com> wrote:
>
>> Let's have some testing of this before we commit to this decision. I'd
>> hate
>> for us to be in a situation where reality doesn't jive with theory due to
>> something self inflicted.  I also feel that removing well exercised code
>> paths in minor versions seems risky. (No qualms for removing in major
>> version)
>>
>> My main concern isn't hbase client to hbase server. I buy that.
>>
>> I'm concerned about a sever side hbase rolling upgrade where masters and
>> rs's are different versions / settings.  E.g. Does a pv2 only master
>> failover properly with a nonpv2 master in the presence of mixed version
>> rs's.  Does the master failover test cover this situation?
>>
>> Jon
>>
>> On Monday, July 6, 2015, Enis Söztutar <enis@apache.org
>> <javascript:_e(%7B%7D,'cvml','enis@apache.org');>> wrote:
>>
>> > >
>> > >
>> > > > Would not being able to opt out of this break rolling upgrade from
>> 1.0
>> > or
>> > > 1.1?
>> > >
>> >
>> > It should not (in theory). The client side does not need to know that
>> the
>> > operation is executed via proc v2. The HBaseAdmin class has the
>> > compatibility layer to work with masters which know about proc v2 or
>> not.
>> > And if the client does not know about proc v2, it will still observe the
>> > side affects (whether the tables regions are created in meta, etc) and
>> work
>> > as expected.
>> >
>> >
>> > >
>> > >
>> > > > Enis
>> > > >
>> > > > On Sun, Jul 5, 2015 at 2:01 PM, Sean Busbey <busbey@cloudera.com>
>> > wrote:
>> > > >
>> > > > > On Jul 5, 2015 1:36 PM, "Stack" <stack@duboce.net> wrote:
>> > > > > >
>> > > > > > On Sat, Jul 4, 2015 at 4:01 PM, Sean Busbey <
>> busbey@cloudera.com>
>> > > > wrote:
>> > > > > >
>> > > > > > > Hi Folks!
>> > > > > > >
>> > > > > > > I believe I've now worked through the logistics to
put up the
>> > first
>> > > > RC
>> > > > > for
>> > > > > > > 1.2.0. At the moment I'm waiting on a Procedure V2
blocker[1],
>> > > which
>> > > > I
>> > > > > hope
>> > > > > >
>> > > > > >
>> > > > > > May I add HBASE-14012 to the above list Sean? (Almost done)
>> > > > > >
>> > > > >
>> > > > > Fine by me. Please make sure it is blocker priority with a fix
>> > version
>> > > of
>> > > > > 1.2.0.
>> > > > >
>> > > > > > 1.2.0 has Distributed Log Replay enabled by default. We
good
>> with
>> > > this?
>> > > > > > I've not done much testing with it enabled. Have others?
>> > > > > >
>> > > > >
>> > > > > I haven't yet. I figured during RC0 I'd try to hit it hard and
>> then
>> > > file
>> > > > > tickets as needed.
>> > > > >
>> > > > > If we leave it on we'll need docs for how to do a rolling upgrade.
>> > > > >
>> > > > > > 1.2.0 also has flush-by-store enabled by default. This has
been
>> > > tested
>> > > > a
>> > > > > > bunch and looks pretty good to me.
>> > > > > >
>> > > > >
>> > > > > Good to hear, this and can't-opt-out-procv2 are my other big
>> > unknowns.
>> > > > >
>> > > >
>> > >
>> > >
>> > >
>> > > --
>> > > // Jonathan Hsieh (shay)
>> > > // HBase Tech Lead, Software Engineer, Cloudera
>> > > // jon@cloudera.com // @jmhsieh
>> > >
>> >
>>
>>
>> --
>> // Jonathan Hsieh (shay)
>> // HBase Tech Lead, Software Engineer, Cloudera
>> // jon@cloudera.com // @jmhsieh
>>
>
>
>
> --
> 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