openstack-k8s-operators · openshift-merge-bot · Mar 16, 2026 · Jan 23, 2026
diff --git a/docs_user/assemblies/assembly_migrating-ceph-cluster.adoc b/docs_user/assemblies/assembly_migrating-ceph-cluster.adoc
@@ -31,6 +31,7 @@ already part of the {CephCluster} cluster.
 
 Before you begin the migration, complete the tasks in your {rhos_prev_long} {rhos_prev_ver} environment. For more information, see xref:red-hat-ceph-storage-prerequisites_configuring-network[{Ceph} prerequisites].
 
+include::../modules/con_ceph-migration-dcn.adoc[leveloffset=+1]
 
 include::../modules/con_ceph-daemon-cardinality.adoc[leveloffset=+1]
 

diff --git a/docs_user/modules/con_adoption-limitations.adoc b/docs_user/modules/con_adoption-limitations.adoc
@@ -29,9 +29,7 @@ Unsupported features::
 +
 The adoption process does not support the following features:
 +
-* Distributed Compute Node (DCN) architecture with storage services at remote or edge sites
 * DNS-as-a-service (designate)
-* {loadbalancer_first_ref}
 * Adopting Border Gateway Protocol (BGP) environments to the {rhos_acro} data plane
 * Adopting a Federal Information Processing Standards (FIPS) environment
 

diff --git a/docs_user/modules/con_ceph-migration-dcn.adoc b/docs_user/modules/con_ceph-migration-dcn.adoc
@@ -0,0 +1,44 @@
+:_mod-docs-content-type: CONCEPT
+[id="ceph-migration-dcn_{context}"]
+
+= {Ceph} migration for Distributed Compute Node deployments
+
+[role="_abstract"]
+Before you adopt your Distributed Compute Node (DCN) deployments that host {CephCluster} clusters on Compute nodes at edge sites so that your architecture runs on {rhos_long} (RHOSO), be aware of important considerations.
+
+Supported edge storage topologies:: DCN deployments support the following storage topologies at edge sites:
++
+* Hyperconverged Infrastructure (HCI): {Ceph} daemons run on Compute nodes at each edge site.
+* {OpenStackPreviousInstaller}-deployed dedicated storage: {Ceph} runs on separate storage nodes deployed by {OpenStackPreviousInstaller}.
+* External {Ceph} cluster: Edge sites connect to pre-existing {CephCluster} clusters not managed by {OpenStackPreviousInstaller}.
+
+Central site {Ceph} migration:: For the central site, migrate {Ceph} daemons from the {OpenStackShort} Controller nodes by using the same process as a non-DCN deployment. For more information, see xref:ceph-daemon-cardinality_migrating-ceph[{Ceph} daemon cardinality].
+
+Edge site {Ceph} migration:: For edge sites that use HCI or {OpenStackPreviousInstaller}-deployed dedicated storage, the {Ceph} daemons can continue to run on their current nodes without migration. The Compute nodes or dedicated storage nodes at edge sites are not decommissioned during adoption, so the {Ceph} daemons remain operational.
++
+For edge sites that use external {Ceph} clusters, no migration is required because the {CephCluster} cluster is not managed by {OpenStackPreviousInstaller}.
+
+{Ceph} back-end configuration and key distribution:: In a DCN deployment, each site has its own {CephCluster} cluster with its own configuration file and {Ceph} keyring. These must be stored in Kubernetes secrets and mounted into the appropriate {rhos_long} service pods.
++
+Rather than storing all {Ceph} keys in a single secret accessible to every pod, the recommended approach is to create one secret per site containing only the keys that site actually needs. This limits the security impact if a site is compromised: a pod at an edge site can authenticate only to its local {CephCluster} cluster and the central cluster, not to the {Ceph} keyrings of other edge sites.
++
+The key distribution rule for N sites is:
++
+* The central site (site 0) receives the {Ceph} keys and configuration for all clusters, because central services such as {image_service} use the `split` back end and must be able to copy images to and from any site.
+* Each edge site (site 1 through N) receives only the keys for the central cluster and its own local cluster.
++
+For example, in a three-site deployment with a central site and two edge sites:
++
+----
+ceph-conf-central  ->  central.conf + central.keyring
+                       dcn1.conf    + dcn1.keyring
+                       dcn2.conf    + dcn2.keyring
+
+ceph-conf-dcn1     ->  central.conf + central.keyring
+                       dcn1.conf    + dcn1.keyring
+
+ceph-conf-dcn2     ->  central.conf + central.keyring
+                       dcn2.conf    + dcn2.keyring
+----
++
+The per-site secrets are created and then mounted into the appropriate pods using `extraMounts` propagation labels. The procedure in xref:configuring-a-ceph-backend_migrating-databases[Configuring a {Ceph} back end] covers both creating the secrets and applying the propagation labels so that each pod receives only its site-specific keys.
diff --git a/docs_user/modules/proc_adopting-compute-services-to-the-data-plane.adoc b/docs_user/modules/proc_adopting-compute-services-to-the-data-plane.adoc
@@ -264,6 +264,12 @@ EOF
 [NOTE]
 For {Ceph} environments with multi-cell configurations, you must name configuration maps and {rhos_prev_long} data plane services similar to the following examples: `nova-custom-ceph-cellX` and `nova-compute-extraconfig-cellX`.
 
