Should I upgrade to Ceph Reef to Squid Orchestrator and Dashboard now?

Decide when to move a self-hosted object or block storage platform from Reef to Squid without breaking cephadm orchestration, dashboards, or client compatibility.

Upgrade cephadm-managed Reef clusters to Squid now, unless you have a specific near-term blocker that makes the cluster unsafe or key dashboard/client workflows unvalidated.

Blockers

Who this is for

Candidates

Upgrade cephadm-managed Reef clusters to Squid now

As of 2026-04-03, Reef is no longer an active release: the official Ceph releases index lists Reef 18.2.8 with estimated end of life on 2026-03-31, while Squid is active with latest 19.2.3 and estimated end of life on 2026-09-19. Ceph officially documents direct upgrading from Quincy or Reef to Squid, and for cephadm-managed clusters the upgrade is automated with `ceph orch upgrade start`. Squid also introduces the `mgmt-gateway` service as a new front end for the dashboard and monitoring stack, which can simplify HA and access management. This is the default decision unless you have a verified blocker in client behavior or management endpoint changes.

When to choose

Use this when you run cephadm already, need supported backports, and can schedule a short control-plane change window. The decisive factor is that Reef support has already ended as of 2026-04-03, so staying put is now an exception case rather than a normal steady state.

Tradeoffs

You regain a supported release and keep the upgrade path automated, but Squid's remaining support window is shorter than a fresh major release and operational teams need to validate dashboard entry points, monitoring access, and any sensitive client features before cutover.

Cautions

There is no downgrade path back to Reef after a Squid upgrade is started and then stopped. If you deploy `mgmt-gateway`, external access to monitoring services is consolidated behind a new single HTTPS endpoint and direct access to those services is removed. For large CephFS deployments, cephadm normally reduces `max_mds` to `1` during upgrade, and Squid also adds a CephFS `root_squash` compatibility check that requires clients using that feature to support the `client_mds_auth_caps` bit.

Hold on Reef only long enough to clear explicit upgrade blockers

A short hold on Reef is defensible only as a stabilization step, not a target state. As of 2026-04-03, Reef 18.2.8 has already reached its estimated end of life on 2026-03-31, so this option means accepting an unsupported release while you clear concrete blockers such as unhealthy hosts, client compatibility testing, or dashboard access changes. Ceph's upgrade guidance says cephadm pauses when a host is unavailable, and the cluster is likely to show `HEALTH_WARNING` during the upgrade. The main reason to delay is operational readiness, not release support.

When to choose

Use this only when the cluster is not currently healthy enough for an orchestrated upgrade or when a dependent dashboard, CephFS, or client workflow has not yet been validated against Squid. The decisive factor is whether your blocker is specific, time-bounded, and resolvable in the near term.

Tradeoffs

You reduce immediate change risk for a few days or weeks, but you stay on an unsupported release and extend exposure to unpatched bugs or security issues. You also compress the next decision because Squid itself has an estimated end of life in 2026.

Cautions

Treat this as a temporary exception with a dated exit plan. Disable PG autoscaling during the upgrade if recommended for your pools, and plan around CephFS upgrade behavior if you run multiple active MDS daemons. If your cluster is not cephadm-managed, Ceph's Squid notes point Quincy-or-later operators toward cephadm adoption first so that the upgrade is automated.

Facts updated: 2026-04-03
Published: 2026-04-03

Try with your AI agent

$ npm install -g pocketlantern
$ pocketlantern init
# Restart Claude Code, Cursor, or your MCP client, then ask:
# "Should I upgrade to Ceph Reef to Squid Orchestrator and Dashboard now?"
Missing something? Request coverage