openstack-k8s-operators · openshift-merge-bot · Jun 30, 2026 · Jun 23, 2026
diff --git a/docs_user/assemblies/assembly_adopting-key-manager-service-with-hsm.adoc b/docs_user/assemblies/assembly_adopting-key-manager-service-with-hsm.adoc
@@ -8,7 +8,7 @@ ifdef::context[:parent-context: {context}]
 = Adopting the {key_manager} with HSM integration
 
 [role="_abstract"]
-Adopt the {key_manager_first_ref} from {OpenStackPreviousInstaller} to {rhos_long} when your source environment includes hardware security module (HSM) integration to preserve HSM functionality and maintain access to HSM-backed secrets. HSM provides enhanced security for cryptographic operations by storing encryption keys in dedicated hardware devices.
+Adopt the {key_manager_first_ref} with HSM integration to {rhos_long} to preserve HSM functionality and maintain access to HSM-backed secrets.
 
 For additional information about the {key_manager} before you start the adoption, see the following resources:
 

diff --git a/docs_user/assemblies/assembly_adopting-the-shared-file-systems-service.adoc b/docs_user/assemblies/assembly_adopting-the-shared-file-systems-service.adoc
@@ -8,9 +8,9 @@ ifdef::context[:parent-context: {context}]
 = Adopting the {rhos_component_storage_file}
 
 [role="_abstract"]
-The {rhos_component_storage_file_first_ref} in {rhos_long} provides a self-service API to create and manage file shares. File shares (or "shares"), are built for concurrent read/write access from multiple clients. This makes the {rhos_component_storage_file} essential in cloud environments that require a ReadWriteMany persistent storage.
+The {rhos_component_storage_file_first_ref} provides a self-service API to create and manage file shares. File shares are built for concurrent read/write access from multiple clients, making the Shared File Systems service in cloud environments that require a ReadWriteMany persistent storage.
 
-File shares in {rhos_acro} require network access. Ensure that the networking in the {rhos_prev_long} ({OpenStackShort}) {rhos_prev_ver} environment matches the network plans for your new cloud after adoption. This ensures that tenant workloads remain connected to storage during the adoption process. The {rhos_component_storage_file} control plane services are not in the data path. Shutting down the API, scheduler, and share manager services do not impact access to existing shared file systems.
+File shares in {rhos_acro} require network access. Ensure that network plans match the {rhos_prev_long} environment to maintain tenant connectivity during adoption. The {rhos_component_storage_file} control plane services are not in the data path. Shutting down the API, scheduler, and share manager services do not impact access to existing shared file systems.
 
 Typically, storage and storage device management are separate networks. Shared File Systems services only need access to the storage device management network.
 For example, if you used a {CephCluster} cluster in the deployment, the "storage"

diff --git a/docs_user/assemblies/assembly_migrating-ceph-rbd.adoc b/docs_user/assemblies/assembly_migrating-ceph-rbd.adoc
@@ -9,10 +9,9 @@ ifdef::context[:parent-context: {context}]
 
 [role="_abstract"]
 For Hyperconverged Infrastructure (HCI) or dedicated Storage nodes that are
-running {Ceph} {CephVernum} or later, you must migrate the daemons that are
-included in the {rhos_prev_long} control plane into the existing external Red
-Hat Enterprise Linux (RHEL) nodes. The external RHEL nodes typically include
-the Compute nodes for an HCI environment or dedicated storage nodes.
+running {Ceph} {CephVernum} or later, migrate the daemons from the {rhos_prev_long} control plane into the existing external Red Hat Enterprise Linux (RHEL) nodes.
+
+The external RHEL nodes typically include the Compute nodes for an HCI environment or dedicated storage nodes.
 
 == Prerequisites
 Before you begin the migration, complete the tasks in your {rhos_prev_long} {rhos_prev_ver} environment. For more information, see the "{Ceph} prerequisites" in the "Adoption overview" chapter.

diff --git a/docs_user/assemblies/assembly_migrating-ceph-rgw.adoc b/docs_user/assemblies/assembly_migrating-ceph-rgw.adoc
@@ -8,7 +8,9 @@ ifdef::context[:parent-context: {context}]
 = Migrating {Ceph} RGW to external RHEL nodes
 
 [role="_abstract"]
