Ceph Reef to Tentacle upgrade

Why a Reef cluster should move straight to Tentacle

If your Ceph cluster runs Reef and is out of support, Tentacle is the target release, and the Tentacle notes support upgrading from Reef. You do not need to stop at Squid on the way unless your own timeline requires it. Tentacle (20.2.x) was first released on November 18, 2025, the latest point release listed is 20.2.4, and its estimated end of life is June 1, 2027. Before you schedule the change, confirm the supported source versions and the exact upgrade steps in the Ceph active releases page, because the target is only useful if the source path is documented for your current build.

Squid is an intermediate option only when it fits your timeline. Squid (19.2.x) was first released on September 26, 2024, the latest listed point release is 19.2.7, and its estimated end of life is October 31, 2026. A Reef to Squid to Tentacle path means two upgrade windows, two sets of health checks and two rounds of client compatibility review. That cost is worth paying if you cannot finish a Tentacle upgrade before Squid's end of life and need a supported release in between, or if your change process requires a specific intermediate version. If neither applies, a single hop to Tentacle keeps the work smaller and shortens the period of unplanned exposure.

Confirm the current state of every cluster before you choose a path. Run ceph versions to see which daemon types are on which release, and confirm that the cluster is managed by cephadm, because the upgrade is driven through cephadm. Clusters deployed with older tools need conversion first, which the conversion steps on this page cover. Clusters that are still on Quincy cannot go straight to Tentacle, so they follow the *Ceph Quincy to Squid upgrade* sibling page first. Clusters already on Squid should use the *Ceph Squid to Tentacle upgrade* page for the hop itself.

What changes between Reef and Tentacle, and what you must do

This table lists the changes that matter for a Reef to Tentacle move, with the impact of each and the action your team needs to take before or during the upgrade. Rows marked to confirm depend on the Tentacle release notes, so check each one against your own configuration. Read the cephadm, OSD release and client compatibility rows first, because they decide whether the upgrade can start and in what order.

Change	Impact	Action needed
Cephadm management	Cephadm was introduced in v15.2.0 and does not support older releases, so non-cephadm daemons cannot follow the cephadm upgrade path.	Confirm every daemon is cephadm-managed. Convert older clusters before starting the upgrade.
Target release	Tentacle 20.2.x was first released November 18, 2025, with an estimated end of life of June 1, 2027.	Choose the latest 20.2.x point release on the releases page and record the exact version in your change plan.
Reef support status	Reef is not listed among the actively maintained releases, so it no longer receives periodic backports or security fixes.	Treat the Reef cluster as unpatched. Schedule the move rather than waiting for a Reef fix.
OSD release requirement	The minimum OSD release setting must match the new release once all OSDs run Tentacle. Confirm the exact setting in the Tentacle release notes.	Verify all OSDs report the new release, then set the minimum OSD release. Do not set it earlier.
FileStore OSDs	FileStore OSDs cannot run on Reef or later, so a cluster still using them must convert before the release change.	Inventory OSD object stores with your admin tools. Plan conversion ahead of the upgrade. Confirm the process in the Tentacle notes.
Client compatibility	Tunable changes can cut off older kernel and librados clients. Confirm which clients and tunables apply to Tentacle.	List every client version and its access path. Plan any tunable change alongside client upgrades.
Default settings	Some default values change between releases. Overrides you set on Reef may behave differently on Tentacle. Confirm the list in the release notes.	Export your current settings with the configuration dump command. Compare each override against the Tentacle defaults.
Container image access	Cephadm pulls the new daemon image on each host. A host that cannot reach the image stalls the rolling upgrade.	Confirm every host can pull the Tentacle image, or mirror it to a local registry before starting.

What to prepare before the first daemon restarts

Most failed Ceph upgrades were decided before the first daemon restarted. These six items set a rollback point, show which clients will be affected, confirm the hardware can absorb a restart, and give you a baseline to compare against after each step.

Verified configuration and monitor backup

Export the cluster configuration, the CRUSH map, the monitor store and the cephadm service specifications before changing anything. Restore a copy into a scratch location to confirm the files are readable, not just present. Record the cluster FSID and the list of hosts running monitors so that a recovery plan has the facts it needs under pressure. Confirm who holds the copies and that they are stored outside the cluster being upgraded.

Client and librados version inventory

List every consumer of the cluster, including hypervisors using RBD, Kubernetes CSI drivers, kernel clients mounting CephFS, RGW users and custom librados applications, with the kernel or library version each one runs. Reef to Tentacle changes what older clients can talk to, so an out-of-date client found after the upgrade becomes an outage. Ask each owner to confirm the version in writing and to name a contact for the window.

