On Tue, Jan 26, 2016 at 11:04 AM, Andrew Purtell <[email protected]> wrote:
> From the perspective of an operator: > > > we can't have another cluster shutdown -> upgrade -> restart? > > Rolling upgradeable, please. If it is useful to make a distinction between > regionserver and master roles, and say all of one must be upgraded before > the other, this is manageable. > Yep, my feeling is that we should make this rolling upgradable. Having coordination for master to be upgraded first then region servers is fine, but may end up to be problematic in practice. I am not sure how we can enforce this (new regionservers cannot talk to old masters for example, or cannot come up due to fs changes?). > > > if we have replication working between 1.x and 2.x > > This is required I think. Stranded users on 0.94 went so far as to hack new > replication endpoints to get it working between 0.94 and 0.96+. > +1. The RPC wire format is not changing in 2.0 is it? > > > is it acceptable to force people to move to the latest 1.x (e.g. 1.5.x)? > > If this would be the only way to upgrade without downtime, then yes, we'd > take it. > Agreed. It is acceptable to require 1.x latest. It should be a last resort though. 0.98 -> 2.0 will depend on whether latest 1.x is required or not I think. > > > On Tue, Jan 26, 2016 at 10:58 AM, Matteo Bertozzi <[email protected] > > > wrote: > > > Hey, > > > > what are your goals/hopes for the 1.x to 2.0 migration? > > > > did we decided we can't have another cluster shutdown -> upgrade -> > > restart? > > or if we have replication working between 1.x and 2.x this is a valid > > option? > > > > one of the goal of the new Assignment is to be able to handle major > > migrations by knowing the state of the cluster in terms of "which version > > is each region server running" and with the ability to schedule region > > migration for fs format changes and similar "major" changes. > > (this requires an upgrade performed, Masters first and then RSs. this is > > what I always suggested to people but I never checked if this is what we > > are suggesting) > > > > also, the above may require (still looking into it) some new calls added > to > > the 1.x line. > > is it acceptable to force people to move to the latest 1.x (e.g. 1.5.x)? > > or at least is it acceptable to force people to move to the latest 1.x.y > > (e.g. 1.1.232)? > > > > did we decided that before going to 2.0 you have to be on a 1.x? meaning > no > > direct upgrade from 0.98 to 2.0? > > > > and for how long should we keep upgrade/compatibility code in 2.x? > > can we force people to upgrade to 2.0 and then to the next 2.x? > > > > thoughts? > > > > > > -- > Best regards, > > - Andy > > Problems worthy of attack prove their worth by hitting back. - Piet Hein > (via Tom White) >
