+1 on requiring upgrading to one of the latest 1.x.y before upgrading to 2.0.
2016-06-21 14:30 GMT+08:00 Matteo Bertozzi <theo.berto...@gmail.com>: > 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 > upgrades, > 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) > > > Matteo > > > On Tue, Jun 21, 2016 at 12:05 AM, Dima Spivak <dspi...@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 <e...@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 > > > > > >
