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

[Atin Mukherjee]

-Atin
Sent from one plus one
On Oct 22, 2015 12:45 PM, "Bipin Kunal" <bkunal at redhat.com> wrote:
>
> 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.
I do understand that having an option of non disruptive upgrade is always a
plus but we need to consider that most of the 4.0 initiatives are major
design revamps instead of add-on features. IMO in service upgrade is almost
impossible as far as GlusterD2.0 is concerned the approach at which
configuration data is going to be stored is completely different and we
need to build/migrate the old state of data into the new form(central store
based) and tampering this during the migration (which could very well be
possible in case of in service upgrade) could be fatal and may lead to a
incorrect data and correctness should always get priority, no matter what
all options we have.

HTH,
Atin
>
> 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
>
>
>
> _______________________________________________
> 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/0ae41eab/attachment.html>