++
+[NOTE]
+====
+For Distributed Compute Node (DCN) deployments, do not use the single `nova-cells-global-config` ConfigMap. Create a per-site `ConfigMap` and per-site `OpenStackDataPlaneService` for each site in your DCN deployment. Each site's {compute_service} nodes require a different {Ceph} configuration and a different {image_service} endpoint. For more information, see xref:adopting-compute-services-with-dcn-backend_{context}[Adopting Compute services with multiple Ceph back ends (DCN)].
+====
+
 . Create the data plane services for {compute_service} cells to enable pre-upgrade workarounds, and to configure the Compute services for your chosen storage back end:
 +
 [subs="+quotes"]

diff --git a/docs_user/modules/proc_adopting-the-block-storage-service.adoc b/docs_user/modules/proc_adopting-the-block-storage-service.adoc
@@ -359,3 +359,7 @@ $ openstack --os-volume-api-version 3.47 volume create --backup <backup_name>
 +
 [NOTE]
 You do not boot a {compute_service_first_ref} instance by using the new `volume from` image or try to detach the previous volume because the {compute_service} and the {block_storage} are still not connected.
+
+.Additional resources
+
+* xref:adopting-block-storage-service-with-dcn-backend_{context}[Adopting the {block_storage} with multiple {Ceph} back ends (DCN)].
diff --git a/docs_user/modules/proc_configuring-a-ceph-backend.adoc b/docs_user/modules/proc_configuring-a-ceph-backend.adoc
@@ -74,10 +74,63 @@ stringData:
     mon_host = 10.1.1.2,10.1.1.3,10.1.1.4
 ----
 +
