Why a Quincy cluster needs two hops to reach Tentacle
If your cluster runs Quincy, you cannot move straight to Tentacle. The Tentacle release notes support upgrades from Reef and Squid only, so Quincy is not a listed source and the path runs through Squid first. The Squid release notes, in turn, support upgrades from Quincy and Reef, which makes Squid the required intermediate step for a Quincy cluster. The two hops are shaped by the support calendar on the Ceph active releases page. Squid (19.2.x) has an estimated end of life of October 31, 2026, and Tentacle (20.2.x) has an estimated end of life of June 1, 2027. Squid is the release that gets you off Quincy, and it is also the release you will be running while you plan the second hop. Because the Squid end of life comes before the Tentacle one, a slow first hop leaves less room for the second. Confirm these dates against the releases page on the day you plan, since estimates can change.
Work backward from the Tentacle target. Decide when the Squid stop will finish, then schedule the Tentacle hop so it completes well before October 31, 2026 instead of treating the two hops as independent projects. Ask your vendor or internal team to confirm how long each hop will take in your environment, including the health checks and soak time you will want between them, since neither is set by the release notes. Also confirm that your current cluster really is on Quincy and not an older release that needs an earlier step. The upgrade path is only as reliable as the version you start from, so record the exact running version of every daemon before you approve the plan.
What changes between Quincy, Squid and Tentacle
This table compares what each hop of the Quincy to Squid to Tentacle path asks of operators, using the upgrade sources, release dates and support windows published for Squid and Tentacle. Read each row as a pre-upgrade check for the hop named in its column. The main takeaway is that Quincy can move to Squid directly, but Tentacle accepts only Reef or Squid as a source, so the second hop must be scheduled against Squid's estimated end of life.
| Item | Quincy to Squid | Squid to Tentacle | Action for operators |
|---|---|---|---|
| Supported upgrade source | Squid release notes list Quincy as a supported source | Tentacle release notes list Squid as a supported source, not Quincy | Confirm the cluster is on Squid before starting the Tentacle hop |
| Release first published | Squid first released September 26, 2024 | Tentacle first released November 18, 2025 | Note both dates when agreeing the upgrade window with stakeholders |
| Estimated end of life | Squid estimated end of life is October 31, 2026 | Tentacle estimated end of life is June 1, 2027 | Schedule the Tentacle hop well before October 31, 2026 if the cluster must stay supported |
| Target branch and point release | Squid 19.2.x, latest listed as 19.2.7 | Tentacle 20.2.x, latest listed as 20.2.4 | Check the releases page for the newest point release on each branch before you start |
| Deployment method | Confirm the cluster is managed by cephadm, which does not support releases older than v15.2.0 | Confirm the cluster is still managed by cephadm after the first hop | Convert any non-cephadm cluster before the first hop, not during it |
| Detailed changes and defaults | Read the Squid release notes for upgrade notes, defaults and required settings | Read the Tentacle release notes for upgrade notes, defaults and required settings | Use each set of notes as the checklist for its hop, since this table does not list every change |
What to prepare before the first hop
Preparation decides whether the Quincy to Squid hop is a routine rolling change or an incident. The cards below cover what to protect, what to inventory, what to verify on hardware and networking, and where to rehearse the upgrade before production is touched.
Back up cluster state and configuration
Capture the cluster configuration, the cephadm service specifications, the monitor store and the CRUSH map before the first hop, and store copies outside the cluster. Record the output of the cluster health commands so you can compare it after each hop. Confirm with your own team how long a restore from these backups would take, because a backup you have never restored is an assumption, not a recovery plan. Keep the cephadm specs and key material under the same access controls as the cluster itself.
Inventory clients and their versions
List every client that talks to the cluster: kernel RBD mounts, librados applications, CephFS mounts, hypervisors, and any Kubernetes consumers through Rook. Older kernel and librados clients may not work with newer defaults, so record their versions now. Note which clients connect to monitors on the v2 port 3300 and which still rely on the older v1 port, because that affects firewall rules and client configuration.
Document custom settings and integrations
Record every setting you changed from the defaults, including messenger v2 options such as secure mode, RGW configuration for authentication backends, multisite and compression settings, and Dashboard single sign-on. For the Dashboard, note whether SAML 2.0 or OAuth2 through the Management Gateway and OAuth2 Proxy services is in use. Each item is a candidate for a post-upgrade check, and some may need review against the Squid release notes before you start.
Check hardware against the recommendations
Compare each OSD with the hardware recommendations: a dedicated drive per OSD, WAL and DB on shared SSDs for HDD-based OSDs, and enterprise-class SSDs for metadata. Confirm that memory is sized for peak use during recovery and backfill, not for quiet periods, because the upgrade itself triggers daemon restarts and data movement. Identify any host already close to its memory limit and plan around it.
Verify bonded network links
Confirm that each host's public and cluster networks use bonded links spread across two switches, as the hardware recommendations advise. Check that the bonds are healthy, that failover has been tested, and that MTU settings match on every host and switch port. A single switch failure during a daemon restart is a common reason an upgrade stalls, so verify this before the window opens, not during it.
Build a test environment that mirrors production
Rehearse both hops on a test cluster that matches production in release, daemon layout, OSD media, network topology and client mix. Use it to time the cephadm upgrade, to test rollback steps, and to confirm that client workloads keep working after each hop. A smaller cluster can prove the procedure but not the timing, so note any differences between the test and production environments and what they could change.
How the two-hop upgrade runs with cephadm
The sequence moves a cephadm-managed Quincy cluster to Squid, confirms it is stable, and then moves it to Tentacle, with a decision point after each hop so the team knows when it is safe to continue. Each hop closes with checks that show the cluster and its clients are healthy before the next change starts.
Run baseline health and inventory checks
Before any change, record the cluster health state, the running Ceph version on every daemon, the host and OSD inventory, and any open health warnings. Confirm that all hosts are reachable through cephadm, that spare capacity exists for recovery during daemon restarts, and that a recent, tested backup of cluster configuration and critical data is in place. The engineer running the upgrade signs off the baseline in the change record. The step is done when every warning has an owner and a decision on whether it blocks the upgrade. Exact health commands are in the Squid release notes and the cephadm documentation.
Resolve blockers and confirm release prerequisites
Read the Squid release notes for the Quincy to Squid path, including the upgrade notes, deprecations and any required configuration changes. Check that the container image for the target release is available to every host, either from the public registry or from a local mirror. Clear any health warnings that the release notes list as blockers. The step is done when the change owner has a written list of required pre-upgrade actions and each one is marked complete.
Upgrade the cluster to Squid with cephadm
Start the cephadm-managed upgrade to Squid so the orchestrator rolls the managers, monitors, OSDs, metadata servers and gateways through their new images in its managed order. The team watches the upgrade status and cluster health throughout, and pauses or stops the upgrade if health degrades beyond what the release notes describe as expected. The step is done when the orchestrator reports the upgrade complete and every daemon reports a Squid version. The staggered daemon order, commands and monitoring points are detailed in the sibling Squid to Tentacle page and the release notes.
Verify daemons and client access on Squid
Confirm that every daemon runs the target version, that placement groups are active and clean or recovering as expected, and that no unexpected health warnings appear. Test representative clients for each interface in use, such as RBD mappings, CephFS mounts and S3 requests through the Object Gateway, to confirm that authentication and data paths still work. Record results for each client type. The step is done when the verification record shows every client type tested and passing, and any exception has an owner and a fix plan.
Decide on rollback and hold for stability
This is the first decision point. Review the verification record with the change owner and the application owners, and decide whether to continue to Tentacle. Note that a rollback to Quincy after the upgrade is not a simple reversal: confirm what the release notes say about downgrading and what your backup can restore before accepting the Squid state. Hold the cluster on Squid for a defined period agreed in the change plan, with monitoring in place, so that latent issues surface before the second hop. The step is done when the decision is recorded with a named approver and the hold period is written into the plan.
Re-run baseline checks before the second hop
Repeat the health, inventory and backup checks against the stable Squid cluster, using the same method as the baseline. Confirm the Tentacle release notes list no new blockers for your configuration, that required settings from the Squid release are in place, and that the Tentacle image is available to every host. Compare results with the first baseline to catch drift. The step is done when the pre-upgrade list for Tentacle is complete and the change owner has signed off.
Upgrade the cluster to Tentacle with cephadm
Start the cephadm-managed upgrade from Squid to Tentacle, following the staggered daemon order and the post-upgrade settings described in the sibling Squid to Tentacle page and the Tentacle release notes. Monitor health and the upgrade status until the orchestrator reports completion and every daemon reports a Tentacle version. The step is done when the cluster reports healthy on Tentacle, with the required release settings applied and confirmed.
Complete post-upgrade verification and close the change
Repeat the daemon and client verification on Tentacle, covering RBD, CephFS, Object Gateway and any integrations, and review monitoring and logs for the first full operating window. Record the final versions, the backup taken before each hop and any open follow-up items. Schedule the next support review against the published end of life for Tentacle, which is June 1, 2027 according to the Ceph releases page. The step is done when the final change record is approved and every follow-up item has an owner.
How to test each hop and decide on rollback
Operators own the cluster-level evidence that each hop is safe to continue. Run the same checks before the first hop, between the hops and after Tentacle is running, and keep the outputs so the comparison is possible. Confirm that the cluster is healthy and that the cephadm orchestrator reports the expected version on every daemon before any change is made.
- Health baseline: Capture
ceph health detail,ceph versionsandceph orch psoutput before the hop starts, and stop if unexplained warnings are present. - Placement and recovery: Confirm that placement groups are active and clean, and that no recovery or backfill is in progress when the hop begins.
- Client path: Verify monitor quorum, manager failover and client connectivity from a test host using the protocol versions your clients use.
- Staggered daemon progress: Watch each daemon restart in the order cephadm applies, and halt the upgrade if a daemon does not return to up and in.
- Release-specific settings: Review the Squid and Tentacle release notes for required flags and deprecations, and record each setting you change.
Before sign-off, check that the post-hop output matches the baseline, apart from the version change you expected.
Application owners test the workloads that depend on the cluster, because a healthy cluster can still break a client library, a driver or an access policy. Build the test list from the services your organization actually runs, and agree who signs off each service. Run the same scripted checks after each hop so that any difference is traceable to one change.
- RGW (object storage): Run S3 PUT, GET, multipart upload, list and delete tests with the credentials and client SDKs your applications use, and confirm lifecycle and versioning behavior on a test bucket.
- RBD (block storage): Attach a test image to a representative virtual machine or host, write and read data with checksums, then take and roll back a snapshot.
- CephFS (file storage): Mount the file system with each client type in use, then test create, rename, lock and quota behavior with real application paths.
- Authentication: Confirm that existing keys, Keystone or LDAP integrations and dashboard single sign-on still work where you use them.
- Client versions: Test the oldest kernel and library clients you still run, because their compatibility can differ from current clients.
Application owners should record results per service and per hop, not as a single pass or fail for the whole cluster.
The decision owner, usually a platform lead with input from security and the service owners, decides whether to continue, pause or stop. Rollback is not the same at each hop, so the test plan must state what can be reversed, what cannot and what the fallback is for each. Agree these answers before the production window, when there is no time to research them.
- Pre-agreed stop criteria: Write the conditions that stop the hop, such as failed daemons, client errors or data-path latency beyond an agreed threshold, and name who can call a stop.
- Quincy to Squid rollback: Confirm with the Squid release notes and the cephadm documentation whether a downgrade is supported at that point, and what backup or restore would be needed if it is not.
- Squid to Tentacle rollback: Treat this hop as a separate decision, because the release notes and any flags set during the upgrade determine what can be undone.
- Backups and snapshots: Confirm that a tested backup of critical pools and configuration exists and that a restore has been rehearsed in a non-production environment.
- Communication: Decide who informs application owners, when a pause is declared and who approves moving to the next hop.
Record the decision, the evidence behind it and the named approver for each hop in the change record.
What makes a Ceph upgrade take longer
This table lists the factors that lengthen a Quincy to Squid upgrade and what each one adds to the work. Read it before requesting a quote, since each row is a question the scope must answer. The main takeaway is that the cluster's size and feature use matter more than the version numbers alone.
| Driver | Why it adds effort | How to keep it down or what to confirm |
|---|---|---|
| Cluster size and host count | Each host needs its cephadm daemons upgraded in turn, and more hosts mean more staggered restarts and more health checks between them. | Confirm host count and daemon layout in the scope. Ask whether the upgrade window covers all hosts or only a subset. |
| Number of OSDs and data volume | Restarting OSDs triggers peering and recovery, and a larger data set means longer rebalancing and more time before the cluster reports healthy. | Check current recovery backlog and free capacity before the first hop. Record the expected health state after each restart. |
| RGW multisite | Zones and realms must stay compatible across the hops, and gateways in each zone need coordinated upgrades and sync checks. | Confirm the number of zones, the sync status and whether gateways can be upgraded in a planned order. |
| Dashboard SSO and custom integrations | Single sign-on through SAML 2.0 or OAuth2 with the Management Gateway and OAuth2 Proxy services, plus custom scripts or monitoring hooks, must be retested after each hop. | Inventory every SSO configuration and integration. Ask for a retest list covering login, API calls and alert paths. |
| Client mix | Older kernel and librados clients may not work with the newer release or with changed tunables, so client upgrades can end up on the critical path. | List every client type and version, including hypervisors and Kubernetes nodes. Confirm which clients need updates before the cluster moves. |
| Air-gapped image mirroring | The Squid and Tentacle images, and any monitoring images, must be mirrored into a local registry and pulled by every host before the upgrade starts. | Confirm the registry location, the image list for each hop and that every host can pull each image. Ask who maintains the mirror. |
| Testing between the two hops | Squid must run stably before Tentacle is attempted, so checks, soak time and rollback planning are added between the two upgrades. | Agree on written pass criteria for each hop. Ask whether test clusters or a staging environment are included in the scope. |
Questions teams ask before upgrading Ceph from Quincy
Can we skip Squid and upgrade from Quincy straight to Tentacle?
No. The Tentacle release notes list Reef and Squid as supported upgrade sources, so a Quincy cluster has to reach Squid before it can move to Tentacle. The Squid release notes list Quincy and Reef as supported sources, which makes Squid the first hop. Each hop is a separate cephadm upgrade with its own health checks, and the second hop should start only after the cluster has run stable on Squid for a period your team agrees in advance. Build both hops into one written scope with a checkpoint between them. Keep the calendar in view: Squid's estimated end of life is October 31, 2026, and Tentacle's is June 1, 2027, according to the Ceph releases page.
What does a Ceph Quincy to Squid upgrade cost?
The cost sits in labor, testing and time, because Ceph is licensed under LGPL and the project sells no paid edition. DeployOpen does not publish a price list. A quote follows the written scope, which is usually fixed. Costs fall into four groups: planning and pre-checks, execution of each hop, validation between hops, and documentation and handover. Some costs are one-time, such as the upgrade itself. Others recur if you buy a support retainer afterward. Drivers include host and OSD count, the number of client types that must be checked, whether a staging cluster exists, whether the site is air-gapped, and how much of the work your staff take on. Ask each quote to show hop-by-hop line items, test environment assumptions and any retainer terms.
How long does the upgrade take, and what changes the answer?
No duration can be fixed in advance, because the elapsed time depends on the cluster itself. Daemon restarts are staggered across hosts, and each stage waits for health to return to a clean state. Recovery after restarts depends on how much data the cluster holds and how quickly it can move that data. Host and OSD count, existing health warnings, maintenance window limits and the length of your staging run all change the calendar. Clusters with many clients also need extra time for client checks. Ask for a schedule that lists each hop, its checkpoints, the windows you must hold and the points where work waits for your approval. Confirm the sequence in the Squid release notes before you commit to dates.
What does our team need to provide before the work starts?
Your team provides access, an accurate picture of the current cluster, verified backups and decisions about change windows. Expect to provide:
- Administrative access through cephadm and the orchestrator, plus host access as agreed in the engagement
- A current inventory of hosts, daemons, OSDs, pools and the CRUSH map
- Recent health output, existing warnings and any known scrub or recovery issues
- Verified, restorable backups of the data the cluster holds
- A list of clients with their kernel and librados versions
- A staging cluster or test environment, if one exists
- Named approvers for each change window and for the go or stop decision between hops
Can our own staff run the Quincy to Squid upgrade?
Yes, if your staff have run cephadm upgrades before and have time to work through each hop carefully. Cephadm manages the cluster as containers, so the person running the upgrade should be comfortable reading orchestrator status, daemon logs and health output. Your team should also be able to read the Squid and Tentacle release notes, interpret health warnings and make a stop decision. Teams without that experience may prefer a fixed-scope engagement, with DeployOpen running planning, hops and validation under a written scope. Many teams split the work, with internal staff owning access and change windows while a partner handles pre-checks and sequencing. Check your skills against the cephadm documentation before you decide.
What happens if the Squid hop fails halfway through?
Stop before the next hop, then diagnose the failure from the cluster's own health output and logs. Do not start the Tentacle hop on a cluster that is unhealthy or only partly upgraded. Confirm which steps can be reversed before the window opens, because a cluster that has moved daemons to a new release may not return to the old one through a simple command. If data is at risk, restore from the backups verified before the work started. Agree these steps in the written scope: who can call a stop, what evidence is collected, how long the cluster stays in a stable state, and who approves a resumed attempt. Keep the cluster running a supported release while you investigate.
When must we finish the second hop to Tentacle?
Work backward from Squid's estimated end of life of October 31, 2026, as listed on the Ceph active releases page. Tentacle's estimated end of life of June 1, 2027 sets the target for the finished upgrade, but the Squid date sets the planning deadline for leaving Squid. The second hop should land with time to spare, so a problem on the first hop still leaves room to recover. Both dates are estimates, so confirm them on the releases page before you set a calendar. Ask your partner to list each decision point tied to these dates, including when your change board must approve the Tentacle window.
What a fixed-scope Ceph upgrade engagement includes
A fixed-scope engagement for this upgrade produces four deliverables, and each one is written before the cluster is touched. The first is an inventory and readiness assessment covering every cephadm-managed host, the monitor and manager placement, OSD media and layout, the RGW and dashboard services, client types (RBD, CephFS, RGW, and any librados or kernel clients), and the current ceph versions output across daemons. The assessment also records the health state of the cluster before work begins, so that any warning that appears later can be traced to the upgrade rather than to a condition that already existed. The second deliverable is a written two-hop runbook: Quincy to Squid, then Squid to Tentacle, with the pre-checks, the cephadm upgrade commands, the order in which daemons are restarted, the require-osd-release step at each hop, and the rollback position for each stage. Because the Squid release notes and the Tentacle release notes list different supported source releases, the runbook states explicitly why the intermediate hop is required and which notes were used for each step.
The third deliverable is test evidence from each hop. This means recorded health output and daemon version checks before and after Squid, a short soak period on Squid with client I/O and RGW traffic, and the same checks again after Tentacle. Evidence should be stored with timestamps so that a reviewer can see what was true at each gate. The fourth deliverable is handover documentation: the as-built state of the cluster, the runbook as executed with any deviations noted, operator procedures for the next upgrade, and the monitoring thresholds to watch. Ask the vendor to specify in the statement of work who performs the Tentacle hop, how long a soak window will last, and who signs off each gate. The scope, deliverables and timeline are agreed in writing before work starts, and any change to them is handled through a written change request. Ongoing support, point release handling and later upgrades are available as a retainer, which suits teams that will not keep Squid's estimated end of life of October 31, 2026 and Tentacle's estimated end of life of June 1, 2027 in their own calendars.
How DeployOpen scopes and delivers the Ceph upgrade
DeployOpen plans, implements, tests, documents and supports self-hosted open-source platforms inside infrastructure you control. For a Ceph Quincy to Squid upgrade, the work starts with a written scope that covers both hops, the checks between them and the handover, before any cluster is changed.
How we scope
- Inventory every cephadm-managed host, daemon version, OSD type and client that depends on the cluster before agreeing the scope.
- Confirm the written scope covers the Quincy to Squid hop, the health checks between hops and the planned Squid to Tentacle step.
- Agree deliverables, timelines and responsibilities in writing; engagements are fixed-scope, and quotes follow from that written scope.
How we build
- Run pre-upgrade health checks and a rehearsal in a non-production environment that mirrors your Quincy cluster as closely as practical.
- Execute the cephadm upgrade to Squid with staged daemon order, then verify health and client connectivity before starting the next hop.
- Record each checkpoint, command output and rollback decision so the Squid to Tentacle step has a tested baseline to start from.
How we hand over
- Deliver the runbook, post-upgrade validation results and the list of configuration changes made during both hops.
- Walk your operations team through monitoring, health warning triage and the commands used for the next upgrade.
- Confirm with your team which Squid and Tentacle end of life dates and point releases apply to your schedule before handover closes.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer for clusters that need help after handover.
- Retainers can cover planning the Squid to Tentacle hop ahead of Squid's estimated end of life, so the schedule is set early.
- Ask for the support boundaries, response arrangements and included upgrade work in writing before signing any retainer.
