hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matteo Bertozzi <theo.berto...@gmail.com>
Subject Re: [DISCUSS] HBase-2.0 SHOULD be rolling upgradable and wire-compatible with 1.x
Date Tue, 21 Jun 2016 06:30:42 GMT
I think everyone wants rolling upgrade. the discussion should probably be
around how much compatibility code do we want to keep around.

using as example HBASE-16060, we need to decide how much are we rolling
upgradable and from where.
I'm not too convinced that we should have extra code in master to "simulate
the old states",
I'll rather have cleaner code in 2.0 and force the users to move to one of
the latest 1.x.y
there are not many changes in the 1.x releases, so we should be able to say:
if you are on 1.1 move to the latest 1.1.x, if you are on 1.2 move to the
latest 1.2.x and so on.

also there are some operations that may not be needed during rolling
and we can cut on compatibility to have some code removed.
an example here is HBASE-15521 where we are no longer able to clone/restore
snapshot during 1.x -> 2.x rolling upgrade, until the two master are on
2.x. but this may be extended to you can't perform some operation until all
the machines are on 2.x for some future change.

I think we should aim for something like:
 - data path: HTable put/get/scan/... must work during a rolling upgrade
 - replication: must? work during rolling upgrade
 - admin: some operation may not be working during rolling upgrade
 - upgrade to the latest 1.x.y before the 2.x upgrade (we can add in 2.x
master and rs the ability to check the client version)


On Tue, Jun 21, 2016 at 12:05 AM, Dima Spivak <dspivak@cloudera.com> wrote:

> If there’s no technical limitation, we should definitely do it. As you
> note, customers running in production hate when they have to shut down
> clusters and with some of the testing infrastructure being rolled out, this
> is definitely something we can set up automated testing for. +1
> -Dima
> On Mon, Jun 20, 2016 at 2:58 PM, Enis Söztutar <enis@apache.org> wrote:
> > Time to formalize 2.0 rolling upgrade scenario?
> >
> > 0.94 -> 0.96 singularity was a real pain for operators and for our users.
> > If possible we should not have the users suffer through the same thing
> > unless there is a very compelling reason. For the current stuff in
> master,
> > there is nothing that will prevent us to not have rolling upgrade support
> > for 2.0. So I say, we should decide on the rolling upgrade requirement
> now,
> > and start to evaluate incoming patches accordingly. Otherwise, we risk
> the
> > option to go deeper down the hole.
> >
> > What do you guys think. Previous threads [1] and [2] seems to be in
> favor.
> > Should we vote?
> >
> > Ref:
> > [1]
> >
> >
> http://search-hadoop.com/m/YGbbsd4An1aso5E1&subj=HBase+1+x+to+2+0+upgrade+goals+
> >
> > [2]
> >
> >
> http://search-hadoop.com/m/YGbb1CBXTL8BTI&subj=thinking+about+supporting+upgrades+to+HBase+1+x+and+2+x
> >

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