-* `mon_host` specifies the addresses of the cluster's monitors. If you use IPv6, use brackets for the `mon_host`. For example:
-`mon_host = [v2:[fd00:cccc::100]:3300/0,v1:[fd00:cccc::100]:6789/0]`
+where:
++
+`mon_host`:: specifies the addresses of the cluster's monitors. If you use IPv6, use brackets for the `mon_host`. For example: `mon_host = [v2:[fd00:cccc::100]:3300/0,v1:[fd00:cccc::100]:6789/0]`
++
+[NOTE]
+====
+For Distributed Compute Node (DCN) deployments with multiple {Ceph} clusters, create one secret per site. Each secret contains only the keys that the respective site requires. For more information on the rationale and key distribution pattern, see xref:ceph-migration-dcn_{context}[{Ceph} migration for Distributed Compute Node deployments].
+
+The {Ceph} configuration files for all clusters are available on the {OpenStackShort} controller at either `/var/lib/tripleo-config/ceph/`, or `/etc/ceph`. Copy them locally and create the per-site secrets:
+
+----
+$ CEPH_SSH="ssh root@<controller>"
+$ CEPH_DIR="/var/lib/tripleo-config/ceph"
+$ TMPDIR=$(mktemp -d)
+
+$ $CEPH_SSH "cat ${CEPH_DIR}/central.conf" > ${TMPDIR}/central.conf
+$ $CEPH_SSH "sudo cat ${CEPH_DIR}/central.client.openstack.keyring" > ${TMPDIR}/central.client.openstack.keyring
+$ $CEPH_SSH "cat ${CEPH_DIR}/dcn1.conf" > ${TMPDIR}/dcn1.conf
+$ $CEPH_SSH "sudo cat ${CEPH_DIR}/dcn1.client.openstack.keyring" > ${TMPDIR}/dcn1.client.openstack.keyring
+$ $CEPH_SSH "cat ${CEPH_DIR}/dcn2.conf" > ${TMPDIR}/dcn2.conf
+$ $CEPH_SSH "sudo cat ${CEPH_DIR}/dcn2.client.openstack.keyring" > ${TMPDIR}/dcn2.client.openstack.keyring
+
+# Central site secret: contains all clusters
+$ oc create secret generic ceph-conf-central \
+    --from-file=${TMPDIR}/central.conf \
+    --from-file=${TMPDIR}/central.client.openstack.keyring \
+    --from-file=${TMPDIR}/dcn1.conf \
+    --from-file=${TMPDIR}/dcn1.client.openstack.keyring \
+    --from-file=${TMPDIR}/dcn2.conf \
+    --from-file=${TMPDIR}/dcn2.client.openstack.keyring \
+    -n openstack
+
+# DCN1 edge site secret: central + local only
+$ oc create secret generic ceph-conf-dcn1 \
+    --from-file=${TMPDIR}/central.conf \
+    --from-file=${TMPDIR}/central.client.openstack.keyring \
+    --from-file=${TMPDIR}/dcn1.conf \
+    --from-file=${TMPDIR}/dcn1.client.openstack.keyring \
+    -n openstack
+
+# DCN2 edge site secret: central + local only
+$ oc create secret generic ceph-conf-dcn2 \
+    --from-file=${TMPDIR}/central.conf \
+    --from-file=${TMPDIR}/central.client.openstack.keyring \
+    --from-file=${TMPDIR}/dcn2.conf \
+    --from-file=${TMPDIR}/dcn2.client.openstack.keyring \
+    -n openstack
+
+$ rm -rf ${TMPDIR}
+----
 
-. In your `OpenStackControlPlane` CR, inject `ceph.conf` and `ceph.client.openstack.keyring` to the {OpenStackShort} services that are defined in the propagation list. For example:
+Repeat for each additional edge site. Each edge site secret must include the central cluster files and only the files for that edge site's local cluster.
+
+When configuring `extraMounts` on the `OpenStackControlPlane`, use propagation labels matching the service instance names (for example, `central`, `dcn1`, `dcn2`) so that each pod mounts only its site-specific secret.
+====
+
+. In your `OpenStackControlPlane` CR, inject the {Ceph} configuration into the {OpenStackShort} service pods using `extraMounts`. For a single-cluster deployment, propagate one secret to all services:
 +
 ----
 $ oc patch openstackcontrolplane openstack --type=merge --patch '
@@ -104,3 +157,58 @@ spec:
             readOnly: true
 '
 ----
