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

[Atin Mukherjee]

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