[Gluster-devel] [Gluster-users] Gluster 4.0 - upgrades & backward compatibility strategy

[Mauro Mozzarelli]

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