++
+For a DCN deployment with per-site secrets, use propagation labels matching each service instance name so that each pod receives only the keys for its site:
++
+----
+$ oc patch openstackcontrolplane openstack --type=merge --patch '
+spec:
+  extraMounts:
+  - name: v1
+    region: r1
+    extraVol:
+    - extraVolType: Ceph
+      propagation:
+      - central
+      - CinderBackup
+      - ManilaShare
+      volumes:
+      - name: ceph-central
+        projected:
+          sources:
+          - secret:
+              name: ceph-conf-central
+      mounts:
+      - name: ceph-central
+        mountPath: "/etc/ceph"
+        readOnly: true
+    - extraVolType: Ceph
+      propagation:
+      - dcn1
+      volumes:
+      - name: ceph-dcn1
+        projected:
+          sources:
+          - secret:
+              name: ceph-conf-dcn1
+      mounts:
+      - name: ceph-dcn1
+        mountPath: "/etc/ceph"
+        readOnly: true
+    - extraVolType: Ceph
+      propagation:
+      - dcn2
+      volumes:
+      - name: ceph-dcn2
+        projected:
+          sources:
+          - secret:
+              name: ceph-conf-dcn2
+      mounts:
+      - name: ceph-dcn2
+        mountPath: "/etc/ceph"
+        readOnly: true
+'
+----
++
+The propagation label `central` matches the {image_service} and {block_storage} pod instances named `central`. The `CinderBackup` and `ManilaShare` labels are service-type propagation and apply to all {block_storage} backup and {rhos_component_storage_file} pods, which run only at the central site. Replace `central`, `dcn1`, and `dcn2` with the instance names used in your deployment.
diff --git a/docs_user/modules/proc_deploying-file-systems-service-control-plane.adoc b/docs_user/modules/proc_deploying-file-systems-service-control-plane.adoc
@@ -6,6 +6,11 @@
 [role="_abstract"]
 Copy the {rhos_component_storage_file_first_ref} configuration from the {rhos_prev_long} ({OpenStackShort}) {rhos_prev_ver} deployment, and then deploy the {rhos_component_storage_file} on the control plane.
 
+[NOTE]
+====
+In a {rhos_prev_long} DCN deployment, the {rhos_component_storage_file} runs only at the central site and is not deployed on edge site Compute nodes. After adoption, {rhos_long} supports deploying the {rhos_component_storage_file} at edge sites if required.
+====
+
 .Prerequisites
 
 * The {rhos_component_storage_file} systemd services such as `api`, `cron`, and `scheduler` are stopped. For more information, see xref:stopping-openstack-services_migrating-databases[Stopping {rhos_prev_long} services].
@@ -114,6 +119,7 @@ __EOF__
 * `share_backend_name` specifies the names of the back ends to use in {rhos_long}. Ensure that the names of the back ends are the same as they were in {OpenStackShort} {rhos_prev_ver}.
 * `networkAttachments` specifies the appropriate storage management network. For example, the `manilaShares` instance with the CephFS back-end driver is connected to the `storage` network.
 * `extraMounts` specifies additional files to add to any of the services. For example, when using {Ceph}, you can add the {rhos_component_storage_file} Ceph user's keyring file as well as the `ceph.conf` configuration file.
+* In a DCN deployment where {Ceph} configuration files are named by cluster (for example, `central.conf` instead of `ceph.conf`), set `cephfs_conf_path` to the path of the configuration file for the cluster hosting the CephFS back end, and set `cephfs_cluster_name` to the corresponding cluster name. For example, `cephfs_conf_path=/etc/ceph/central.conf` and `cephfs_cluster_name=central`. Using `/etc/ceph/ceph.conf` when that file does not exist in the mounted secret will cause the `manila-share` service to fail with a `conf_read_file` error.
 +
 The following example patch file uses CephFS through NFS:
 +

diff --git a/docs_user/modules/proc_stopping-openstack-services.adoc b/docs_user/modules/proc_stopping-openstack-services.adoc
@@ -235,3 +235,154 @@ endif::[]
 ----
 +
 If the status of each service is `OK`, then the services stopped successfully.
