Oh, and yes. make sure to double check the .deb packages pls :) Last time there was a bug, because of what volumes didn't start after upgrade. I know these are made by volunteers, but devs should give them appropriate signals I believe.
2015-10-15 11:29 GMT+03:00 Mauro M. <glus...@ezplanet.net>: > To date my experience with upgrades has been a disaster in that in two > cases I was unable to start my volume and eventually I had to downgrade. > > What I want to recommend is that there is an EXTENSIVE REGRESSION TEST. > The most important goal is that NOTHING that works with the previous > release should break in the new release. > > I recommend to test in particular with multi-homed bricks, it is to expect > that administrators create fast (Infiniband) LANs dedicated to gluster > with their own separate IPs and Names, physically separated from the LAN > interfaces that carry the canonical host name. > > Make sure as well that file system attributes or configuration files > aren't changed during the upgrade to a point that prevents a safe > downgrade. > > 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 <amukh...@redhat.com > >> <mailto:amukh...@redhat.com>>: > >> > >> 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-us...@gluster.org <mailto:gluster-us...@gluster.org> > >> http://www.gluster.org/mailman/listinfo/gluster-users > >> > >> > >> > >> > >> -- > >> Best regards, > >> Roman. > > _______________________________________________ > > Gluster-users mailing list > > gluster-us...@gluster.org > > http://www.gluster.org/mailman/listinfo/gluster-users > > > > > -- > Mauro Mozzarelli > Phone: +44 7941 727378 > eMail: ma...@ezplanet.net > > -- Best regards, Roman.
_______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
