I have not quite had such a bad experience with upgrades (was able to do all upgrades of the 3.5 and 3.6 series without downtime, except for the 3.6. to 3.7 upgrade where regardless of adding the rpc-allow-insecure option would not let the 3.7 node talk to the 3.6). However, had to recently downgrade from 3.7.3 to 3.6.6, and that was a complete pain because I had to manually change the op-version for all volumes and for each info file in the vols directory for each of my volumes. So whatever testing is done to go up to 4.x should take care of fixing these op-version values in the proper locations if a rollback is needed. A shout out to JoeJulian in IRC for all his valuable help in helping me figure out all the changes needed to go back down to 3.6.x In case you are wondering why I had to downgrade, then -> https://bugzilla.redhat.com/show_bug.cgi?id=1234877 which has been confirmed to still occur with 3.7.5. Diego On Thu, Oct 15, 2015 at 4:27 AM, Mauro Mozzarelli <mauro@xxxxxxxxxxxx> wrote: > One feature I would like to see in 4.0 is to be able to have a volume > started with only ONE brick up and running, at least as a configurable > option if not a default. > > This was possible in 3.5, perhaps more by mistake than design, but it > disappeared in 3.6 and it is a major issue if I want to run a second brick > as standby only. > > Right now I can do it in 3.7.4, but if I reboot the single brick I have to > stop and start again the volume before I can mount it, which is the > workaround I am using. > > Mauro > On Thu, October 15, 2015 04:14, Atin Mukherjee wrote: >> >> >> On 10/14/2015 05:50 PM, Roman wrote: >>> Hi, >>> >>> Its hard to comment plans and things like these, but I suggest everyone >>> will be happy to have a possibility to upgrade from 3 to 4 without new >>> installation, OK with offline upgrade also (shut down volumes and >>> upgrade). And I'm somehow pretty sure, that this upgrade process should >>> be pretty flawless so no one under any circumstances would need any kind >>> of rollbacks, so there should not be any IFs :) >> Just to clarify that there will be and has to be an upgrade path. That's >> what I mentioned in point 4 in my mail. The only limitation would be >> here is no rolling upgrade support. >>> >>> 2015-10-07 8:32 GMT+03:00 Atin Mukherjee <amukherj@xxxxxxxxxx >>> <mailto:amukherj@xxxxxxxxxx>>: >>> >>> Hi All, >>> >>> Over the course of the design discussion, we got a chance to discuss >>> about the upgrades and backward compatibility strategy for Gluster >>> 4.0 >>> and here is what we came up with: >>> >>> 1. 4.0 cluster would be separate from 3.x clusters. Heterogeneous >>> support won't be available. >>> >>> 2. All CLI interfaces exposed in 3.x would continue to work with >>> 4.x. >>> >>> 3. ReSTful APIs for all old & new management actions. >>> >>> 4. Upgrade path from 3.x to 4.x would be necessary. We need not >>> support >>> rolling upgrades, however all data layouts from 3.x would need to be >>> honored. Our upgrade path from 3.x to 4.x should not be cumbersome. >>> >>> >>> Initiative wise upgrades strategy details: >>> >>> GlusterD 2.0 >>> ------------ >>> >>> - No rolling upgrade, service disruption is expected >>> - Smooth upgrade from 3.x to 4.x (migration script) >>> - Rollback - If upgrade fails, revert back to 3.x, old configuration >>> data shouldn't be wiped off. >>> >>> >>> DHT 2.0 >>> ------- >>> - No in place upgrade to DHT2 >>> - Needs migration of data >>> - Backward compat, hence does not exist >>> >>> NSR >>> --- >>> - volume migration from AFR to NSR is possible with an offline >>> upgrade >>> >>> We would like to hear from the community about your opinion on this >>> strategy. >>> >>> Thanks, >>> Atin >>> _______________________________________________ >>> Gluster-users mailing list >>> Gluster-users@xxxxxxxxxxx <mailto:Gluster-users@xxxxxxxxxxx> >>> http://www.gluster.org/mailman/listinfo/gluster-users >>> >>> >>> >>> >>> -- >>> Best regards, >>> Roman. >> _______________________________________________ >> Gluster-users mailing list >> Gluster-users@xxxxxxxxxxx >> http://www.gluster.org/mailman/listinfo/gluster-users >> > > > -- > Mauro Mozzarelli > Phone: +44 7941 727378 > eMail: mauro@xxxxxxxxxxxx > > _______________________________________________ > Gluster-users mailing list > Gluster-users@xxxxxxxxxxx > http://www.gluster.org/mailman/listinfo/gluster-users _______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-users
