+1 on both rolling upgradable and wire-compatible with 1.x. Requiring end users to upgrade hbase client means they have to restart their application, which is really miserable, not mentioning the coordination work required with different users...
Best Regards, Yu On 22 June 2016 at 10:29, Heng Chen <[email protected]> wrote: > bq. We should keep main data paths working between 1.x client and 2.0 > cluster. It is fine if some admin operation does not work with older > client. > +1 > > > > 2016-06-22 2:13 GMT+08:00 Enis Söztutar <[email protected]>: > > > Agreed with above. We should keep main data paths working between 1.x > > client and 2.0 cluster. It is fine if some admin operation does not work > > with older client. Agreed on replication as well, it must work or we > should > > have a dedicated replicator implementation. > > > > HBASE-16060 would have been fine to leave unresolved according to above, > > however, accessing the table state is needed from the main data path in > > retry logic. Whenever we cannot find a region between retries, we check > > whether the table is disabled or not (because from region assignment > > perspective, there is no distinction between a region not assigned yet, > or > > a disabled table. So, I think HBASE-16060 is a blocker for 2.0 > > unfortunately. > > > > Enis > > > > On Tue, Jun 21, 2016 at 10:51 AM, Andrew Purtell < > [email protected] > > > > > wrote: > > > > > Inline > > > > > > > On Jun 20, 2016, at 11:30 PM, Matteo Bertozzi < > [email protected] > > > > > > wrote: > > > > > > > > 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 > > > > > > Yes. > > > > > > > - replication: must? work during rolling upgrade > > > > > > This is a must. If anything this is what gave users the most pain at > the > > > "singularity" - so much so that at least one built custom cross version > > > replication endpoints. That should have been on us to provide. > > > > > > > - admin: some operation may not be working during rolling upgrade > > > > > > This would depend on what won't work. > > > > > > I think it would be great if you could start a rolling upgrade, stop at > > > like 10% or 20% of the fleet, see how it goes for a while, and then > > either > > > commit or roll back. How comfortable that mixed version state is will > > > depend on what won't work. I submit this for consideration as a stretch > > > goal. > > > > > > > - 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) > > > > > > This would be fine, I think. > > > > > > > > > > > > > > > Matteo > > > > > > > > > > > >> On Tue, Jun 21, 2016 at 12:05 AM, Dima Spivak <[email protected] > > > > > 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 <[email protected]> > > > 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 > > > >> > > > > > >
