Just to be clear, of course this doesn't work if pv2 isn't opt out, so that's the question I'm really asking - should we / can we do that?
On Thu, Jul 9, 2015 at 11:55 AM, Andrew Purtell <[email protected]> wrote: > > I'm concerned about a sever side hbase rolling upgrade where masters and > > rs's are different versions / settings. E.g. Does a pv2 only master > > failover properly with a nonpv2 master in the presence of mixed version > > rs's. Does the master failover test cover this situation? > > This is a valid concern certainly. How we handled this in the 0.98 era, > which admittedly is looser by intent, is say that rolling upgrade are > supported IF the server fleet does not toggle on any new feature until all > server instances have been upgraded. Would that work here? I think it's a > reasonable story. > > > On Thu, Jul 9, 2015 at 6:47 AM, Jonathan Hsieh <[email protected]> wrote: > >> Let's have some testing of this before we commit to this decision. I'd >> hate >> for us to be in a situation where reality doesn't jive with theory due to >> something self inflicted. I also feel that removing well exercised code >> paths in minor versions seems risky. (No qualms for removing in major >> version) >> >> My main concern isn't hbase client to hbase server. I buy that. >> >> I'm concerned about a sever side hbase rolling upgrade where masters and >> rs's are different versions / settings. E.g. Does a pv2 only master >> failover properly with a nonpv2 master in the presence of mixed version >> rs's. Does the master failover test cover this situation? >> >> Jon >> >> On Monday, July 6, 2015, Enis Söztutar <[email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: >> >> > > >> > > >> > > > Would not being able to opt out of this break rolling upgrade from >> 1.0 >> > or >> > > 1.1? >> > > >> > >> > It should not (in theory). The client side does not need to know that >> the >> > operation is executed via proc v2. The HBaseAdmin class has the >> > compatibility layer to work with masters which know about proc v2 or >> not. >> > And if the client does not know about proc v2, it will still observe the >> > side affects (whether the tables regions are created in meta, etc) and >> work >> > as expected. >> > >> > >> > > >> > > >> > > > Enis >> > > > >> > > > On Sun, Jul 5, 2015 at 2:01 PM, Sean Busbey <[email protected]> >> > wrote: >> > > > >> > > > > On Jul 5, 2015 1:36 PM, "Stack" <[email protected]> wrote: >> > > > > > >> > > > > > On Sat, Jul 4, 2015 at 4:01 PM, Sean Busbey < >> [email protected]> >> > > > wrote: >> > > > > > >> > > > > > > Hi Folks! >> > > > > > > >> > > > > > > I believe I've now worked through the logistics to put up the >> > first >> > > > RC >> > > > > for >> > > > > > > 1.2.0. At the moment I'm waiting on a Procedure V2 blocker[1], >> > > which >> > > > I >> > > > > hope >> > > > > > >> > > > > > >> > > > > > May I add HBASE-14012 to the above list Sean? (Almost done) >> > > > > > >> > > > > >> > > > > Fine by me. Please make sure it is blocker priority with a fix >> > version >> > > of >> > > > > 1.2.0. >> > > > > >> > > > > > 1.2.0 has Distributed Log Replay enabled by default. We good >> with >> > > this? >> > > > > > I've not done much testing with it enabled. Have others? >> > > > > > >> > > > > >> > > > > I haven't yet. I figured during RC0 I'd try to hit it hard and >> then >> > > file >> > > > > tickets as needed. >> > > > > >> > > > > If we leave it on we'll need docs for how to do a rolling upgrade. >> > > > > >> > > > > > 1.2.0 also has flush-by-store enabled by default. This has been >> > > tested >> > > > a >> > > > > > bunch and looks pretty good to me. >> > > > > > >> > > > > >> > > > > Good to hear, this and can't-opt-out-procv2 are my other big >> > unknowns. >> > > > > >> > > > >> > > >> > > >> > > >> > > -- >> > > // Jonathan Hsieh (shay) >> > > // HBase Tech Lead, Software Engineer, Cloudera >> > > // [email protected] // @jmhsieh >> > > >> > >> >> >> -- >> // Jonathan Hsieh (shay) >> // HBase Tech Lead, Software Engineer, Cloudera >> // [email protected] // @jmhsieh >> > > > > -- > Best regards, > > - Andy > > Problems worthy of attack prove their worth by hitting back. - Piet Hein > (via Tom White) > -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
