Why a ceph-ansible or ceph-deploy cluster needs a conversion plan
Converting a ceph-ansible or ceph-deploy cluster to cephadm is an in-place adoption of daemons that are already running, not a data migration. The data stays on the OSDs where it is, and the work consists of bringing each monitor, manager, OSD, metadata server and gateway under cephadm's container-based management. How long that takes and how much risk it carries depends on three things: the Ceph release the cluster runs today, the state of each host (operating system, container runtime, package versions and any hand-made configuration), and the mix of daemons that must be adopted.
The first decision is the release level. cephadm was introduced in v15.2.0 (Octopus) and does not support older releases, so a cluster running anything earlier must be upgraded before it can be adopted. Confirm the exact running version of every daemon with ceph versions and compare it against the release status on the Ceph releases page. Mixed versions across daemons are a warning sign in their own right, and a cluster that is partway through an earlier upgrade needs that upgrade finished or stabilized before any conversion starts. The Ceph active releases page is the reference for which releases still receive backports and security fixes.
Start with an inventory, not with commands. List every host, every daemon and the deployment tool that created it, and record the configuration that lives outside the cluster itself, such as custom systemd units, hand-edited ceph.conf files and monitoring exporters. This inventory tells you which hosts can be adopted cleanly and which need preparation first. Confirm with your own change records who owns each host, because the conversion changes how daemons are started and restarted on those hosts.
Which legacy configuration and daemons map cleanly to cephadm
This table compares each element of a ceph-ansible or ceph-deploy cluster with its cephadm equivalent and marks whether it is adopted in place, redeployed, or assimilated into the centralized configuration store. Read the Action column first to plan the change window, then use the notes to confirm each item in your own environment before starting.
| Legacy element | Action | cephadm equivalent and migration note |
|---|---|---|
| ceph-ansible playbooks and group_vars | Redeployed | Playbooks are retired, not converted. Record the values they set (network, pools, OSD layout) and rebuild them as cephadm service specifications and host inventory. |
| ceph-deploy config files and keyrings | Assimilated | Move settings from ceph.conf into the centralized config store and confirm which keys remain file-based. Keyrings are imported into the cluster auth database, so review client caps before cutover. |
| systemd-managed MON daemons | Adopted in place | cephadm adopts existing monitors into containers. Confirm quorum health and monitor addresses before and after adoption. |
| systemd-managed MGR daemons | Adopted in place | Managers are adopted like monitors. Modules you depend on, such as the dashboard, must be re-checked after the move because their configuration may need reapplication. |
| systemd-managed OSD daemons | Adopted in place | OSDs are adopted one host at a time, keeping data in place. Confirm that device paths and any WAL or DB partitions remain correctly referenced. |
| MDS daemons for CephFS | Redeployed | Metadata servers are commonly recreated under cephadm with a service specification rather than adopted. Plan a window for client reconnection and confirm the filesystem name and placement. |
| RGW daemons for object storage | Redeployed | Gateways are usually redeployed under cephadm with a service specification. Client endpoints, load balancer targets and TLS certificates must be updated to match the new daemons. |
| RBD pools and images | Assimilated | Block images stay in their pools and need no conversion. Assimilate the RBD client settings into the config store and confirm that clients still see the same pools. |
| CephFS filesystem and data pools | Assimilated | The filesystem metadata and data pools persist. Confirm the filesystem and pool names, then align MDS placement with the new service specification. |
Documented adoption and redeploy paths in cephadm
The adoption path takes daemons that were started by ceph-ansible or ceph-deploy and brings them under cephadm control without rebuilding them. The documented approach uses the cephadm adopt command on each host, naming the daemon type and identifier. Adoption moves the daemon's unit definition and data layout into the container model that cephadm uses, so the daemon runs under a cephadm-managed systemd unit afterward. Confirm the exact syntax, the supported daemon types and the prerequisites for your target release in the cephadm documentation before running anything.
- Host change: each adopted daemon gets a cephadm-style systemd unit and runs from a container image instead of the packaged binaries.
- Order: adopt monitors and managers first, then OSDs, then metadata and gateway daemons, following the documented sequence.
- Image pinning: choose the container image deliberately, since adoption will run that image for every daemon you convert.
- Rollback planning: keep the legacy unit files and configuration until each daemon has run stably under cephadm.
- Verify afterward: check
ceph orch psfor every adopted daemon, confirm cluster health withceph -s, and confirm each daemon reports the expected version.
After each adoption, confirm that the daemon rejoined the cluster and that no unexpected restarts or quorum changes occurred.
Legacy deployments usually keep settings in a local ceph.conf on every host. Assimilation imports those settings into the cluster configuration database, the central store that cephadm and the monitors read. The documented command for this is ceph config assimilate-conf, which reads a file and writes the recognized options into the store. Options that are not recognized, or that were set in per-host sections, need review because they may not carry over the way you expect. Confirm the flags and behavior for your release in the cephadm documentation.
- Host change: the local configuration file is read but not removed, so hosts keep their old file until you clean it up deliberately.
- Cluster change: accepted options move into the central store and apply cluster-wide or to the scoped daemon class you set.
- Review step: run the command with a dry-run style check where your release supports it, and compare the result with the original file.
- Leftovers: per-host overrides and deprecated options may remain in files and need a separate decision.
- Verify afterward: run
ceph config dumpand compare the effective values with the original file for critical settings such as network and memory options.
Remove or trim the local files only after the central store shows the values you expect and the daemons have restarted cleanly.
Metadata servers and Object Gateway daemons are often easier to redeploy through the orchestrator than to adopt in place. Redeployment creates the service under cephadm with a service specification, then removes the legacy daemon once the new one serves traffic. For CephFS, the MDS service is defined by filesystem and placement. For RGW, the service is defined with its realm, zone and placement details where applicable. The exact specification fields and commands should be taken from the cephadm and Object Gateway documentation for your release.
- Host change: the new daemon runs as a cephadm-managed container, and the legacy daemon stays until you stop it.
- Placement: define the hosts and count explicitly so the orchestrator places daemons where your load balancers expect them.
- Client impact: RGW endpoints and load balancer health checks may need updating during the switch, so plan a short overlap window.
- Filesystem safety: confirm active and standby MDS roles before retiring any legacy daemon.
- Verify afterward: check
ceph fs statusfor MDS state, and check RGW endpoints with real S3 or Swift requests from a test client.
Do not retire the legacy RGW or MDS until client traffic and failover behavior have been tested against the new daemons.
During a conversion, the cluster can report daemons it no longer manages through the orchestrator. These stray daemon warnings usually mean a legacy daemon still runs on a host that cephadm does not track, often after an incomplete adoption or a redeploy that left the old process in place. Clearing the warning should follow the cause, not just silence the health check. The cephadm documentation describes how to identify and resolve these cases for your release.
- Identify first: use the health detail output to list each stray daemon, its host and its type.
- Decide per daemon: adopt it, redeploy it, or retire it, depending on whether it is still needed.
- Host check: confirm no leftover systemd unit or container continues to run after a retirement.
- Health baseline: make sure the warning is the only remaining issue before closing the change.
- Verify afterward: confirm
ceph health detailno longer lists stray daemons and thatceph orch psmatches the expected daemon inventory.
Keep a written inventory of every daemon before and after the conversion so the final state can be checked against the plan.
How a conversion runs from inventory to cleared warnings
The sequence takes a ceph-ansible or ceph-deploy cluster from an unmanaged inventory to one where cephadm owns every daemon, and where the old automation can no longer change the layout. Each step ends with a check that tells the team whether it can move on.
Inventory the release, hosts, daemons and configuration
Record the running Ceph release on every daemon, the operating system and kernel on each host, and the daemon placement across monitors, managers, OSDs, MDS and RGW. Export the central configuration database and the ceph-ansible or ceph-deploy inventory and group variables, then note any settings that live only in local configuration files. The step is done when the team can list every daemon, its host and its version, and can name the playbook or deployment tool that created it. Confirm the target release and its upgrade path with the Ceph releases index before any host is touched.
Prepare hosts and SSH access for the orchestrator
Install a supported container runtime on every host and confirm the nodes can pull the Ceph container image from the registry your environment allows, including air-gapped mirrors where they apply. Create the account cephadm will use over SSH, install its public key on each host, and confirm the orchestrator can reach every node with passwordless access and the expected sudo rights. Verify time synchronization and the host network bonds that the cluster already depends on. The step is done when a test connection to each host succeeds from the admin node and the container runtime reports healthy on all of them. Check the cephadm documentation for the exact host requirements of your release.
Rehearse the conversion in a non-production cluster
Build a non-production cluster on the same release and deployment method, ideally with similar host layout and a copy of the production configuration. Run the full sequence there, including adoption, MDS and RGW redeployment and warning cleanup, and record each command, the output you expected and the output you saw. Time-box the rehearsal around the team's own change windows rather than against a published estimate. The step is done when the rehearsal runs end to end without manual fixes that are absent from the runbook. Use the results to decide whether production needs a different order or extra checks.
Adopt daemons one type at a time
Assimilate the legacy configuration into the central configuration store, then adopt monitors, managers, OSDs and the remaining daemon types one type at a time using cephadm adoption. Adoption converts each daemon in place, so there is no second copy running beside the original, which is why this stage cannot be run as a parallel migration. Run a health check and confirm quorum, placement and OSD states after each daemon type before starting the next. The step is done when every daemon of that type reports as managed by cephadm and the cluster health matches the pre-conversion baseline.
Redeploy MDS and RGW under cephadm
Metadata servers and object gateways are not converted in place in the same way, so redeploy them under cephadm with the placement, ports, realm and zone settings recorded in the inventory. For CephFS, confirm the file system name, the active and standby MDS counts and client mount behavior before removing the old daemons. For RGW, confirm the realm, zonegroup and zone settings, the load balancer or DNS endpoints, and the authentication backends used by clients. Expect a service interruption for affected clients unless your design already provides a second path, and confirm the client impact with the application owners beforehand. The step is done when clients reconnect, S3 requests succeed against the new service endpoints and the old daemons are removed.
Clear stray daemon and cephadm health warnings
After adoption and redeployment, check the cluster for stray daemon warnings, which show up when a daemon is running but not tracked by the orchestrator. Identify each stray daemon, confirm whether it is a leftover from the old tooling, and either adopt it or remove it with the documented cephadm commands. Review any other cephadm warnings, such as host or service health messages, and resolve them rather than suppressing them. The step is done when the health output reports no stray daemons and no open cephadm warnings, and the orchestrator status lists every service as managed.
Retire the legacy automation
Disable and remove the ceph-ansible or ceph-deploy playbooks, inventories and scheduled jobs from every controller, and revoke any credentials those tools used to reach the hosts. Document where the new cephadm specifications and service definitions live, and put them under version control with review. Confirm that no configuration management system or CI pipeline still applies the old layout. The step is done when a test run of the old tooling is not possible from any controller, and the team has a written record of the new source of truth for placement and configuration.
What changes on each host during adoption
cephadm runs every Ceph daemon as a container, and the orchestrator that drives it must be able to reach each host over SSH and run the container runtime there. Before adoption, the host usually runs daemons as systemd units created by ceph-ansible or ceph-deploy, with binaries and configuration installed directly on the operating system. During adoption, each daemon is moved into a container managed by cephadm, and the host itself stays in service while this happens. Each host needs a container runtime that cephadm supports, a cephadm binary, an SSH key trusted by the orchestrator, and enough free space for the container images. Confirm with the cephadm documentation which container runtime and image registry access your release expects, and check that your air-gapped or proxied networks can pull the exact image version you plan to run.
Adopted daemons change how they are started and supervised. The legacy systemd unit files are replaced by units that cephadm generates, so systemctl calls, log locations and restart behavior change for each daemon. Plan for an inventory of every unit on every host before the first adoption, because scripts, monitoring checks and runbooks that reference the old unit names will fail after a daemon moves. Keep the old configuration and data paths in your notes until each daemon has been verified, since adoption moves the daemon's data directory into the cephadm layout rather than copying it elsewhere.
Configuration moves in the same process. Under the legacy tooling, settings are often spread across ceph.conf files on several hosts, Ansible variables and local overrides, which makes it hard to know which value a daemon actually uses. cephadm stores most settings in the centralized configuration database held by the monitors, and the ceph config assimilate-conf step imports what your existing files contain. Once assimilated, the database becomes the source of truth, so ask your team which values must stay in local files, such as the monitor addresses needed for bootstrap, and record every override you keep so that a later change is made in one place.
What drives the effort and duration of a conversion
This table lists the factors that most change how much work a ceph-ansible or ceph-deploy to cephadm conversion involves, the direction each pushes cost, and what to request in a written scope. Read it before asking for a quote, because the same cluster can take very different effort depending on these answers. No duration or fee is implied by any row.
| Driver | Why it changes effort | What to ask for in the written scope |
|---|---|---|
| Cluster size and daemon count | More OSDs, monitors and managers mean more hosts to adopt and more daemons to verify one at a time. Effort rises with count, and each host adds checks. | Inventory of hosts, OSDs, monitors, managers and gateways, with the adoption order and the verification step after each batch. |
| Legacy tool version | The starting release and the ceph-ansible or ceph-deploy version set which steps apply. Older deployments often need more preparation before cephadm can take over. | Confirmed Ceph release running today, the tool and its version, and the target release the cluster will run after conversion. |
| Degree of playbook customization | Heavily customized playbooks, group variables or local templates hold settings that must be found and moved into cluster configuration. Undocumented changes raise effort most. | A review of inventory files, group variables and local overrides, plus a list of settings that must be carried into the new configuration. |
| Host operating system consistency | Mixed operating systems, kernels or container runtimes across hosts mean separate preparation and testing paths. Uniform hosts are simpler to convert in one pattern. | Table of OS release, kernel, container runtime and Python version per host, and the plan for any host that differs. |
| MDS and RGW in use | Metadata servers and Object Gateways need their own redeployment under cephadm and their own client checks. Each service adds steps and a separate test pass. | Count of CephFS file systems and MDS daemons, RGW zones and endpoints, and the client applications that reach them. |
| Network and monitor quorum constraints | Monitor quorum must hold through each step, and public and cluster networks must be reachable from every host. Limited maintenance margin or fragile networks slow the work. | Monitor count and placement, network layout, quorum loss tolerance, and the rollback point if a monitor fails to rejoin. |
| Test environment available | A staging cluster that mirrors production allows dry runs and rehearsed rollback. Without one, more verification moves into the production window. | Whether a test cluster exists, how closely it matches production, and who runs the rehearsal and signs off on results. |
| Change windows and approvals | Limited windows, freeze periods or change board cycles cap how many hosts can be converted per session, which lengthens the overall schedule. | Permitted maintenance hours, freeze dates, approval steps, and the expected pace of host batches agreed with your change process. |
| Health warnings present before start | Existing warnings, scrub errors or near-full OSDs must be cleared or explained before conversion. Unresolved issues add investigation work. | Current cluster health output and a list of open warnings with owners, so the scope can account for remediation first. |
Where conversions usually go wrong
Most failed conversions do not fail during the adoption command itself. They fail afterward, when old automation runs again, daemons disagree about their versions, or a service loses its endpoint during redeploy. Each card below names one risk, the step that prevents it, and the check that shows it is handled.
Legacy automation reapplying old config
The most common cause of drift after conversion is the old playbook or deployment tooling still running on a schedule or in a pipeline. If ceph-ansible or ceph-deploy is run again against a cluster that cephadm now manages, it can write configuration and unit files that cephadm did not create. Disable or remove every scheduled job, CI pipeline and inventory that targets these hosts before adoption starts. The check is to confirm that no job or runner still references the cluster inventory, and that a configuration change made in the cluster survives one full scheduled run window without being reverted.
Stray daemon warnings left uncleared
After adoption, daemons or services that cephadm no longer tracks can keep producing a health warning. Those warnings look minor, so teams often close the change window with them still open. Review the health output after each adoption step, identify each stray daemon by name, and either adopt it or remove it deliberately. The check is that the cluster reports no stray daemon warning, and that the orchestrator's list of daemons matches what is actually running on each host.
Mismatched container images across hosts
A host that still runs an older image, or one that was pulled at a different time, can leave the cluster running mixed daemon versions. This is a risk during and after the conversion, and it becomes harder to diagnose when the same major release is labeled differently on different hosts. Pin the target image explicitly, confirm the image on every host before and after each step, and avoid relying on a floating tag. The check is an inventory of running daemon versions across all hosts that shows one release for each daemon type.
MDS or RGW outages during redeploy
Redeploying metadata servers or Object Gateway daemons can interrupt CephFS clients or S3 traffic if the service is redeployed without spare capacity. The risk is highest when a single RGW sits behind a load balancer with no second instance, or when an MDS standby is missing. Confirm that a standby MDS is available before touching the active one, and that at least one RGW remains reachable while the others are redeployed. The check is a client-side read and write test against each service during every redeploy window, with results recorded.
Undocumented custom configuration
Legacy deployments often carry settings that exist only in group variables, local override files or someone's memory: custom CRUSH rules, tuned OSD parameters, non-default network ranges or RGW options. If these are not captured before conversion, they are lost or silently reset. Export the running configuration with ceph config dump and compare it with the legacy variables, then record every difference. The check is a written list of each custom setting, its source and its status after assimilation, reviewed by the team that owns the cluster.
Insufficient rollback planning
Without a rollback plan, a failed adoption step can leave the team choosing between an unfamiliar state and a rebuild. Plan the rollback before the first step: take a configuration export, confirm recent backups of monitor and critical data, record the current daemon placement, and define which step is the point of no return. Agree who can halt the work and what state the cluster must return to. The check is a dry run of the rollback steps in a non-production cluster, and a sign-off that the backups were restored successfully at least once.
Questions buyers ask before converting a legacy Ceph cluster
How much does converting a ceph-ansible or ceph-deploy cluster to cephadm cost?
The cost depends on how many hosts and daemons the cluster runs, how much of its configuration lives outside the Ceph database, and how many services need to be redeployed. The work is usually a one-time project, but it can leave recurring costs behind, such as a support retainer or an upgrade plan for the new management layer. Ask for a quote that lists each host and daemon group, the configuration review, the maintenance windows, the rollback plan, and the post-conversion verification as separate lines. Confirm with your own team whether the conversion is a fixed-scope engagement or time-and-materials, and what happens if the inventory turns out larger than expected.
How long does a cephadm conversion take?
Duration depends on cluster size, the number of hosts, the amount of custom configuration, and how many maintenance windows your change process allows. Each host is adopted and checked before the next one starts, so the calendar time often depends more on approvals and change freezes than on the technical steps. Ask for a written timeline that shows the inventory and assessment phase, a pilot on a non-production cluster where possible, the host-by-host adoption schedule, and the window for MDS and RGW redeployment. Any duration you are quoted should be tied to a written scope, and you should confirm the Ceph release running on the cluster before agreeing to dates.
What does our internal team need to provide for the conversion?
Your team needs to provide access and knowledge that only your organization holds. This includes read access to every cluster host, the current Ceph configuration and any Ansible inventory or group variables, a list of pools and their client consumers, network and DNS details, and the names of the people who approve change windows. Someone who knows the legacy playbooks or deployment scripts should be available during assessment, because undocumented overrides are the most common source of surprises. Confirm that you have a current, tested backup of the cluster configuration and of any data you cannot afford to lose, and that you know which application owners must be told before RGW or MDS services change endpoints.
Can our team convert the cluster without outside help?
Yes, a capable internal team can perform the conversion, provided it has hands-on experience with the cephadm orchestrator, container runtimes on the hosts, and the legacy tooling being retired. The work includes preparing hosts, assimilating configuration into the central store, adopting daemons one at a time, redeploying MDS and RGW, and clearing stray daemon warnings. Outside help is most useful when the cluster is business critical, when the team has not run cephadm before, or when change windows are tight. Before deciding, list the skills your team has in-house, the people available during change windows, and whether a non-production cluster exists to rehearse the steps.
Is our data at risk during a conversion, and how is it protected?
The conversion changes how daemons are managed, not the data stored on OSDs, but any change to running monitors, managers, or gateways carries operational risk. Data protection depends on verified backups, a tested rollback path, and careful sequencing so that the cluster stays healthy between steps. Ask how the plan checks cluster health before and after each host, how it handles monitor quorum, and which steps are reversible. Confirm the current replication or erasure coding settings, the state of recent scrubs, and whether any pools are already degraded, because those conditions should be resolved before a conversion begins. Also confirm who owns the decision to pause the work if health checks fail.
Do we need to upgrade Ceph before converting to cephadm?
Possibly. cephadm does not support releases older than v15.2.0 (Octopus), so a cluster on an older release must be brought to a supported release before adoption. Beyond that minimum, the decision depends on the release currently running and the release you plan to stay on. The Ceph releases page lists Squid (19.2.x) and Tentacle (20.2.x) as actively maintained, and the Squid estimated end of life is October 31, 2026. Check the release index for your current version, confirm whether it is still receiving backports, and decide whether to adopt first and upgrade later or upgrade first. Treat the sequence as a planning decision to be settled before the conversion is scheduled.
Official Ceph and cephadm documentation to read before scoping
Before scoping a conversion, read the cephadm documentation and the Ceph active releases page together. The cephadm documentation describes how the orchestrator adopts and manages daemons as containers, and the releases page lists which Ceph versions still receive backports and security fixes. Your current cluster version, your target release and the cephadm procedure you plan to follow must all be checked against these two pages, because a conversion is only as safe as the release it lands on. The Ceph releases page currently lists Tentacle and Squid as the actively maintained lines, with estimated end-of-life dates for each. Confirm those dates again on the day you scope, since they move.
Treat the documentation as the source for exact commands, flags and version support, not this page. Ask your partner or your own team to confirm, in writing, the cephadm version that supports adopting your existing daemons, the minimum Ceph release that must be running before adoption begins, and whether any intermediate upgrade is required. Ask also which steps in the conversion procedure are marked as needing a maintenance window and which can run against a live cluster. Note any documented caveats for MDS and RGW daemons, since those are where legacy deployments most often diverge from the cephadm layout.
Record the outcome of this review in the scope document. A useful artifact is a short table that maps each step of the conversion to the documentation section that governs it, the Ceph release it applies to, and the person who verified it. If the documentation for your release differs from what your runbook assumes, the runbook changes, not the cluster. This record also gives your auditors and change board a traceable basis for the procedure, and it keeps the quote tied to the versions your environment actually runs.
How DeployOpen scopes and delivers a cephadm conversion
The sequence turns an undocumented or legacy-managed cluster into one that cephadm manages, with a written scope, a rehearsed procedure, a controlled cutover and runbooks your team can operate. Each stage ends with a check you can review before the next one starts.
Agree the scope in writing
DeployOpen reviews your current Ceph release, deployment tooling, host operating systems, network layout, and the services running on the cluster, including any MDS and RGW daemons, dashboards and client integrations. The written scope lists what is in and out, who approves change windows, and the rollback position you accept. Done means the scope is signed off by your storage owner and change board, with no open questions about ownership of the cluster.
Inventory the existing cluster
DeployOpen collects the cluster state from your environment: daemon placement, configuration sources, cluster health, placement of monitors and managers, client authentication, and any configuration held in ceph-ansible group variables or ceph-deploy notes. The output is an inventory that maps each daemon to its host and service type and flags anything that cephadm will not adopt as found. Done means your team has reviewed the inventory and confirmed that it matches what the hosts actually run.
Confirm prerequisites and release compatibility
Before any change, DeployOpen checks that the Ceph release and host operating system can run the target cephadm and container runtime, and that hosts have the time sync, name resolution, SSH access and container images your environment requires. Gaps are logged as blockers with an owner. The target release is confirmed against the Ceph releases page and any upgrade path. Done means the prerequisite checklist is complete and each blocker is either closed or formally accepted.
Rehearse in a non-production environment
DeployOpen builds a non-production copy of the cluster inside your infrastructure, using the same release, host layout and service mix where possible, and runs the conversion sequence end to end. The rehearsal records the exact commands, the time each stage takes on your hardware, every warning raised, and the rollback steps tested. Done means the rehearsal log is complete, the issues it found are fixed in the procedure, and your team has accepted the revised runbook for production.
Adopt daemons in agreed change windows
During each approved window, DeployOpen assimilates the configuration into the cluster configuration database, adopts monitors, managers, OSDs and gateways under cephadm, and redeploys MDS and RGW services so cephadm manages them. Health is checked between stages, and work stops if the cluster leaves its expected state. Done means every daemon reports under cephadm, the cluster health matches the pre-change baseline, and clients have been verified against the new endpoints.
Clear stray daemon and health warnings
After adoption, DeployOpen identifies stray daemons that cephadm does not manage, removes or re-adopts them under a documented change, and clears any remaining health warnings with a reason recorded for each. Monitoring and alerting are checked against the new daemon names. Done means the cluster reports no stray daemon warnings, and the remaining health state is documented against the baseline.
Hand over runbooks and operating procedures
DeployOpen delivers the final inventory, the adoption record, the runbooks for routine operations such as host addition, daemon restart and upgrade with cephadm, and the rollback procedure your team tested in rehearsal. Your operators walk through the runbooks with DeployOpen. Done means your named operators have run at least one routine task from the runbook themselves and the handover package is accepted in writing.
Decide on ongoing support or retainers
After handover, you choose whether your team operates the cluster alone or with DeployOpen support. Ongoing support, upgrade planning and continuous testing are available as retainers with terms agreed in writing. Your quote should state what the retainer covers, how upgrades are scheduled, and how urgent requests are handled. Done means the operating model is recorded in writing, with a named contact for the cluster.
