> > >> 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) >
That is why I suggested that we keep the handlers in branch-1.1 so that in case something serious comes up (especially related to customer support environments) that at least we can go back to previous handler logic and sideline the issues. We do not need to (and should not) keep handlers around in branch-1 from a compatibility point of view. Whether to keep it as a backup option to be able to sleep better at night is debatable. Maintaining handlers in the code base is not difficult, but we need to re-add them back since in branch-1 they are already removed (see release notes for https://issues.apache.org/jira/browse/HBASE-13469). I think we should never give the option of using handlers, only except for guarding against problems in procv2 without any workaround. We have been running all sorts of IT tests including IntegrationTestDDLMasterFailover, and some other master failover tests as well as rolling upgrade from 0.98.4 (HDP-2.2) versions, and all of the discovered issues have been fixed (see subtasks of HBASE-12439). We consider proc v2 to be pretty stable thanks to Matteo and Stephen's work. For rolling upgrades between procv2 masters and non-procv2 masters, RU should work. These are independent of each other with minimal shared state (except for actual hdfs and zk data structures). If you have a master failure during create table for example, the outcome was not defined. In that sense it does not change the semantics. Enis > >> > >> 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) >