-For Hyperconverged Infrastructure (HCI) or dedicated Storage nodes, you must migrate the Ceph Object Gateway (RGW) daemons that are included in the {rhos_prev_long} Controller nodes into the existing external Red Hat Enterprise Linux (RHEL) nodes. The external RHEL nodes typically include the Compute nodes for an HCI environment or {Ceph} nodes. Your environment must have {Ceph} {CephVernum} or later and be managed by `cephadm` or Ceph Orchestrator.
+For Hyperconverged Infrastructure (HCI) or dedicated Storage nodes, migrate the Ceph Object Gateway (RGW) daemons from the {rhos_prev_long} Controller nodes into the existing external Red Hat Enterprise Linux (RHEL) nodes.
+
+The RHEL nodes include the Compute nodes for an HCI environment or {Ceph} nodes. Your environment must have {Ceph} {CephVernum} or later and be managed by `cephadm` or Ceph Orchestrator.
 
 == Prerequisites
 

diff --git a/docs_user/assemblies/assembly_migrating-mon-from-controller-nodes.adoc b/docs_user/assemblies/assembly_migrating-mon-from-controller-nodes.adoc
@@ -8,8 +8,9 @@ ifdef::context[:parent-context: {context}]
 :context: migrating-ceph-mon
 
 [role="_abstract"]
-You must move Ceph Monitor daemons from the {rhos_prev_long} ({OpenStackShort}) Controller nodes to a set of target nodes. Target nodes are either existing {Ceph} nodes, or {OpenStackShort} Compute nodes if {Ceph} is
-deployed by {OpenStackPreviousInstaller} with a Hyperconverged Infrastructure (HCI) topology. Additional Ceph Monitors are deployed to the target nodes, and they are promoted as `_admin` nodes that you can use to manage the {CephCluster} cluster and perform day 2 operations.
+Move Ceph Monitor daemons from the {rhos_prev_long} ({OpenStackShort}) Controller nodes to a set of existing {Ceph} nodes, or to a set of {OpenStackShort} Compute nodes if {Ceph} is deployed by {OpenStackPreviousInstaller} with a Hyperconverged Infrastructure (HCI) topology.
+
+Additional Ceph Monitors are deployed to the target nodes and promoted as _admin nodes to manage the {CephCluster} cluster and perform day 2 operations.
 
 To migrate the Ceph Monitor daemons, you must perform the following high-level steps:
 

diff --git a/docs_user/assemblies/assembly_rhoso-180-adoption-overview.adoc b/docs_user/assemblies/assembly_rhoso-180-adoption-overview.adoc
@@ -8,7 +8,9 @@ ifdef::context[:parent-context: {context}]
 = {rhos_long_noacro} {rhos_curr_ver} adoption overview
 
 [role="_abstract"]
-Adoption is the process of migrating a {rhos_prev_long} ({OpenStackShort}) {rhos_prev_ver} control plane to {rhos_long_noacro} {rhos_curr_ver}, and then completing an in-place upgrade of the data plane. You can retain existing infrastructure investments and modernize your {OpenStackShort} deployment on a containerized {rhocp_long} foundation. To ensure that you understand the entire adoption process and how to sufficiently prepare your {OpenStackShort} environment, review the prerequisites, adoption process, and post-adoption tasks.
+Adoption is the process of migrating a {rhos_prev_long} {rhos_prev_ver} control plane to {rhos_long_noacro} {rhos_curr_ver} and upgrading the data plane in-place. Retain existing infrastructure investments and modernize your {OpenStackShort} deployment on a containerized {rhocp_long} foundation.
+
+To understand the adoption process and to prepare your {OpenStackShort} environment, review the prerequisites, adoption process, and post-adoption tasks.
 
 [IMPORTANT]
 Read the whole adoption guide before you start

diff --git a/docs_user/modules/con_adopting-spine-leaf-networks.adoc b/docs_user/modules/con_adopting-spine-leaf-networks.adoc
@@ -4,9 +4,9 @@
 = Configuring spine-leaf networks for the {rhos_long_noacro} deployment
 
 [role="_abstract"]
-When you adopt a {rhos_prev_long} ({OpenStackShort}) deployment with spine-leaf networking, like a Distributed Compute Node (DCN) architecture, you must each L2 network segment with a separate IP subnet and create create routed provider networks. Traffic between sites is routed at L3 through spine routers or similar network infrastructure.
+When you adopt a {rhos_prev_long} ({OpenStackShort}) deployment with spine-leaf networking, such as a Distributed Compute Node (DCN) architecture, adopt each L2 network segment with a separate IP subnet and create routed provider networks.
 
