Gluster users - Oct 2015 - Gluster 4.0 - upgrades & backward compatibility strategy

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

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 :)

2015-10-07 8:32 GMT+03:00 Atin Mukherjee <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
> http://www.gluster.org/mailman/listinfo/gluster-users
>


-- 
Best regards,
Roman.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.gluster.org/pipermail/gluster-users/attachments/20151014/8b7c8b0f/attachment.html>

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