Hardware checks against recommendations

Compare each OSD host against the Ceph hardware recommendations: one dedicated drive per OSD, WAL and DB on shared SSDs for HDD-backed OSDs, enterprise-class SSDs for metadata, and bonded network links spread across two switches. Upgrades add restart and recovery load, so a host that already runs close to its limits will show it first. Check memory against peak use, not average use, and note any host that falls short.

Health baseline before the change

Capture ceph status, ceph health detail, ceph versions, and ceph osd tree in a dated file before the upgrade starts. Record any warnings already present, scrub state, degraded or misplaced object counts, and the OSD down or out list. Any warning you cannot explain now will be hard to attribute later. Agree in advance which baseline changes stop the window and who makes that call.

Test cluster that mirrors production

Build or reserve a non-production cluster with the same cephadm version, OSD media types, pool layouts, CRUSH rules and a representative client mix. Run the full upgrade there first and time each stage, including the slowest daemon restarts and recovery. Use the test run to confirm the commands in your runbook, rehearse the rollback decision, and find any client that behaves differently. Note the differences you could not reproduce, because those are the risks you carry into production.

Upgrade window and decision owners

Set the maintenance window, the freeze on configuration changes and the people who can pause the upgrade. Confirm that storage, network, virtualization and application teams all know when client-facing I/O may slow and when it may stop. Write down the criteria that stop the upgrade between daemon groups, such as a monitor quorum loss or unexpected PG states. Ask your provider to show how these criteria map to the runbook steps.

Converting older non-cephadm clusters before the jump

Before planning any Reef to Tentacle sequence, confirm whether the cluster is already managed by cephadm. cephadm was introduced in v15.2.0 (Octopus) and does not support older releases, so a package-based cluster or one deployed with ceph-ansible must be adopted into cephadm first, either as a separate change before the upgrade or as a documented first phase of it. Treat adoption as its own change with its own health baseline and rollback plan, because it alters how every daemon is started, configured and restarted, and a failed adoption is easier to contain than a failed adoption combined with a release change.

The adoption decision points come from the layout you actually run. Inventory every daemon type (monitors, managers, OSDs, metadata servers, Object Gateways and any monitoring stack) on every host, and decide which hosts go first. Check that the hosts can pull the container images, that SSH access for the orchestrator is in place, and where configuration lives, since settings in ceph.conf and in the centralized configuration database behave differently once the orchestrator takes over. The set of adoptable daemons, the host prerequisites and the adoption commands change with the layout, so confirm each step against the cephadm documentation for your cluster before scheduling work.

The main risk is running two deployment methods side by side for longer than planned. Adopted daemons run as containers under cephadm, while unadopted daemons may still run under systemd units from the original packages. The orchestrator upgrades only the daemons it manages, so an unadopted daemon can be skipped, upgraded out of order or restarted by a different process than the one you expect. Keep the mixed state as short as possible, record which method owns each daemon in your change log, and confirm that ceph orch ps lists every daemon and that cluster health is clean before the Tentacle upgrade begins.

How the cephadm upgrade sequence runs, with checks and rollback points

This sequence moves a cephadm-managed Reef cluster to Tentacle one daemon group at a time, with a health check closing each group. It also marks the rollback points, including the point after which a simple downgrade is no longer available.

