Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: pass (athena.apache.org: message received from 54.191.145.13
 which is an MX secondary for dev@hbase.apache.org)
Date: Sun, 3 May 2015 01:07:10 +0000 (UTC)
From: lars hofhansl <larsh@apache.org>
Reply-To: lars hofhansl <larsh@apache.org>
To: "dev@hbase.apache.org" <dev@hbase.apache.org>
Message-ID: <1615138335.488466.1430615230744.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: 
 <CAMUu0w8rzy-N=8KQqb6aU8T=wPzA7y6R2bvFqjxS3+07wPbmrg@mail.gmail.com>
References: 
 <CAMUu0w8rzy-N=8KQqb6aU8T=wPzA7y6R2bvFqjxS3+07wPbmrg@mail.gmail.com>
Subject: Re: [DISCUSS] Rolling Upgrade 0.98 -> 1.1
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_488465_113581855.1430615230738"

------=_Part_488465_113581855.1430615230738
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

A belated and perhaps unhelpful "I agree" from me.
Supporting rolling upgrades is in our own interest.If we want phase out old=
er releases of HBase (and reduce _our_ work supporting all those branches) =
we should give our users some no-downtime, and hopefully painless way to up=
grade.
0.94 is now 3 years old, and had 28 releases. In part that's because we do =
not have a good upgrade path to later releases (and maybe also because it j=
ust worked well).I had fun doing 0.94, but I don't think we want to do that=
 again. :)

-- Lars

      From: Enis S=C3=B6ztutar <enis@apache.org>
 To: "dev@hbase.apache.org" <dev@hbase.apache.org>=20
 Sent: Tuesday, April 28, 2015 7:17 PM
 Subject: Re: [DISCUSS] Rolling Upgrade 0.98 -> 1.1
  =20
Yeah, we need rolling upgrade from 0.98 to 1.1 I think. One issue related
to DLR was that, it needs a fix HBASE-11094 which is 0.98.4+ only otherwise
it is data loss. We have turned it off in 1.0, because explaining rolling
upgrades from 0.98.4- and 0.98.4+ was hard and there is no easy way to
enforce it.

See
https://issues.apache.org/jira/browse/HBASE-12577

Enis


On Tue, Apr 28, 2015 at 4:27 PM, Andrew Purtell <apurtell@apache.org> wrote=
:

> +1 for rolling upgrade from 0.98 to any 1.x for as long as we can manage
> it. Will make life easier for adopters of the 1.x line who come in later.
>
>
>
> On Tue, Apr 28, 2015 at 10:16 AM, Nick Dimiduk <ndimiduk@apache.org>
> wrote:
>
> > We're pretty late in the game to bring this up, but I want to make sure
> > we're all on the same page. I believe we want to support rolling upgrad=
es
> > as there have been blocker tickets opened against the release to this
> > effect. The two things I'm aware of that cause problems here are table
> > state in meta (HBASE-13017) and distributed log replay (HBASE-12577). A=
re
> > there any others we should be aware of? When I search for "Hadoop Flags=
:
> > Incompatible change" [0] I do get a couple hits, but I don't think this
> > flag is well socialized.
> >
> > Given the resolution outlined for table states, I'm prone to punt this
> one
> > to 1.2.
> >
> > For DLR, we have HBASE-12743 opened without clear progress. Devaraj als=
o
> > mentioned to me that he's been tracking troubles around this feature hi=
s
> > test runs. Unless someone wants to crack this nut today or tomorrow, I
> > think we should toggle it off. HBASE-13584.
> >
> > Other items?
> >
> > Thanks,
> > Nick
> >
> > [0]:
> >
> >
> https://issues.apache.org/jira/issues/?jql=3Dproject%20%3D%20HBASE%20AND%=
20fixVersion%20%3D%201.1.0%20AND%20%22Hadoop%20Flags%22%20%3D%20%22Incompat=
ible%20change%22
> >
>
>
>
> --
> Best regards,
>
>=C2=A0 =C2=A0 - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>


------=_Part_488465_113581855.1430615230738--