[swift] Rolling upgrade, any version relationships?

SeongSoo Cho ppiyakk2 at printf.kr
Wed Mar 18 05:14:07 UTC 2020


Hi

In my case, I upgraded my cluster from ocata to train directly, and It was very successful.

- Is it ok for the upgrade to take extended time (e.g weeks) and therefore be running with some new and some old storage nodes for that time?
-> I think.. It's ok but It is better to take a short period.

Regards
Seongsoo

> On Mar 18, 2020, at 1:22 PM, Mark Kirkwood <mark.kirkwood at catalyst.net.nz> wrote:
> 
> Ping! This question seems to have slipped in the global bitstream unnoticed :-)
> 
> On 11/03/20 3:27 pm, Mark Kirkwood wrote:
>> Hi, we are looking at upgrading our 2.7.0 Swift cluster. In the past I've modeled this on a dev system by upgrading storage nodes one by one (using 2.17 as the target version). This seemed to work well - I deliberately left the cluster half upgraded for an extended period to test for any cross version weirdness (didn't see any). However I'm wanting to check that I have not missed something important. So my questions are:
>> 
>> - If upgrading from 2.7.0 is it safe to just grab the latest version (e.g 2.23)?
>> 
>> - If not is there a preferred version to jump to first?
>> 
>> - Is it ok for the upgrade to take extended time (e.g weeks) and therefore be running with some new and some old storage nodes for that time?
>> 
>> regards
>> 
>> Mark
>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200318/65247f7b/attachment.html>


More information about the openstack-discuss mailing list