Confirm health and the cephadm version
Before anything restarts, the team confirms the cluster reports HEALTH_OK, or documents every warning it carries, using ceph -s and ceph health detail. Next, they check that every host and daemon is managed by cephadm with ceph orch ps, and that every daemon reports the Reef version with ceph versions. Ask your team to confirm in the Tentacle release notes that your current cephadm version supports this upgrade path. The step is done when the baseline output is saved and the change owner signs off. This is rollback point one: nothing has been restarted, so stopping here changes nothing in the cluster.
Set the target image to Tentacle
Point the orchestrator at the Tentacle container image, using the image reference listed in the Tentacle release notes and confirmed for your registry. Then start the upgrade with ceph orch upgrade start --image followed by that reference. Run ceph orch upgrade status to confirm the target is accepted and the orchestrator has begun with the managers. If your hosts cannot pull from a public registry, the image must already be mirrored locally before this step. The step is done when status shows the upgrade in progress with the Tentacle target recorded.
Upgrade managers and monitors first
cephadm upgrades the Manager daemons first, then the Monitors, restarting one at a time and waiting for quorum after each. Watch progress with ceph orch upgrade status, then confirm monitor membership and quorum with ceph mon stat and ceph quorum_status. The group is done when every Manager and Monitor reports Tentacle, all monitors are in quorum, and ceph -s passes. This is rollback point two. Once monitors run Tentacle, returning them to Reef is not a simple downgrade, so treat any later reversal as a recovery decision and confirm the procedure in the Tentacle documentation before you begin.
Upgrade OSDs in staged groups
cephadm then restarts OSDs host by host, so the cluster briefly runs mixed OSD versions. Between hosts, check ceph -s for degraded or undersized placement groups and wait for peering to finish before the next restart. Use ceph versions and ceph osd tree to track which OSDs have moved. Your team should confirm the batch size and any maintenance-window rules before the upgrade starts, since these depend on your failure domains and capacity. The group is done when every OSD reports Tentacle and placement groups return to active and clean, or any remaining state is documented and accepted.
Upgrade metadata servers, gateways and remaining daemons
Next, cephadm upgrades metadata servers, the Object Gateway (RGW) and any other services you run, such as NFS or iSCSI gateways if they are deployed. For metadata servers, confirm with ceph fs status that an active daemon exists and standbys are healthy before each restart. For RGW, run a small S3 smoke test against each endpoint after its daemons restart, using a test bucket. The group is done when ceph orch ps lists every daemon on Tentacle, ceph orch upgrade status reports the service groups complete, and client smoke tests pass.
Raise require-osd-release only after all OSDs run it
Confirm again with ceph versions that every OSD and every other daemon reports Tentacle. Only then run ceph osd require-osd-release with the Tentacle value confirmed in the release notes. This setting raises the minimum OSD release for the cluster and blocks older daemons from joining, so do not run it while any OSD still reports Reef. This is rollback point three. After the flag is raised, you cannot return OSDs or monitors to Reef by a simple downgrade. The step is done when ceph osd dump shows the new required release and ceph -s reports no new warnings.
Run post-upgrade checks and close the window
Confirm ceph orch upgrade status shows no upgrade in progress and that ceph versions lists Tentacle for every daemon. Review the health output for new warnings, including any CRUSH tunables warning, which needs its own planned change because it can move data and affect older clients. Check the Dashboard, metrics collection and alerting, and rerun the client and application tests you used before the upgrade. Record the final state as the new baseline. The sequence is complete when health matches or improves on the saved baseline and the owners accept the result.

Which checks confirm the cluster is healthy on Tentacle

Start with the cluster itself. A cluster that reports healthy after the last daemon restarts can still hide placement groups that have not returned to active and clean, or OSDs that rejoined with unexpected state. Confirm the cluster reports a clean health state, that every monitor is in quorum, that all managers and OSDs are up and in, and that placement groups have finished peering and recovery. Compare the result with the baseline you captured before the upgrade, not with an abstract ideal.

Overall health status: Record the health output and any warnings that remain. Warnings introduced by the upgrade need an owner and a decision before the change is closed.
Monitor quorum: Confirm the expected monitors are in quorum and that the quorum membership matches the pre-upgrade record.
Daemon versions: Check that every daemon reports the Tentacle version and that no mixed-version daemons remain once the orchestrator finishes.
Placement groups: Confirm placement groups are active and clean, and that no inactive, degraded or unfound groups remain. Note any that were already degraded before the change.
OSD state: Verify every OSD is up and in, and that utilization has not shifted unexpectedly after restarts.

Record each value next to its pre-upgrade baseline so the change record shows what changed and why.

What makes a Reef to Tentacle upgrade take longer

This table lists the factors that most often extend a Reef to Tentacle upgrade and the steps that keep each one contained. Read it before you estimate the window, because several drivers, such as non-cephadm clusters and data movement, can dominate the schedule regardless of how clean the upgrade procedure is. Confirm each row against your own inventory before you agree a timeline.

