Atin Mukherjee
2015-Oct-15 03:14 UTC
[Gluster-users] Gluster 4.0 - upgrades & backward compatibility strategy
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 at redhat.com > <mailto:amukherj at 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-users at gluster.org <mailto:Gluster-users at gluster.org> > http://www.gluster.org/mailman/listinfo/gluster-users > > > > > -- > Best regards, > Roman.
Mauro Mozzarelli
2015-Oct-15 07:38 UTC
[Gluster-users] Gluster 4.0 - upgrades & backward compatibility strategy
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 <amukherj at redhat.com >> <mailto:amukherj at 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-users at gluster.org <mailto:Gluster-users at gluster.org> >> http://www.gluster.org/mailman/listinfo/gluster-users >> >> >> >> >> -- >> Best regards, >> Roman. > _______________________________________________ > Gluster-users mailing list > Gluster-users at gluster.org > http://www.gluster.org/mailman/listinfo/gluster-users >-- Mauro Mozzarelli Phone: +44 7941 727378 eMail: mauro at ezplanet.net
Mauro Mozzarelli
2015-Oct-15 08:27 UTC
[Gluster-users] Gluster 4.0 - upgrades & backward compatibility strategy
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 at redhat.com >> <mailto:amukherj at 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-users at gluster.org <mailto:Gluster-users at gluster.org> >> http://www.gluster.org/mailman/listinfo/gluster-users >> >> >> >> >> -- >> Best regards, >> Roman. > _______________________________________________ > Gluster-users mailing list > Gluster-users at gluster.org > http://www.gluster.org/mailman/listinfo/gluster-users >-- Mauro Mozzarelli Phone: +44 7941 727378 eMail: mauro at ezplanet.net
Mauro M.
2015-Oct-15 08:29 UTC
[Gluster-users] Gluster 4.0 - upgrades & backward compatibility strategy
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 at redhat.com >> <mailto:amukherj at 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-users at gluster.org <mailto:Gluster-users at gluster.org> >> http://www.gluster.org/mailman/listinfo/gluster-users >> >> >> >> >> -- >> Best regards, >> Roman. > _______________________________________________ > Gluster-users mailing list > Gluster-users at gluster.org > http://www.gluster.org/mailman/listinfo/gluster-users >-- Mauro Mozzarelli Phone: +44 7941 727378 eMail: mauro at ezplanet.net
Mauro M.
2015-Oct-15 08:29 UTC
[Gluster-users] Gluster 4.0 - upgrades & backward compatibility strategy
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 <amukherj at redhat.com >> <mailto:amukherj at 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-users at gluster.org <mailto:Gluster-users at gluster.org> >> http://www.gluster.org/mailman/listinfo/gluster-users >> >> >> >> >> -- >> Best regards, >> Roman. > _______________________________________________ > Gluster-users mailing list > Gluster-users at gluster.org > http://www.gluster.org/mailman/listinfo/gluster-users >-- Mauro Mozzarelli Phone: +44 7941 727378 eMail: mauro at ezplanet.net