You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by Nick Dimiduk <nd...@apache.org> on 2015/04/28 19:16:12 UTC
[DISCUSS] Rolling Upgrade 0.98 -> 1.1
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 upgrades
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). Are
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 also
mentioned to me that he's been tracking troubles around this feature his
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=project%20%3D%20HBASE%20AND%20fixVersion%20%3D%201.1.0%20AND%20%22Hadoop%20Flags%22%20%3D%20%22Incompatible%20change%22
Re: [DISCUSS] Rolling Upgrade 0.98 -> 1.1
Posted by Nick Dimiduk <nd...@gmail.com>.
It's safe to say that all 1.x releases should be rolling upgradable from
0.98. Thanks for clarifying.
On Saturday, May 2, 2015, lars hofhansl <la...@apache.org> wrote:
> A belated and perhaps unhelpful "I agree" from me.
> Supporting rolling upgrades is in our own interest.If we want phase out
> older releases of HBase (and reduce _our_ work supporting all those
> branches) we should give our users some no-downtime, and hopefully painless
> way to upgrade.
> 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
> just worked well).I had fun doing 0.94, but I don't think we want to do
> that again. :)
>
> -- Lars
>
> From: Enis Söztutar <enis@apache.org <javascript:;>>
> To: "dev@hbase.apache.org <javascript:;>" <dev@hbase.apache.org
> <javascript:;>>
> Sent: Tuesday, April 28, 2015 7:17 PM
> Subject: Re: [DISCUSS] Rolling Upgrade 0.98 -> 1.1
>
> 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
> <javascript:;>> 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
> <javascript:;>>
> > 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
> upgrades
> > > 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).
> Are
> > > 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
> also
> > > mentioned to me that he's been tracking troubles around this feature
> his
> > > 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=project%20%3D%20HBASE%20AND%20fixVersion%20%3D%201.1.0%20AND%20%22Hadoop%20Flags%22%20%3D%20%22Incompatible%20change%22
> > >
> >
> >
> >
> > --
> > Best regards,
> >
> > - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
>
>
>
Re: [DISCUSS] Rolling Upgrade 0.98 -> 1.1
Posted by lars hofhansl <la...@apache.org>.
A belated and perhaps unhelpful "I agree" from me.
Supporting rolling upgrades is in our own interest.If we want phase out older releases of HBase (and reduce _our_ work supporting all those branches) we should give our users some no-downtime, and hopefully painless way to upgrade.
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 just worked well).I had fun doing 0.94, but I don't think we want to do that again. :)
-- Lars
From: Enis Söztutar <en...@apache.org>
To: "dev@hbase.apache.org" <de...@hbase.apache.org>
Sent: Tuesday, April 28, 2015 7:17 PM
Subject: Re: [DISCUSS] Rolling Upgrade 0.98 -> 1.1
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 <ap...@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 <nd...@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 upgrades
> > 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). Are
> > 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 also
> > mentioned to me that he's been tracking troubles around this feature his
> > 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=project%20%3D%20HBASE%20AND%20fixVersion%20%3D%201.1.0%20AND%20%22Hadoop%20Flags%22%20%3D%20%22Incompatible%20change%22
> >
>
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
Re: [DISCUSS] Rolling Upgrade 0.98 -> 1.1
Posted by Enis Söztutar <en...@apache.org>.
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 <ap...@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 <nd...@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 upgrades
> > 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). Are
> > 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 also
> > mentioned to me that he's been tracking troubles around this feature his
> > 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=project%20%3D%20HBASE%20AND%20fixVersion%20%3D%201.1.0%20AND%20%22Hadoop%20Flags%22%20%3D%20%22Incompatible%20change%22
> >
>
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
Re: [DISCUSS] Rolling Upgrade 0.98 -> 1.1
Posted by Andrew Purtell <ap...@apache.org>.
+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 <nd...@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 upgrades
> 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). Are
> 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 also
> mentioned to me that he's been tracking troubles around this feature his
> 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=project%20%3D%20HBASE%20AND%20fixVersion%20%3D%201.1.0%20AND%20%22Hadoop%20Flags%22%20%3D%20%22Incompatible%20change%22
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: [DISCUSS] Rolling Upgrade 0.98 -> 1.1
Posted by Stack <st...@duboce.net>.
On Tue, Apr 28, 2015 at 10:16 AM, Nick Dimiduk <nd...@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 upgrades
> 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). Are
> 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 also
> mentioned to me that he's been tracking troubles around this feature his
> test runs. Unless someone wants to crack this nut today or tomorrow, I
> think we should toggle it off. HBASE-13584.
>
> Let me substitute HBASE-13567 for HBASE-12743 (since resolved for
HBASE-13567). I own it. Not sure I will have a fix by tomorrow.
St.Ack
> Other items?
>
> Thanks,
> Nick
>
> [0]:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20HBASE%20AND%20fixVersion%20%3D%201.1.0%20AND%20%22Hadoop%20Flags%22%20%3D%20%22Incompatible%20change%22
>