Driver	Why it adds effort	How to reduce it
Non-cephadm clusters	Clusters deployed with older tooling must be converted to cephadm management before the Tentacle upgrade can be orchestrated, and that conversion is a separate piece of work with its own checks.	Inventory every daemon and host now, convert in a non-production copy first, and confirm the conversion path against the cephadm documentation for your starting version.
Number of OSDs and hosts	Each host and OSD adds staged restarts, image pulls and health checks, so the upgrade window grows with cluster size and the number of failure domains you upgrade one at a time.	Upgrade by host or failure domain in a planned order, and script the health checks so each stage runs the same way.
Data movement and recovery time	Restarting OSDs and rebalancing data can trigger backfill and recovery traffic that runs for much longer than the software steps and competes with client I/O.	Set recovery limits before the upgrade, measure how much data is degraded at each stage, and ask your partner to model recovery time from your real capacity and utilization.
Client fleet diversity	Older kernel RBD clients and librados clients may stop working after changes to CRUSH tunables, and each client version needs to be identified and tested before the cutover.	Build a client inventory with kernel and library versions, test each client class in staging, and plan client upgrades before changing tunables.
RGW configuration	Object gateway settings, realms, zones, load balancers and authentication integrations each need validation after the upgrade, and multisite setups need sequencing across sites.	Document RGW configuration and multisite topology, run S3 and Swift test suites against the upgraded gateways, and upgrade secondary zones in a planned order.
Dashboard and SSO configuration	Dashboard settings, certificates and any SAML 2.0 or OAuth2 integration through the Management Gateway may need reconfiguration and retesting after daemons change.	Export current dashboard and SSO settings, check certificate expiry, and test login for each identity path before and after the upgrade.
Custom monitoring and scripts	Alert rules, exporters, backup jobs and automation that call Ceph commands or depend on older output formats can break silently after the upgrade.	Inventory all scripts and monitoring integrations, run them against a staging cluster, and update any parsing that relies on changed command output.
Air-gapped image mirroring	In an air-gapped network, the Tentacle container images and any monitoring images must be mirrored into a local registry and pulled by every host before the upgrade starts.	Mirror and verify images well ahead of the window, confirm every host can pull them, and keep a record of image digests for the change.

Questions teams ask before upgrading Reef to Tentacle

Can a Reef cluster upgrade straight to Tentacle?

Confirm the direct path in the Tentacle release notes before you plan, because a jump is only valid from the source releases those notes list. Ceph's releases page lists Tentacle (20.2.x) as actively maintained, first released November 18, 2025, with 20.2.4 as the latest release at the time of writing. Reef is not on that active list, so the question is the upgrade path, not the target's support status. Check three things: every daemon runs the same Reef point release, the cluster is managed by cephadm or has a conversion plan, and no FileStore OSDs remain, because FileStore OSDs cannot run on Reef or later. If the notes do not list Reef as a valid source, the work goes through an intermediate release with health checks between hops. Start with the Ceph active releases page.

What does a Reef to Tentacle upgrade cost?

DeployOpen does not publish prices, and a quote follows from a written scope. Ceph is licensed under LGPL-2.1 or LGPL-3, and the project offers no paid edition, so the cost is labor, test infrastructure and any support retainer, not software licenses. The main components are the pre-upgrade health assessment, conversion of any non-cephadm clusters, a rehearsal in a staging environment, the production upgrade window, post-upgrade verification and handover documentation. Costs rise with the number of hosts and OSDs, the media mix, the need for conversion, air-gapped image mirroring, monitoring and client integrations, and the number of change windows. The upgrade itself is one-time, while ongoing support or upgrades are separate retainers. When you request a quote, ask for an itemized scope, assumptions, exclusions, who performs each step and what the rollback plan covers.

How long does the upgrade take, and what sets the timeline?

No duration is fixed in advance, because the timeline depends on the cluster you run. The largest drivers are data volume and OSD count, since recovery and rebalancing after each daemon restart can take far longer than the restart itself. Host count matters because daemons are upgraded in staggered groups, and each group waits for cluster health before the next one starts. Other drivers include the health of the cluster when work begins, the effort to convert older non-cephadm clusters, how many staging rehearsals you run, the number of approved maintenance windows and, for air-gapped sites, how quickly every host can pull the new images. Measure timing in a staging cluster that matches production as closely as possible, then ask the vendor to base the schedule on those measurements and the written scope.

What must our team provide before the upgrade starts?

Your team provides the access, data and approvals that the upgrade cannot proceed without. Typical inputs include:

Administrative access to the cephadm orchestrator host and SSH access to every cluster node, with the change owner named.
Current cluster output, such as ceph status, ceph health detail, ceph versions and the pool and CRUSH configuration.
An inventory of clients, including kernel and librados versions, because client compatibility affects what can change safely.
Verified backups of cluster configuration and monitor data, plus the network and host diagram.
Approved maintenance windows, escalation contacts, monitoring access and, for air-gapped networks, a local container registry that holds the target images.

Also confirm who owns business sign-off on downtime tolerance and who can approve a stop if health checks fail mid-upgrade.

Can our own team run the Reef to Tentacle upgrade?