-You must configure routing for Compute nodes at edge sites to connect with control plane services, such as RabbitMQ or the database at the central site. The cloud will not function correctly without routes configured.
+Traffic between sites is routed at L3 through spine routers or similar network infrastructure. You must configure routing for Compute nodes at edge sites to connect with control plane services, such as RabbitMQ or the database at the central site. The cloud will not function correctly without routes configured.
 
 [NOTE]
 ====

diff --git a/docs_user/modules/con_adoption-guidelines.adoc b/docs_user/modules/con_adoption-guidelines.adoc
@@ -4,7 +4,7 @@
 = Guidelines for planning the adoption
 
 [role="_abstract"]
-When planning to adopt a {rhos_long} {rhos_curr_ver} environment, consider the scope of the change. An adoption is similar in scope to a data center upgrade. Different firmware levels, hardware vendors, hardware profiles, networking interfaces, storage interfaces, and so on affect the adoption process and can cause changes in behavior during the adoption.
+Adoption is similar in scope to a data center upgrade. Different firmware levels, hardware vendors, hardware profiles, networking interfaces, and storage interfaces can affect the adoption process and change behavior.
 
 Review the following guidelines to adequately plan for the adoption and increase the chance that you complete the adoption successfully:
 

diff --git a/docs_user/modules/con_preparing-the-shared-file-systems-service-configuration.adoc b/docs_user/modules/con_preparing-the-shared-file-systems-service-configuration.adoc
@@ -4,7 +4,7 @@
 = Guidelines for preparing the {rhos_component_storage_file} configuration
 
 [role="_abstract"]
-To deploy {rhos_component_storage_file_first_ref} on the control plane, you must copy the original configuration file from the {rhos_prev_long} {rhos_prev_ver} deployment. You must review the content in the file to make sure you are adopting the correct configuration for {rhos_long} {rhos_curr_ver}. Not all of the content needs to be brought into the new cloud environment.
+Copy the {rhos_component_storage_file_first_ref} configuration from {rhos_prev_long} {rhos_prev_ver}, and review it to ensure that you copy the correct configuration for {rhos_long} {rhos_curr_ver}.
 
 Review the following guidelines for preparing your {rhos_component_storage_file} configuration file for adoption:
 

diff --git a/docs_user/modules/con_preventing-config-loss-when-using-oc-patch.adoc b/docs_user/modules/con_preventing-config-loss-when-using-oc-patch.adoc
@@ -4,9 +4,9 @@
 = Preventing configuration loss when using the `oc patch` command
 
 [role="_abstract"]
-When you use the `oc patch` command to modify a resource, the changes are applied directly to the live object in your OpenShift cluster. If you later edit the custom resource (CR) file for the resource and apply the updates by using `oc apply -f <filename>`, your previous patched changes are overwritten and lost from the resource.
+When you use `oc patch` to modify a resource, the changes are applied directly to live objects in your OpenShift cluster. If you later apply updates to the custom resource (CR) file by using `oc apply -f <filename>`, your previous patched changes are overwritten and lost from the resource.
 
-To prevent loss of configuration, you can use the `--patch-file` option to configure the patch and retain patch files. Alternatively, you can export your `openstackcontrolplane` CR after the patch is applied:
+To prevent configuration loss, use the `--patch-file` option or export your `openstackcontrolplane` CR after the patch is applied.
 
 ----
 $ oc get <resource_type> <resource_name> -o yaml > <filename>.yaml

diff --git a/docs_user/modules/con_storage-driver-certification.adoc b/docs_user/modules/con_storage-driver-certification.adoc
@@ -4,7 +4,7 @@
 = Storage driver certification
 
 [role="_abstract"]
-Before you adopt your {rhos_prev_long} {rhos_prev_ver} deployment to a {rhos_long} {rhos_curr_ver} deployment, confirm that your deployed storage drivers are certified for use with {rhos_acro} {rhos_curr_ver}. For information on software certified for use with {rhos_acro} {rhos_curr_ver}, see the Red Hat Ecosystem Catalog.
+Confirm that your deployed storage drivers are certified for {rhos_acro} {rhos_curr_ver} before adoption. See the Red Hat Ecosystem Catalog for certified software.
 
 [role="_additional-resources"]
 .Additional resources

diff --git a/docs_user/modules/proc_adopting-block-storage-service-with-dcn-backend.adoc b/docs_user/modules/proc_adopting-block-storage-service-with-dcn-backend.adoc
@@ -4,7 +4,7 @@
 = Adopt the {block_storage} with multiple {Ceph} back ends (DCN)
 
 [role="_abstract"]
