Ceph release cadence and supported upgrade paths

Intermediate⏱ ~17 minceph

What you'll learn

Describe the release cadence and naming
Identify supported upgrade paths
Plan a version strategy
Recognise an unsupported path before attempting it

Prerequisites

None — start here.

Verified against Ceph Tentacle 20.2.x · Ceph Squid 19.2.x (supported previous) · cephadm matches the verified Ceph release · podman 4.x · csi-rbd and csi-cephfs current · RBD / CephFS / RGW current (matches Ceph release) · Linux kernel 5.15+ (5.10 minimum) · Ubuntu 24.04 LTS (Ceph host baseline) · Debian 12 (Bookworm) (Ceph host baseline) · Rocky Linux / RHEL / AlmaLinux 9.x (Ceph host baseline) · Proxmox VE 9.x (cross-course integration) · Kubernetes 1.31+ (cross-course integration) · 2026-08-18

Why this matters in production

An unsupported upgrade path can leave a cluster in a state with no straightforward way forward or back.

The release model

Named releases, roughly annual:
  ... Pacific, Quincy, Reef, Squid, Tentacle ...
Each has a major version number.
Point releases within a named release carry fixes.

ceph version
ceph versions

{
    "mon": { "ceph version 19.2.0 (...) squid (stable)": 3 },
    "mgr": { "ceph version 19.2.0 (...) squid (stable)": 2 },
    "osd": { "ceph version 19.2.0 (...) squid (stable)": 96 }
}

ceph versions shows the version of every daemon type, which is how a partially-upgraded cluster is identified.

Supported paths

Path	Supported
Point release within a named release	yes
One named release forward	yes
Two named releases forward	generally not; check the release notes
Backward, to any earlier version	no
Skipping a release the notes require	no

The rule that holds: upgrade one named release at a time, reading
the release notes for each.

# what is currently running
ceph versions | python3 -c '
import sys,json
d = json.load(sys.stdin)
for k, v in d.items():
    if k == "overall": continue
    for ver, n in v.items(): print("%-6s %-60s %d" % (k, ver[:60], n))'

Planning a version strategy

Strategy	Suits
Track the latest named release	teams with test capacity and appetite
Stay one named release behind	most production deployments
Track a distribution’s packaged version	where the distribution provides support
Upgrade only for security fixes	conservative; accumulates a large gap

The last accumulates risk: a cluster several named releases behind
faces a multi-step upgrade with each step needing its own window and
verification.

# how far behind is the cluster?
ceph version
# against the current release series

Recognising an unsupported path

TARGET=19.2.1
ceph orch upgrade start --ceph-version ${TARGET}
ceph orch upgrade status

# cephadm checks and refuses unsupported paths
TARGET=19.2.1
ceph orch upgrade check --ceph-version ${TARGET}

The check subcommand validates the path without starting anything, which is the step to run before planning a window.

Signals an upgrade is unsupported:
  cephadm refuses to start it
  the release notes specify an intermediate version
  the target predates the current version
  a required feature flag is not set

Quiz

Knowledge check · 4 questions

Q1. Why does Ceph have no supported downgrade path?

Releases change on-disk formats and store schemas as daemons upgrade, and older daemons cannot read structures written by newer ones Downgrade support was deferred and is planned for a future release, so the path exists but is not yet exposed by cephadm The monitors refuse to admit a daemon whose version is below the recorded require_osd_release, which blocks the daemon rather than the data Downgrades work within a named release because point releases share a format, and are blocked only across named releases
Q2. Skipping a named release is generally supported if the target is newer.

True False
Q3. Plan an upgrade from several releases behind.

A cluster runs a named release three versions behind current. The team wants to reach the current release.
Q4. What does `ceph versions` reveal that `ceph version` does not?

Passing score: 75%. Answers are checked in this browser.

Production discipline

Run ceph orch upgrade check before planning any upgrade window — it validates the path and surfaces prerequisites without starting anything. Upgrade one named release at a time with full verification between steps; there is no downgrade, so each step’s backup is the only reverse option.

Cross-course references

Kubernetes: version skew policies bound supported upgrade paths similarly
Linux: irreversible on-disk format changes make backups the only rollback