+
+. For Distributed Compute Node (DCN) deployments where {image_service}, {block_storage}, and {Ceph} services run on edge Compute nodes, stop the {image_service}, {block_storage}, and etcd services on all edge Compute nodes with the `DistributedComputeHCI` role:
++
+[NOTE]
+====
+The `DistributedComputeHCI` role runs `GlanceApiEdge`, `CinderVolumeEdge`, and `Etcd` services. A minimum of three nodes per site use this role. Skip this step if your DCN deployment does not run these services on edge Compute nodes. The examples in this procedure use hyper-converged (HCI) roles. If your deployment does not use HCI, the same services apply to the `DistributedCompute` role, which runs the same `GlanceApiEdge`, `CinderVolumeEdge`, and `Etcd` services but without Ceph OSD, Ceph Monitor, or Ceph Manager.
+====
++
+.. Define shell variables for your `DistributedComputeHCI` edge Compute nodes:
++
+[subs=+quotes]
+----
+# DCN1 edge site DistributedComputeHCI nodes
+DCN1_HCI0_SSH="ssh -i *<path to SSH key>* root@*<dcn1-hci-0 IP>*"
+DCN1_HCI1_SSH="ssh -i *<path to SSH key>* root@*<dcn1-hci-1 IP>*"
+DCN1_HCI2_SSH="ssh -i *<path to SSH key>* root@*<dcn1-hci-2 IP>*"
+
+# DCN2 edge site DistributedComputeHCI nodes
+DCN2_HCI0_SSH="ssh -i *<path to SSH key>* root@*<dcn2-hci-0 IP>*"
+DCN2_HCI1_SSH="ssh -i *<path to SSH key>* root@*<dcn2-hci-1 IP>*"
+DCN2_HCI2_SSH="ssh -i *<path to SSH key>* root@*<dcn2-hci-2 IP>*"
+----
++
+where:
+
+`<path to SSH key>`::
+Specifies the path to your SSH key for each `DistributedComputeHCI` edge Compute node on each DCN edge site.
+
+`<dcn1-hci-0 IP>`, `<dcn1-hci-1 IP>`, `<dcn1-hci-2 IP>`::
+Specifies the IP address for each `DistributedComputeHCI` edge Compute node within the DCN1 edge site.
+
+`<dcn2-hci-0 IP>`, `<dcn2-hci-1 IP>`, `<dcn2-hci-2 IP>`::
+Specifies the IP address for each `DistributedComputeHCI` edge Compute node within the DCN2 edge site.
++
+.. Stop the storage services on all `DistributedComputeHCI` nodes:
++
+----
+# Services to stop on DistributedComputeHCI edge compute nodes
+DCN_HCI_SERVICES=("tripleo_glance_api_internal.service"
+                   "tripleo_cinder_volume.service"
+                   "tripleo_etcd.service")
+
+# List of all DistributedComputeHCI node SSH commands
+DCN_HCI_NODES=("$DCN1_HCI0_SSH"
+               "$DCN1_HCI1_SSH"
+               "$DCN1_HCI2_SSH"
+               "$DCN2_HCI0_SSH"
+               "$DCN2_HCI1_SSH"
+               "$DCN2_HCI2_SSH")
+
+echo "Stopping storage services on DistributedComputeHCI nodes"
+for node_ssh in "${DCN_HCI_NODES[@]}"; do
+    [ -z "$node_ssh" ] && continue
+    echo "Processing node: $node_ssh"
+    for service in "${DCN_HCI_SERVICES[@]}"; do
+        if $node_ssh sudo systemctl is-active $service 2>/dev/null; then
+            echo "Stopping $service"
+            $node_ssh sudo systemctl stop $service
+        fi
+    done
+done
+
+echo "Checking storage services on DistributedComputeHCI nodes"
+for node_ssh in "${DCN_HCI_NODES[@]}"; do
+    [ -z "$node_ssh" ] && continue
+    for service in "${DCN_HCI_SERVICES[@]}"; do
+        if ! $node_ssh systemctl show $service 2>/dev/null | grep ActiveState=inactive >/dev/null; then
+            echo "ERROR: Service $service still running on $node_ssh"
+        else
+            echo "OK: Service $service is not running on $node_ssh"
+        fi
+    done
+done
+----
++
+[NOTE]
+====
+* On edge sites, the {image_service} runs with the service name `tripleo_glance_api_internal.service`, which is different from the `tripleo_glance_api.service` on the central controller.
+* The {block_storage} volume service (`tripleo_cinder_volume.service`) uses the same service name on both edge sites and the central controller.
+* The etcd service (`tripleo_etcd.service`) is used as a distributed lock manager (DLM) for the {block_storage} volume service running in active/active mode on edge sites.
+====
+
+. If your DCN deployment includes `DistributedComputeHCIScaleOut` nodes, stop the HAProxy service on those nodes:
++
+[NOTE]
+====
+The `DistributedComputeHCIScaleOut` role is used to scale compute and storage capacity beyond the initial three `DistributedComputeHCI` nodes at each site. These nodes run `HAProxyEdge`, which proxies {image_service} requests to the `GlanceApiEdge` instances on `DistributedComputeHCI` nodes. Skip this step if your DCN deployment does not include `DistributedComputeHCIScaleOut` nodes. For non-HCI deployments, the equivalent role is `DistributedComputeScaleOut`, which runs the same `HAProxyEdge` service.
+====
++
+.. Define shell variables for your `DistributedComputeHCIScaleOut` edge Compute nodes:
++
+[subs=+quotes]
+----
+# DCN1 edge site DistributedComputeHCIScaleOut nodes
+DCN1_SCALEOUT0_SSH="ssh -i *<path to SSH key>* root@*<dcn1-scaleout-0 IP>*"
+DCN1_SCALEOUT1_SSH="ssh -i *<path to SSH key>* root@*<dcn1-scaleout-1 IP>*"
+
+# DCN2 edge site DistributedComputeHCIScaleOut nodes
+DCN2_SCALEOUT0_SSH="ssh -i *<path to SSH key>* root@*<dcn2-scaleout-0 IP>*"
+DCN2_SCALEOUT1_SSH="ssh -i *<path to SSH key>* root@*<dcn2-scaleout-1 IP>*"
+----
++
+where:
+
+`<dcn1-scaleout-0 IP>`, `<dcn1-scaleout-1 IP>`::
+Specifies the IP address for each `DistributedComputeHCIScaleOut` node within the DCN1 edge site.
+
+`<dcn2-scaleout-0 IP>`, `<dcn2-scaleout-1 IP>`::
+Specifies the IP address for each `DistributedComputeHCIScaleOut` node within the DCN2 edge site.
++
+.. Stop the services on all `DistributedComputeHCIScaleOut` nodes:
++
+----
+# Services to stop on DistributedComputeHCIScaleOut edge compute nodes
+DCN_SCALEOUT_SERVICES=("tripleo_haproxy_edge.service")
+
+# List of all DistributedComputeHCIScaleOut node SSH commands
+DCN_SCALEOUT_NODES=("$DCN1_SCALEOUT0_SSH"
+                     "$DCN1_SCALEOUT1_SSH"
+                     "$DCN2_SCALEOUT0_SSH"
+                     "$DCN2_SCALEOUT1_SSH")
+
+echo "Stopping services on DistributedComputeHCIScaleOut nodes"
+for node_ssh in "${DCN_SCALEOUT_NODES[@]}"; do
+    [ -z "$node_ssh" ] && continue
+    echo "Processing node: $node_ssh"
+    for service in "${DCN_SCALEOUT_SERVICES[@]}"; do
+        if $node_ssh sudo systemctl is-active $service 2>/dev/null; then
+            echo "Stopping $service"
+            $node_ssh sudo systemctl stop $service
+        fi
+    done
+done
+
+echo "Checking services on DistributedComputeHCIScaleOut nodes"
+for node_ssh in "${DCN_SCALEOUT_NODES[@]}"; do
+    [ -z "$node_ssh" ] && continue
+    for service in "${DCN_SCALEOUT_SERVICES[@]}"; do
+        if ! $node_ssh systemctl show $service 2>/dev/null | grep ActiveState=inactive >/dev/null; then
+            echo "ERROR: Service $service still running on $node_ssh"
+        else
+            echo "OK: Service $service is not running on $node_ssh"
+        fi
+    done
+done
+----
++
+[NOTE]
+====
+* The HAProxy edge service (`tripleo_haproxy_edge.service`) provided a local {image_service} endpoint on `DistributedComputeHCIScaleOut` nodes, proxying requests to the `GlanceApiEdge` instances on `DistributedComputeHCI` nodes. During adoption, {rhocp_long} Kubernetes service endpoints backed by MetalLB replace HAProxy.
+====
Original file line number	Diff line number	Diff line change
Expand Up		@@ -31,6 +31,7 @@ already part of the {CephCluster} cluster.

		Before you begin the migration, complete the tasks in your {rhos_prev_long} {rhos_prev_ver} environment. For more information, see xref:red-hat-ceph-storage-prerequisites_configuring-network[{Ceph} prerequisites].

		include::../modules/con_ceph-migration-dcn.adoc[leveloffset=+1]

		include::../modules/con_ceph-daemon-cardinality.adoc[leveloffset=+1]

Expand Down