Hello Atin, I think having rolling upgrade or in-service upgrade is always a plus point and sometime it is even necessity. It will be really good if we can add in-service upgrade option.
Thanks, Bipin Kunal On Wed, Oct 21, 2015 at 10:42 PM, Joe Julian <[email protected]> wrote: > A agree with all of it. It all makes perfect sense and will get us in a > better position to move forward successfully. > > As an architect, I hate things that affect my SLA, so the downtime will be > difficult and expensive. Anything that can be done to keep that downtime to > the shortest number of seconds possible would be a great place to put some > focus. > > As the guy hanging out on IRC, I have no problem telling people that > they'll need downtime for this upgrade. If you could figure out some way to > put safeguards that prevent people from breaking their production cluster > because they didn't read the release notes (happens frequently), that would > be much appreciated. > > > On 10/06/2015 10:32 PM, Atin Mukherjee wrote: > >> 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 >> [email protected] >> http://www.gluster.org/mailman/listinfo/gluster-users >> > > _______________________________________________ > Gluster-users mailing list > [email protected] > http://www.gluster.org/mailman/listinfo/gluster-users >
_______________________________________________ Gluster-users mailing list [email protected] http://www.gluster.org/mailman/listinfo/gluster-users
