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

[Bipin Kunal]

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 <joe at julianfamily.org> 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
>> Gluster-users at gluster.org
>> http://www.gluster.org/mailman/listinfo/gluster-users
>>
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-users/attachments/20151022/a4b9355f/attachment.html>