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-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