-Adopt the {block_storage_first_ref} in a Distributed Compute Node (DCN) deployment where multiple {CephCluster} clusters provide storage at different sites. You can deploy multiple `CinderVolume` instances, one for each availability zone, with each volume service configured to use its local {Ceph} cluster.
+Adopt the {block_storage_first_ref} in a Distributed Compute Node (DCN) deployment with multiple {CephCluster} clusters at different sites. Deploy multiple `CinderVolume` instances, one for each availability zone, with each volume service configured to use its local {Ceph} cluster.
 
 During adoption, the {block_storage} volume services that ran on edge site Compute nodes are migrated to run on {rhocp_long} at the central site. Although the control path for API requests now traverses the WAN to reach the {block_storage} running on {rhocp_long}, the data path remains local. Volume data continues to be stored in the {Ceph} cluster at each edge site. When you create a volume or clone a volume from a snapshot, the operation occurs entirely within the local {Ceph} cluster. This preserves data locality.
 

diff --git a/docs_user/modules/proc_adopting-compute-services-with-dcn-backend.adoc b/docs_user/modules/proc_adopting-compute-services-with-dcn-backend.adoc
@@ -4,7 +4,9 @@
 = Adopting Compute services with multiple {Ceph} back ends (DCN)
 
 [role="_abstract"]
-In a Distributed Compute Node (DCN) deployment where {image_service_first_ref} and {block_storage_first_ref} services run on edge Compute nodes, each site has its own {CephCluster} cluster. The {compute_service_first_ref} nodes at each site must be configured with the {Ceph} connection details and {image_service} endpoint for their local site. Because the {image_service} has a separate API endpoint at each site, each site's `OpenStackDataPlaneNodeSet` custom resource (CR) must use a different `OpenStackDataPlaneService` CR that points to the correct {image_service}.
+Configure the edge {compute_service_first_ref} nodes at each site with the {Ceph} connection details and {image_service_first_ref} endpoint for their local site.
+
+In a Distributed Compute Node (DCN) deployment where {image_service} and {block_storage_first_ref} services run on edge Compute nodes, each site has its own {CephCluster} cluster. The {image_service} has a separate API endpoint at each site. Each site's `OpenStackDataPlaneNodeSet` custom resource (CR) must use a different `OpenStackDataPlaneService` CR that points to the correct {image_service}.
 
 In a DCN deployment, all node sets belong to a single {compute_service} cell. The central site and each edge site are separate `OpenStackDataPlaneNodeSet` resources within that cell. The per-site `OpenStackDataPlaneService` resources deliver different {Ceph} and {image_service} configurations to each node set while sharing the same cell-level {compute_service} configuration.
 

diff --git a/docs_user/modules/proc_adopting-image-service-with-block-storage-backend.adoc b/docs_user/modules/proc_adopting-image-service-with-block-storage-backend.adoc
@@ -4,7 +4,7 @@
 = Adopting the {image_service} that is deployed with a {block_storage} back end
 
 [role="_abstract"]
-Adopt the {image_service_first_ref} that you deployed with a {block_storage_first_ref} back end in the {rhos_prev_long} ({OpenStackShort}) environment. The control plane `glanceAPI` instance is deployed with the following configuration. You use this configuration in the patch manifest that deploys the {image_service} with the block storage back end:
+Adopt the {image_service_first_ref} with a {block_storage_first_ref} back end by using the following configuration from the control plane `glanceAPI` instance. Use this configuration in the patch manifest that deploys the {image_service} with the block storage back end.
 
 ----
 ..

diff --git a/docs_user/modules/proc_adopting-image-service-with-dcn-backend.adoc b/docs_user/modules/proc_adopting-image-service-with-dcn-backend.adoc
@@ -4,7 +4,9 @@
 = Adopting the {image_service} with multiple {Ceph} back ends (DCN)
 
 [role="_abstract"]
-Adopt the {image_service_first_ref} in a Distributed Compute Node (DCN) deployment where multiple {CephCluster} clusters provide storage at different sites. This configuration deploys multiple `GlanceAPI` instances: a central API with access to all {Ceph} clusters, and edge APIs at each DCN site with access to their local cluster and the central cluster.
+Adopt the {image_service_first_ref} in a Distributed Compute Node (DCN) deployment with multiple {CephCluster} clusters that provide storage at different sites.
+
+This configuration deploys multiple `GlanceAPI` instances: a central API with access to all {Ceph} clusters, and edge APIs at each DCN site with access to their local cluster and the central cluster.
 
 During adoption, the {image_service} instances that ran on edge site Compute nodes are migrated to run on {rhocp_long} at the central site. Although the control path for API requests now traverses the WAN to reach the {image_service} running on {rhocp_long}, the data path remains local. Image data continues to be stored in the {Ceph} cluster at each edge site. When you create a virtual machine or volume from an image, the operation occurs at the local {Ceph} cluster. This architecture uses {Ceph} shallow copies (copy-on-write clones) to enable fast boot times without transferring image data across the WAN.
 

