Re: Gluster 4.0 - upgrades & backward compatibility strategy

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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



[Index of Archives]     [Gluster Development]     [Linux Filesytems Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux