[swift] Rolling upgrade, any version relationships?
Tim Burke
tburke at nvidia.com
Fri May 22 17:29:37 UTC 2020
On 4/14/20 6:00 PM, Mark Kirkwood wrote:
> Hi all, flagging this again as it would be great to have a definite
> answer to these questions! Thanks!
>
> 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
>>
>>
>
Hi Mark,
It should be perfectly fine upgrading from 2.7.0 to latest. If possible,
you'll want to upgrade backend servers (object, container, account)
before proxies, though I've done many upgrades where that wasn't
possible (because all nodes were running all services). We've never (to
my knowledge, anyway) had anything like a checkpoint release.
Having a long in-progress window for the upgrade increases the
likelihood that you'll uncover some heretofore unknown upgrade bug, but
it should be mostly OK. There may be some noisy logging, due to changes
in the replication protocol for example, but as long as the cluster was
healthy going into the upgrade, I wouldn't worry too much. Shorter is
generally better, though, especially if your cluster topology requires
that some proxies get upgraded before all the backend servers are upgraded.
Tim
More information about the openstack-discuss
mailing list