diff --git a/docs_user/modules/proc_adopting-image-service-with-object-storage-backend.adoc b/docs_user/modules/proc_adopting-image-service-with-object-storage-backend.adoc
@@ -4,7 +4,7 @@
 = Adopting the {image_service} that is deployed with a {object_storage} back end
 
 [role="_abstract"]
-Adopt the {image_service_first_ref} that you deployed with an {object_storage_first_ref} back end in the {rhos_prev_long} ({OpenStackShort}) environment. The control plane `glanceAPI` instance is deployed with the following configuration. You use this configuration in the patch manifest that deploys the {image_service} with the object storage back end:
+Adopt the {image_service_first_ref} with an {object_storage_first_ref} back end by using the following configuration from the control plane `glanceAPI` instance. Use this configuration in the patch manifest that deploys the {image_service} with the object storage back end.
 
 ----
 ..

diff --git a/docs_user/modules/proc_adopting-key-manager-service-with-proteccio-hsm.adoc b/docs_user/modules/proc_adopting-key-manager-service-with-proteccio-hsm.adoc
@@ -4,7 +4,9 @@
 = Adopting the {key_manager} with Proteccio HSM integration
 
 [role="_abstract"]
-To adopt the {key_manager_first_ref} with Proteccio hardware security module (HSM) integration, you patch an existing `OpenStackControlPlane` custom resource (CR) where {key_manager} is disabled. The patch starts the service with the configuration parameters from the {rhos_prev_long} ({OpenStackShort}) environment and preserves access to existing HSM-backed secrets. You configure the {key_manager} to use both the `simple_crypto` and `pkcs11` back ends.
+Adopt the {key_manager_first_ref} with Proteccio HSM by patching the `OpenStackControlPlane` custom resource (CR) where {key_manager} is disabled. Configure the {key_manager} to use both the `simple_crypto` and `pkcs11` back ends.
+
+The patch starts the service with the configuration parameters from the {rhos_prev_long} ({OpenStackShort}) environment and preserves access to existing HSM-backed secrets.
 
 The {key_manager} Proteccio HSM adoption is complete if you see the following results:
 

diff --git a/docs_user/modules/proc_adopting-key-manager-service.adoc b/docs_user/modules/proc_adopting-key-manager-service.adoc
@@ -4,7 +4,9 @@
 = Adopting the {key_manager}
 
 [role="_abstract"]
-To adopt the {key_manager_first_ref}, you patch an existing `OpenStackControlPlane` custom resource (CR) where {key_manager} is disabled. The patch starts the service with the configuration parameters that are provided by the {rhos_prev_long} ({OpenStackShort}) environment. You configure the {key_manager} to use the `simple_crypto` back end.
+Adopt the {key_manager_first_ref} by patching the existing `OpenStackControlPlane` custom resource (CR) where {key_manager} is disabled. Configure the {key_manager} to use the `simple_crypto` back end.
+
+The patch starts the service with the configuration parameters that are provided by the {rhos_prev_long} ({OpenStackShort}) environment.
 
 The {key_manager} adoption is complete if you see the following results:
 

diff --git a/docs_user/modules/proc_adopting-networker-services-to-the-data-plane.adoc b/docs_user/modules/proc_adopting-networker-services-to-the-data-plane.adoc
@@ -4,7 +4,7 @@
 = Adopting Networker services to the {rhos_acro} data plane
 
 [role="_abstract"]
-Adopt the Networker services in your existing {rhos_prev_long} deployment to the {rhos_long} data plane. The Networker services could be running on Controller nodes or dedicated Networker nodes. You decide which services you want to run on the Networker nodes, and create a separate `OpenStackDataPlaneNodeSet` custom resource (CR) for the Networker nodes.
+Adopt Networker services to the {rhos_long} data plane by creating a `OpenStackDataPlaneNodeSet` custom resource (CR) that includes the services to run on the Networker nodes. The Networker services could be running on Controller nodes or dedicated Networker nodes.
 
 [TIP]
 ====