Why plan the Ceph Squid to Tentacle upgrade now
If your cephadm-managed cluster runs Squid, the release line's estimated end of life is October 31, 2026, according to the Ceph releases page. Tentacle, the release line that follows it, was first published November 18, 2025, and its latest point release at the time of writing is 20.2.4, with an estimated end of life of June 1, 2027. Squid to Tentacle is the direct supported hop, so this upgrade is the route that keeps the cluster on a maintained release without an intermediate stop. Because Squid receives its final backports on a fixed horizon, the window for a calm, staged change narrows over time, and it is better to schedule the work while health checks, rollback options and maintenance windows are still easy to arrange.
Planning the move now also gives you time to answer the questions that decide how long it takes and how much risk it carries. Confirm which Squid point release each host is running, whether every daemon type is managed by cephadm, and whether any client, gateway or hypervisor depends on behavior that changes between releases. Check the release notes for Tentacle before you choose a target point release, and confirm with your own test cluster how long the monitors, managers, OSDs, metadata servers and Object Gateway daemons take to restart. These answers feed the sequence and the require-osd-release step covered later on this page.
This page sets out how to plan that work: the health checks to run before you start, the order in which daemons should move, the post-upgrade settings that need deliberate attention, and a test plan that validates the change without relying on a rollback. The aim is a dated, owned plan that your team or a partner can execute, with each step verified before the next one begins. Start the planning in your own test environment or lab, not in production, so that the findings shape the production schedule.
What changes between Squid and Tentacle
This table lists the changes that affect a cephadm-managed Squid cluster moving to Tentacle, with the impact of each and the action to take before or during the upgrade. Read it alongside the Tentacle release notes for your exact target point release, because deprecations and default changes can differ between point releases. The main takeaway is that this is a major release move, so the checks belong before the first daemon restarts.
| Change | Impact on the cluster | Action before or during the upgrade |
|---|---|---|
| Major release step from Squid 19.2.x to Tentacle 20.2.x | This is a major release move, not a point release, so the test plan and rollback assumptions must cover it. | Confirm your current Squid point release and read the Tentacle notes for the target point release. |
| Squid estimated end of life on October 31, 2026 | After this date Squid is expected to stop receiving backports and security fixes, which sets the planning deadline. | Schedule the staging run and the production window with margin before that date. |
| Tentacle point release choice (latest listed as 20.2.4) | Backports and security fixes arrive in point releases, so the target point release changes what you receive. | Choose the newest suitable point release and check its notes for upgrade caveats. |
| Deprecated options and commands | Scripts, dashboards, configuration keys and automation that depend on deprecated items may fail or warn. | Inventory configuration and automation, then confirm each deprecation in the Tentacle notes. |
| Changed default values | Settings you never set explicitly may behave differently after the upgrade without any visible change to your config. | Export current settings with ceph config dump, compare them with the defaults named in the Tentacle notes, and pin values you need. |
| Release gating with require-osd-release | Features tied to the new release stay gated until the flag is raised after all OSDs run Tentacle. | Raise the flag only after every OSD reports the new release, using the value named in the Tentacle notes, and confirm whether it can be lowered. |
| Image pull during cephadm daemon upgrades | Each host must pull the Tentacle images, so a host that cannot reach the registry stalls the upgrade mid-stream. | Confirm every host can pull the target images before starting, and check the registry path in your environment. |
| SSO and gateway authentication settings | Dashboard SSO (SAML 2.0 or OAuth2) and Object Gateway authentication settings may need review after the move. | Record current settings, then test dashboard login and S3 access on a non-production cluster before production. |
How the supported path from Squid to Tentacle works
Tentacle is the next major Ceph release after Squid, so a Squid cluster moves to Tentacle as a single major-version hop managed by cephadm. The supported path is to run cephadm's rolling upgrade across the daemons of the cluster rather than rebuilding hosts or reinstalling packages. Before planning, confirm the source and target versions against the Ceph active releases page, which lists the current Tentacle (20.2.x) and Squid (19.2.x) point releases and their estimated end of life dates. Record the exact Squid point release your cluster runs with ceph versions, because the target and any intermediate step depend on it. Ask your team to confirm whether the cluster was bootstrapped with cephadm or converted to it, since cephadm only manages clusters from Octopus (v15.2.0) onward.
Stay on the latest Squid point release before the hop. Point releases carry periodic backports and security fixes, so a cluster that is already on the newest Squid build starts the major upgrade with the most recent bug and security corrections and a smaller gap between the code it runs and the code it is moving to. Applying the latest Squid point release first also lets you observe that release in production for a period before changing the major version, which makes any regression easier to attribute. Treat the point release as its own change with its own health checks, and do not combine it with the Tentacle move in the same maintenance window.
The Ceph releases page is also the source for planning around end of life. Squid's estimated end of life date is listed there, and your upgrade window should be scheduled with enough margin before that date to absorb a failed attempt, a rescheduled window or a second pass. Check the page again when you set the window, because end of life estimates and point release numbers change over time. Your change record should name the source and target versions, the date you checked the releases page, and the owner who signed off on the path.
What to prepare before touching the cluster
The work in this section happens before any daemon restarts. Each card covers one thing to capture or verify on your cephadm Squid cluster so that a problem during the Tentacle upgrade can be traced, compared and reversed where possible. Together they define what good looks like before the first upgrade step begins.
Verified configuration and data backup
Export the cluster configuration, the cephadm service specifications, the CRUSH map and the monitor store to storage outside the cluster, then confirm the copies can be read. Identify critical pools and test a restore of a sample object or RBD image into a scratch location. Because a Squid to Tentacle path is a forward upgrade, treat the backup as protection against data loss and configuration drift rather than as a route back to Squid. Confirm with your storage team who owns restore decisions.
Inventory of Ceph clients
List every client that talks to the cluster: kernel RBD mappings, librados applications, CephFS mounts, hypervisors, and any system that uses the Ceph Object Gateway. Record client versions and kernel releases, since older clients can be affected by changes in default behavior. Assign an owner to each client so that someone can confirm it works after the upgrade. This inventory also feeds the test plan and the change window.
Custom CRUSH rules and failure domains
Export the current CRUSH map and document every custom rule, device class and failure domain that pools depend on. Confirm which pools reference which rules, and that host and rack placement still matches the physical layout. Review these rules before the upgrade so that any change in data placement is a deliberate decision rather than a surprise during recovery. Check the Squid release notes and the Tentacle notes for any changes that touch your rule types.
RGW and dashboard integrations
Record how the Ceph Object Gateway is deployed, including realm and zone configuration if multisite is used, load balancer and ingress endpoints, and authentication backends such as Keystone or LDAP. For the Ceph Dashboard, note whether single sign-on is configured through SAML 2.0 or through OAuth2 with the Management Gateway and OAuth2 Proxy services. Test each integration in staging after the upgrade, because these components often depend on configuration keys that change between releases.
Health baseline
Capture ceph health detail, ceph -s, ceph versions and ceph orch ps output before starting, and save it with a timestamp. Record OSD utilization, placement group states, any scrub or recovery activity, and the status of cephadm itself. A clean baseline lets you distinguish warnings caused by the upgrade from problems that already existed. Do not start the upgrade while the cluster is recovering unless your runbook explicitly allows it.
Staging cluster that mirrors production
Build or reserve a staging cluster with the same Squid release, cephadm version, host OS, network layout and representative client types as production. Run the full sequence there first, including the require-osd-release step and client tests. Differences in hardware, drive models or network bonding can change behavior, so document every gap that remains. Staging results are evidence for the go or no-go decision, not a guarantee for production.
Upgrade sequence with checks and rollback points
This sequence moves a cephadm-managed Squid cluster to Tentacle in stages, with a verification gate after each one. Rollback is practical until the OSDs are upgraded, and it becomes impractical once require-osd-release is set, so that command is the last cluster-wide change in the sequence.
Check cluster health and cephadm state
Run
ceph health detail,ceph orch ps,ceph versionsandceph orch upgrade checkfrom a cephadm shell on the Squid cluster. Your storage administrator resolves any HEALTH_WARN causes, degraded placement groups, down OSDs and failed or stray daemons before continuing. This step changes nothing in the cluster, so it is fully reversible. It is done when health is HEALTH_OK, or when each remaining warning is understood and accepted in writing, andceph versionsshows every daemon on Squid.Confirm hosts and Tentacle images are reachable
Confirm every host is online and reachable through cephadm with
ceph orch host ls, then check that each host can pull the Tentacle container image you plan to use. Pick the 20.2.x point release from the Ceph releases page and confirm the image tag before starting. For air-gapped sites, mirror the images into the local registry and verify the pull from every host first. This step is also reversible. It is done when every host reports online and every host has pulled the target image.Record a configuration and spec baseline
Export the current state so you can compare it after the upgrade and restore settings if needed. Save the output of
ceph config dumpand export service specifications withceph orch ls --export. Store the files outside the cluster, along with the backup and monitor-store copies that your own data protection policy requires. This step does not change the cluster. It is done when the exports are stored off-cluster and someone other than the operator has confirmed they can be read.Start the cephadm upgrade to Tentacle
Start the upgrade with
ceph orch upgrade startand the Tentacle image or version you confirmed in the earlier steps. cephadm then upgrades daemons in its own order, beginning with the monitors and managers. Watch progress withceph orch upgrade statusandceph health detail. Keep a change window open and a named operator watching the status output. This is the first step that changes running daemons. It is done when the upgrade status shows it is in progress and the first daemons report Tentacle without new errors.Verify monitors and managers before OSDs
After the monitors and managers finish, confirm that quorum is intact with
ceph quorum_statusand thatceph versionsshows every monitor and manager on Tentacle. Check that the Dashboard and any API clients respond. Do not start OSD work until this gate passes. Rollback at this point means pausing the upgrade with cephadm and investigating, not downgrading monitors, so confirm in the Tentacle release notes which downgrade paths are supported. It is done when quorum is stable and all monitors and managers report Tentacle.Upgrade OSDs and confirm placement groups recover
Let cephadm upgrade OSD hosts in sequence and watch recovery between them. After each host,
ceph -sshould show placement groups returning to active+clean before the next host restarts. Pause the upgrade if recovery stalls, if slow requests climb, or if any OSD fails to rejoin. OSD downgrades are not a routine rollback, so treat the pause as your recovery point. It is done when every OSD reports Tentacle,ceph versionsshows no mixed OSD releases, and all placement groups are active+clean.Upgrade metadata, gateways and remaining services
Allow cephadm to finish the metadata servers, the Ceph Object Gateway (RGW) and any other services in your specification, such as NFS or iSCSI gateways where deployed. Test each service after its daemons upgrade. For RGW, send S3 requests to the endpoints your applications use. For file services, mount and read from a test client. It is done when
ceph orch upgrade statusreports completion,ceph versionsshows one release across all daemon types, and each service passes its test.Set require-osd-release after all OSDs run Tentacle
Run
ceph osd require-osd-releasewith the Tentacle release name only afterceph versionsconfirms every OSD runs Tentacle. Confirm the exact release name in the Tentacle release notes before running the command. This step sets a cluster-wide minimum that stops older OSDs from rejoining, and it is the point where rollback becomes impractical. Do not run it while any OSD is still on Squid. It is done when the command returns successfully andceph osd dumpreports the new minimum release.Review new defaults and close the upgrade
Compare the
ceph config dumpoutput with the baseline saved earlier, and check each default change listed in the Tentacle release notes against your own settings. Decide which changes you keep and which you override in configuration. Re-runceph health detailand confirm no new warnings appeared, including any tunables warning that the release notes describe. Record the final versions and configuration in your change log. It is done when defaults are reviewed, your overrides are documented and health is clean.
Why require-osd-release and new defaults change the plan
The require-osd-release setting is a cluster-wide floor. Once it is raised to the new release, Ceph stops treating older OSDs as acceptable members of the cluster, so the setting must be raised only after every OSD daemon has restarted on Tentacle. Raising it early can block OSDs that have not yet been upgraded, and it is the step that turns an interrupted upgrade into a harder recovery. Plan it as the final gate of the OSD stage, not as a routine command that runs after the monitors finish. Before you run it, confirm the exact flag name, the value to set and the version gate in the Tentacle release notes, and check ceph versions to confirm that every OSD reports the Tentacle build.
Raising the floor also narrows what older daemons and clients may do. Depending on the release notes, some older OSD builds and some client libraries may be refused once the floor moves, so the client inventory you built during preparation matters as much as the OSD list. Ask each application owner which librados, RBD and CephFS client versions they run, including hypervisors and any kernel clients, and record which of them the release notes say are affected. Treat any client that cannot be upgraded before the cutover as a blocker to resolve in the plan, not as a surprise to discover in production.
New defaults and changed configuration options deserve the same discipline. Read the Tentacle release notes section by section and list every changed default, deprecated option and removed option that touches your roles, OSD memory, recovery, networking, RGW or the dashboard. For each item, record the old value, the new value, whether your cluster sets the option explicitly, and what behavior it changes. Then reproduce the relevant workload in the test environment on Tentacle, with your own settings and your own hardware, and confirm that the change is harmless or that you have set the option deliberately. Do not assume a default is safe because it is a default.
What makes this upgrade take longer
This table lists the factors that most often stretch a cephadm Squid to Tentacle upgrade and explains why each one adds work. Read each row as a question to answer about your own cluster before you agree on a schedule. The main takeaway is that host count, data volume and client mix matter more than the version step itself.
| Driver | Why it adds work | How to reduce it |
|---|---|---|
| Cluster size and host count | Each host pulls the new images and restarts its daemons in turn, so more hosts means more staggered rounds and more health checks between them. | Confirm host count and daemon placement early, and keep the upgrade order in a written runbook with a checkpoint after each group. |
| Number of OSDs and data volume | Recovery and rebalancing after OSD restarts take longer as stored data grows, and the cluster stays in a degraded state for that period. | Check recovery and backfill capacity before starting, and avoid other large data moves during the window. |
| Custom CRUSH rules and tuning | Non-default CRUSH maps, device classes and OSD tuning must be reviewed against Tentacle defaults, which adds review and testing time. | Export the current CRUSH map and configuration, diff them against new defaults, and test changes on a non-production copy. |
| RGW multisite | Zone ordering, sync health and realm configuration must be checked on each side before and after the gateway daemons move. | Confirm sync status in every zone before starting, and upgrade gateways in an order your multisite design has been tested with. |
| Dashboard SSO | SAML or OAuth2 settings, identity provider callbacks and the Management Gateway services may need reconfiguration or retesting after the Dashboard restarts. | Record current SSO settings, test login on a staging endpoint, and confirm the identity provider still trusts the Dashboard URL. |
| Client mix, including older kernel and librados clients | Clients that cannot speak the required protocol features may be cut off or need upgrades, and this is often discovered late. | Inventory every RBD, CephFS and RGW client version, including hypervisors and kernel mounts, before setting any compatibility flags. |
| Air-gapped image mirroring | The new Ceph and monitoring images must be mirrored into a local registry and pulled by every host before the upgrade can start. | Mirror and verify images on every host ahead of the window, and confirm the monitoring stack images are included too. |
| Staffing and change control | Few people who know the cluster, plus approval steps and out-of-hours windows, lengthen each step and raise the risk of rushed decisions. | Name a rollback owner and a go or no-go decision maker, and ask any partner to confirm who will be on the work and when. |
Questions teams ask before upgrading Ceph Squid to Tentacle
What drives the cost of a Ceph Squid to Tentacle upgrade?
The biggest drivers are cluster size, the number of hosts and daemon types, how much of the upgrade is cephadm-managed, and how many clients and integrations must be checked afterward. Cost also rises with the amount of pre-upgrade remediation, such as clearing health warnings, fixing unsupported configuration, and aligning client kernels and librados versions. Some work is one-time (planning, the upgrade run, the test plan), while staging environments and ongoing patching recur. Ask any quote to break out planning, pre-checks, the upgrade itself, post-upgrade validation, and handover, and to state which environments and client types are in scope. The fixed-scope agreement that follows from that written scope is where the price is set.
Can our own team upgrade Ceph to Tentacle without a partner?
Often yes, if the team already runs cephadm clusters and has tested upgrades in a non-production environment. The skills that matter are reading health output, understanding how cephadm staggers daemons, handling require-osd-release correctly, and knowing how clients will behave after the change. Teams with limited Ceph operations experience, no staging cluster, or strict change windows usually benefit from an outside plan and a second pair of hands during the run. Check whether your engineers have recently completed a Squid-based upgrade or equivalent work, whether they can reproduce the cluster in a lab, and whether they have time to run the test plan before Squid's estimated end of life, which the Ceph releases page lists as October 31, 2026.
What does the upgrade need from our team?
Expect to provide named owners and access, not just approval. The usual inputs are current cluster and host inventory, the cephadm version and service specifications, a list of clients and their kernel and librados versions, network and monitoring details, and a maintenance window agreed with application owners. Your team also needs to supply a staging environment or agree to build one, backup and restore confirmation, and people who can make go or no-go decisions between stages. Ask the provider which of these items they expect in writing before work starts, and who signs off each checkpoint.
How long does a Ceph Squid to Tentacle upgrade take?
Duration depends on the number of daemons, the amount of data that must recover or rebalance between stages, the size of the test matrix, and how many change windows the business allows. Staggered upgrades run one daemon type at a time, so larger clusters with many OSDs take longer even when each step is quick. Planning and staging usually take longer than the production run itself. The Ceph release notes and cephadm documentation describe the upgrade mechanics, but they do not give a duration for your cluster. Ask for a timeline that shows each phase, the checkpoints, and the dependencies on your own change calendar, and confirm it against a rehearsal in staging.
Can we roll back a Ceph Squid to Tentacle upgrade once it starts?
Plan on the basis that a rollback is not a routine step. Once daemons have moved to Tentacle and cluster features such as require-osd-release have been raised, reverting to Squid is not something to rely on, so the plan should be built around verification at each stage instead of a reversal. A rollback-free test plan means proving the upgrade in a non-production cluster, keeping verified backups, confirming health before each stage, and defining stop conditions that pause the run before it becomes irreversible. Ask your provider to document which steps are reversible, which are not, and what recovery looks like if a stage fails, and confirm that answer in your own staging environment.
What should we ask a partner for in a quote?
Ask for a written scope that names the source and target versions, the environments covered, the cephadm and host inventory assumptions, and the client types included in validation. The quote should list deliverables such as the health check report, the staggered upgrade runbook, the require-osd-release and defaults review, the test plan, and the post-upgrade checks. Request the exclusions too, for example application testing, hardware work, or Rook-based clusters. Confirm who performs each task, how changes are approved, how the schedule maps to Squid's estimated end of life, and what support is available after the upgrade, whether that is a one-time handover or an ongoing retainer.
Which Tentacle changes and defaults should we review before we upgrade?
Review the release notes for Tentacle and the defaults that affect your cluster, rather than assuming a change is harmless. Check which configuration options have changed, which features will be enabled after require-osd-release is raised, and whether any of your clients rely on behavior that will change. Compare your current settings with what Tentacle expects, and record any deliberate overrides so they can be retested. Tentacle's first release date, November 18, 2025, and its estimated end of life of June 1, 2027, come from the Ceph releases page, but the exact changes must be confirmed in the Tentacle release notes for your version.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so the Squid to Tentacle upgrade runs in your cloud accounts, data centers or air-gapped network. Each engagement starts with a written scope that sets out the health checks, upgrade order and test plan before any cluster is touched.
How we scope
- We confirm your current Squid point release, cephadm version and host inventory before agreeing the upgrade path.
- The written scope lists every OSD, monitor, manager, gateway and client type that must be checked before the upgrade starts.
- We agree which clients, kernels and librados versions must be verified for compatibility with Tentacle before the cluster is changed.
How we build
- We prepare a staggered daemon upgrade order and a runbook covering health gates between each daemon group.
- We script the pre-upgrade checks, the require-osd-release step and the post-upgrade verification so each stage is repeatable.
- We test the full plan in a non-production cluster that matches your topology before it is run against production data.
How we hand over
- You receive the runbook, the health check scripts, the test evidence and a record of every configuration change made.
- We document the new Tentacle defaults that differ from your Squid settings and the decisions your team needs to confirm.
- We walk your operators through the cutover, the monitoring checks and the criteria for stopping the upgrade safely.
How we support
- Fixed-scope engagements close with a written handover, and any follow-up work is quoted separately against a new written scope.
- Ongoing support, point release rollouts and continuous testing are available as a retainer for clusters that need them.
- Ask for the support level, response expectations and named contacts in writing before the engagement begins.