Yes, an experienced in-house Ceph team can run the upgrade if it has operated Ceph in production, has a staging cluster and follows the official upgrade documentation closely. The hard parts are not the commands but the sequencing, the health gates between daemon groups, the conversion of older clusters and the decision to stop when something looks wrong. Ask your team whether it has performed a cephadm upgrade and a conversion before, whether it can rehearse the full sequence in staging and who will be on call during the window. If those answers are uncertain, the three common options are to run the work in-house, to buy a fixed-scope engagement with a written plan and rehearsal, or to buy a retainer for ongoing upgrades and support. The choice depends on skills, risk tolerance and how often you expect to upgrade.

What does rollback mean on a Ceph upgrade?

Rollback on Ceph is not a single command that reverts a cluster to Reef. Once daemons run the new release and the cluster has changed its on-disk formats or release flags, the usual recovery options are a restore from backup or a forward fix on Tentacle. Confirm in the release notes which downgrade steps, if any, are supported for your source release. Plan around that reality: take verified backups of configuration and monitor data before starting, rehearse the full sequence in staging, define stop points between daemon groups and agree the decision criteria in advance. Set release-level flags, such as require-osd-release, only after the whole cluster runs the new release and checks have passed, and confirm their exact effect in the notes before you run them.

Which health checks should run before and after the upgrade?

Run the same checks before and after, and do not start the upgrade until the baseline is clean. Before the start, confirm that ceph health detail shows no unexplained warnings, that monitors form quorum, that no placement groups are degraded or backfilling, and that ceph versions shows one consistent Reef release across daemons. During the upgrade, track progress with ceph orch upgrade status and watch recovery and client latency at each group boundary. After it finishes, confirm every daemon reports the target version, check ceph health detail again, verify scrubs are running, test client mounts and block or object access, review dashboard and monitoring alerts, and record the results. Compare the numbers with the baseline and keep the record, since it becomes the evidence for the next change.

Why rollback on Ceph is a planning decision, not a button

Rolling back a Ceph upgrade is not a single action you can take at any point. A cephadm-managed daemon can sometimes be returned to its previous container image before the cluster commits to new data formats, but once you run steps such as raising require-osd-release to the Tentacle level, the cluster stops accepting older daemons and the reversal path closes. Treat each step in the Reef to Tentacle sequence as either reversible or not, and decide before the change window which steps you will allow yourself to take without a verified way back. Confirm the exact rollback behavior for your starting point in the Tentacle release notes, since the notes are the authority on which steps are safe to reverse and at which release they apply.

Plan the test environment around that boundary. Build a lab cluster that matches your production daemon mix, OSD backend, network layout and any RGW, RBD or CephFS clients, then run the full sequence there, including the point where you intend to stop reversing. Record which cephadm commands and config changes you made at each stage, so the rollback decision for production is based on evidence rather than memory. Ask whether the lab can be started from a copy of production metadata or only from a fresh build, because a fresh build will not reproduce the state of an upgraded cluster that has been running for years. Backup strategy follows the same boundary. A snapshot of the monitor store and configuration is useful only if you know which restore procedure matches the stage you are in, so document that mapping before you start. Keep client-facing data protection separate from upgrade protection: confirm that RBD, CephFS and RGW data have a recovery path that does not depend on the cluster being on the old release. Agree in writing, with your operations and application owners, which point marks the go or no-go decision and who is authorized to invoke a restore.

How DeployOpen scopes and delivers a Ceph upgrade

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Reef to Tentacle upgrade, we start from a written scope that names your cluster, its deployment method and the checks that must pass before each step.

How we scope

We confirm whether each cluster is already cephadm-managed or needs conversion before any upgrade step is planned.
We inventory OSD store types, host operating systems, client versions and network layout to find blockers early.
Engagements are fixed-scope, so the written scope lists the clusters, hosts, deliverables and acceptance checks covered.

How we build

We stage the upgrade in a non-production copy first, recording health output and daemon versions at each stage.
We sequence daemon upgrades on monitors, managers, OSDs, metadata servers and gateways, with a check between each group.
We set release-level options such as require-osd-release only after confirming every daemon is on Tentacle, and document each change.

How we hand over

You receive a runbook with pre-checks, the executed upgrade order, rollback limits and the post-upgrade verification results.
We document new defaults and any tunable or client-compatibility changes that your application owners must review.
Knowledge transfer covers how to read cephadm upgrade status and health warnings so your team can run future point releases.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
A retainer can cover the next Tentacle point releases, including reviewing release notes and planning each rollout.
Ask any provider to confirm in writing which Ceph versions, hosts and client types their support covers before signing.