proper versions for upgrading Reef to Squid

B

bagels1b

Member
Nov 7, 2022
19
2
8
Hi,
I'm going to be upgrading my ProxMox hosts from 8.2.4 up to 8.3.1 and my Ceph from Reef 18.2.2 to Squid. I'm following the directions here (https://pve.proxmox.com/wiki/Ceph_Reef_to_Squid) for ceph and I'm wondering if I can go from Reef 18.2.2 up to Squid directory? In the Introduction section of that document it says Reef(18.2+) to Squid but then in the "Assumption" section it says 18.2.4-pve3 or higher. Can I upgrade from 18.2.2 or do I need to be at 18.2.4?

Thanks
 
Hi,

It should be possible, but it was not really tested in our QA much, so there might be lurking some odd edge case causing trouble.

That said it's good to know that 18.2.4 is the direct successor of 18.2.2, as the 18.2.3 version was skipped due to a release mishap from the ceph upstream side.
And the release notes of 18.2.4 do not mention anything specific to the upgrade process in general or for squid specially, and normally changes fixing upgrade issues are mentioned quite explicitly as they are good to know.

Again, no guarantees, but as there are no major changes in underlying storage technology and the like between Reef and Squid I'd think it's likely that you won't face problems if your cluster is fully healthy.
But again, no guarantees, if this is about a business critical cluster you might want to play it safe, which either means testing the upgrade on some test instance (even if just a virtualized PVE cluster) or upgrade to 18.2.4 first.
 
  • Like
Reactions: bagels1b
Thanks @t.lamprecht. This is a critical cluster so I'm going to go to 18.2.4 first. Is this the command to upgrade to a specific (non-latest) version of ceph? Anything else needed? My test cluster is currently at 18.2.4 and I haven't found a way to downgrade to 18.2.2 to test going 18.2.2 directly to Squid.
apt install ceph=18.2.4-1-pve3 ceph-common=18.2.4-1-pve3 ceph-mgr=18.2.4-1-pve3 ceph-mon=18.2.4-1-pve3 ceph-osd=18.2.4-1-pve3 radosgw=18.2.4-1-pve3 -y
 
Other strategy: power down all not needed VMs, backup everything, move the remaining VMs to local storages. delete ceph OSDs / Monitors etc complete, update to lastest CEPH / change reposotory etc, create a CEPH storage, and move the VMs back and restore from backup.
 
bagels1b said:
Is this the command to upgrade to a specific (non-latest) version of ceph?
Click to expand...
There's no need for a specific version command as 18.2.4 is the latest version on the ceph reef repo anyway.

So just ensure that you got a valid ceph-reef repo enabled and no other ceph specific repo and do a normal upgrade, either using the web UI (node -> Updates: Use refresh then upgrade) or the CLI using apt update and apt full-upgrade
 
t.lamprecht said:
There's no need for a specific version command as 18.2.4 is the latest version on the ceph reef repo anyway.

So just ensure that you got a valid ceph-reef repo enabled and no other ceph specific repo and do a normal upgrade, either using the web UI (node -> Updates: Use refresh then upgrade) or the CLI using apt update and apt full-upgrade
Click to expand...
Thanks @t.lamprecht. Do I need to do ceph osd set noout or set any other flags? I've seen that mentioned in a few places.
Will apt full-upgrade upgrade my pve from 8.2.4 to 8.3.1? If so, should my procedure be to do this full-upgrade (pve to 8.3.1 and ceph to 8.2.4) and then update the ceph repo to squid and do another full-upgrade to get ceph to 19.2.1?
 
bagels1b said:
Do I need to do ceph osd set noout or set any other flags?
Click to expand...
Yeah, setting noout before the upgrade and clearing that flag afterwards can help to avoid churn and extra load during an upgrade.
It's pretty much required for major ceph upgrades but not a hard requirement for minor upgrades like yours here.
bagels1b said:
Will apt full-upgrade upgrade my pve from 8.2.4 to 8.3.1? If so, should my procedure be to do this full-upgrade (pve to 8.3.1 and ceph to 8.2.4) and then update the ceph repo to squid and do another full-upgrade to get ceph to 19.2.1?
Click to expand...
You can combine the two updates in one go.

That will likely pull in a new kernel, so if your ceph cluster is fully health before that you could also safe some time by not manually restarting OSD, manager and monitor daemons but do a reboot of each node one by one, (live-)migrating any guest that should keep running to another node.

Note that I'm a bit short on time and won't get around to writing a very concise upgrade help here, but if your cluster is indeed healthy then a standard upgrade to latest PVE and latest Ceph from same major release series should have a rather tiny potential for any breakage (knocks wood).
 
You must log in or register to reply here.
Top Bottom