openstack-k8s-operators · openshift-merge-bot · Apr 2, 2026 · Mar 31, 2026
diff --git a/docs_user/assemblies/assembly_adopting-the-image-service.adoc b/docs_user/assemblies/assembly_adopting-the-image-service.adoc
@@ -21,7 +21,7 @@ To complete the {image_service} adoption, ensure that your environment meets the
 * You have a Single Node OpenShift or OpenShift Local that is running in the {rhocp_long} cluster.
 * Optional: You can reach an internal/external `Ceph` cluster by both `crc` and {OpenStackPreviousInstaller}.
 
-If you have image quotas in {OpenStackShort} {rhos_prev_ver}, these quotas are transferred to {rhos_long} {rhos_curr_ver} because the image quota system in {rhos_curr_ver} is disabled by default. For more information about enabling image quotas in {rhos_curr_ver}, see link:{defaultURL}/customizing_persistent_storage/assembly_glance-customizing-the-image-service_customizing-cinder#assembly_glance-configuring-quotas_configuring-glance[Configuring image quotas] in _Customizing persistent storage_. If you enable image quotas in {rhos_acro} {rhos_curr_ver}, the new quotas replace the legacy quotas from {OpenStackShort} {rhos_prev_ver}.
+If you have image quotas in {OpenStackShort} {rhos_prev_ver}, these quotas are transferred to {rhos_long} {rhos_curr_ver} because the image quota system in {rhos_curr_ver} is disabled by default. If you enable image quotas in {rhos_acro} {rhos_curr_ver}, the new quotas replace the legacy quotas from {OpenStackShort} {rhos_prev_ver}.
 
 include::../modules/proc_adopting-image-service-with-object-storage-backend.adoc[leveloffset=+1]
 
@@ -35,5 +35,9 @@ include::../modules/proc_adopting-image-service-with-dcn-backend.adoc[leveloffse
 
 include::../modules/proc_verifying-the-image-service-adoption.adoc[leveloffset=+1]
 
+[role="_additional-resources"]
+== Additional resources
+* link:{defaultURL}/customizing_persistent_storage/assembly_glance-customizing-the-image-service_customizing-cinder#assembly_glance-configuring-quotas_configuring-glance[Configuring image quotas]
+
 ifdef::parent-context[:context: {parent-context}]
 ifndef::parent-context[:!context:]
diff --git a/docs_user/assemblies/assembly_configuring-isolated-networks.adoc b/docs_user/assemblies/assembly_configuring-isolated-networks.adoc
@@ -10,11 +10,11 @@ ifdef::context[:parent-context: {context}]
 [role="_abstract"]
 Before you begin replicating your existing VLAN and IPAM configuration in the {rhos_long} environment, you must have the following IP address allocations for the new control plane services:
 
-* 1 IP address for each isolated network on each {rhocp_long} worker node. You configure these IP addresses in the `NodeNetworkConfigurationPolicy` custom resources (CRs) for the {OpenShiftShort} worker nodes. For more information, see xref:configuring-openshift-worker-nodes_isolated-networks[Configuring {OpenShiftShort} worker nodes].
-* 1 IP range for each isolated network for the data plane nodes. You configure these ranges in the `NetConfig` CRs for the data plane nodes. For more information, see xref:configuring-data-plane-nodes_isolated-networks[Configuring data plane nodes].
+* 1 IP address for each isolated network on each {rhocp_long} worker node. You configure these IP addresses in the `NodeNetworkConfigurationPolicy` custom resources (CRs) for the {OpenShiftShort} worker nodes.
+* 1 IP range for each isolated network for the data plane nodes. You configure these ranges in the `NetConfig` CRs for the data plane nodes.
 * 1 IP range for each isolated network for control plane services. These ranges
-enable pod connectivity for isolated networks in the `NetworkAttachmentDefinition` CRs. For more information, see xref:configuring-networking-for-control-plane-services_isolated-networks[Configuring the networking for control plane services].
-* 1 IP range for each isolated network for load balancer IP addresses. These IP ranges define load balancer IP addresses for MetalLB in the `IPAddressPool` CRs. For more information, see xref:configuring-networking-for-control-plane-services_isolated-networks[Configuring the networking for control plane services].
+enable pod connectivity for isolated networks in the `NetworkAttachmentDefinition` CRs.
+* 1 IP range for each isolated network for load balancer IP addresses. These IP ranges define load balancer IP addresses for MetalLB in the `IPAddressPool` CRs.
 
 [NOTE]
 The exact list and configuration of isolated networks in the following procedures should reflect the actual {rhos_prev_long} environment. The number of isolated networks might differ from the examples used in the procedures. The IPAM scheme might also differ. Only the parts of the configuration that are relevant to configuring networks are shown. The values that are used in the following procedures are examples. Use values that are specific to your configuration.
@@ -25,5 +25,11 @@ include::../modules/proc_configuring-networking-for-control-plane-services.adoc[
 
 include::../modules/proc_configuring-data-plane-nodes.adoc[leveloffset=+1]
 
+[role="_additional-resources"]
+== Additional resources
+* xref:configuring-openshift-worker-nodes_isolated-networks[Configuring {OpenShiftShort} worker nodes]
+* xref:configuring-data-plane-nodes_isolated-networks[Configuring data plane nodes]
+* xref:configuring-networking-for-control-plane-services_isolated-networks[Configuring the networking for control plane services]
+
 ifdef::parent-context[:context: {parent-context}]
 ifndef::parent-context[:!context:]
diff --git a/docs_user/assemblies/assembly_configuring-network-for-RHOSO-deployment.adoc b/docs_user/assemblies/assembly_configuring-network-for-RHOSO-deployment.adoc
@@ -20,22 +20,23 @@ Perform the following tasks to incorporate the existing network configuration:
 
 When configuring nodes and services, the general approach is as follows:
 
-* For IPAM, you can either reuse subnet ranges from the existing deployment or, if there is a shortage of free IP addresses in existing subnets, define new ranges for the new control plane services. If you define new ranges, you configure IP routing between the old and new ranges. For more information, see xref:planning-your-ipam-configuration_configuring-network[Planning your IPAM configuration].
-ifeval::["{build_variant}" == "ospdo"]
-For more information about creating networks for a director Operator environment, see link:https://docs.redhat.com/en/documentation/red_hat_openstack_platform/17.1/html-single/deploying_an_overcloud_in_a_red_hat_openshift_container_platform_cluster_with_director_operator/index#proc_creating-an-overcloud-network-with-the-openstacknetconfig-CRD_OSPdO-networks[Creating networks with director Operator] in _Deploying an overcloud in a Red Hat OpenShift Container Platform cluster with director Operator_.
-endif::[]
+* For IPAM, you can either reuse subnet ranges from the existing deployment or, if there is a shortage of free IP addresses in existing subnets, define new ranges for the new control plane services. If you define new ranges, you configure IP routing between the old and new ranges.
 * For VLAN tags, always reuse the configuration from the existing deployment.
 
-[NOTE]
-For more information about the network architecture and configuration, see
-link:{deploying-rhoso}/assembly_preparing-rhoso-networks[Preparing networks for Red Hat OpenStack Services on OpenShift] in _{deploying-rhoso-t}_ and link:{defaultOCPURL}/networking/about-networking[About networking] in _Networking_.
-
-
 include::../modules/proc_retrieving-network-information-from-your-existing-deployment.adoc[leveloffset=+1]
 
 include::../assemblies/assembly_planning-your-ipam-configuration.adoc[leveloffset=+1]
 
 include::../assemblies/assembly_configuring-isolated-networks.adoc[leveloffset=+1]
 
+[role="_additional-resources"]
+== Additional resources
+ifeval::["{build_variant}" == "ospdo"]
+* link:https://docs.redhat.com/en/documentation/red_hat_openstack_platform/17.1/html-single/deploying_an_overcloud_in_a_red_hat_openshift_container_platform_cluster_with_director_operator/index#proc_creating-an-overcloud-network-with-the-openstacknetconfig-CRD_OSPdO-networks[Creating networks with director Operator]
+endif::[]
+* xref:planning-your-ipam-configuration_configuring-network[Planning your IPAM configuration]
+* link:https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/18.0/html/deploying_red_hat_openstack_services_on_openshift/assembly_preparing-rhoso-networks_preparing[Preparing networks for Red Hat OpenStack Services on OpenShift]
+
+
 ifdef::parent-context[:context: {parent-context}]
 ifndef::parent-context[:!context:]
diff --git a/docs_user/assemblies/assembly_migrating-ceph-cluster.adoc b/docs_user/assemblies/assembly_migrating-ceph-cluster.adoc
@@ -29,7 +29,9 @@ Ganesha. To migrate your {CephCluster} cluster, you must decommission the
 Controller nodes and move the {Ceph} daemons to a set of target nodes that are
 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].
+== Prerequisites
+
+* Before you begin the migration, complete the tasks in your {rhos_prev_long} {rhos_prev_ver} environment. For more information, see "{Ceph} prerequisites" in the Adoption overview chapter.
 
 include::../modules/con_ceph-migration-dcn.adoc[leveloffset=+1]
 
@@ -45,5 +47,9 @@ include::assembly_migrating-ceph-rbd.adoc[leveloffset=+1]
 
 include::../modules/proc_migrating-ceph-post.adoc[leveloffset=+1]
 
+[role="_additional-resources"]
+== Additional resources
+* xref:red-hat-ceph-storage-prerequisites_configuring-network[{Ceph} prerequisites]
+
 ifdef::parent-context[:context: {parent-context}]
 ifndef::parent-context[:!context:]
diff --git a/docs_user/assemblies/assembly_migrating-ceph-monitoring-stack.adoc b/docs_user/assemblies/assembly_migrating-ceph-monitoring-stack.adoc
@@ -20,10 +20,16 @@ Ceph Manager. With {OpenStackPreviousInstaller}-deployed {Ceph}, the {Ceph} Dash
 The {Ceph} Dashboard containers are included through `tripleo-container-image-prepare` parameters, and high availability (HA) relies
 on `HAProxy` and `Pacemaker` to be deployed on the {rhos_prev_long} ({OpenStackShort}) environment. For an external {CephCluster} cluster, HA is not supported.
 
-You migrate and relocate the Ceph Monitoring components to free Controller nodes. 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].
+== Prerequisites
+You migrate and relocate the Ceph Monitoring components to free Controller nodes. Before you begin the migration, complete the tasks in your {rhos_prev_long} {rhos_prev_ver} environment. For more information, see "{Ceph} prerequisites" in the "Adoption overview" chapter.
 
 
 include::../assemblies/assembly_migrating-monitoring-stack-to-target-nodes.adoc[leveloffset=+1]
 
+[role="_additional-resources"]
+== Additional resources
+* xref:red-hat-ceph-storage-prerequisites_configuring-network[{Ceph} prerequisites]
+
+
 ifdef::parent-context[:context: {parent-context}]
 ifndef::parent-context[:!context:]
diff --git a/docs_user/assemblies/assembly_migrating-ceph-rbd.adoc b/docs_user/assemblies/assembly_migrating-ceph-rbd.adoc
@@ -14,11 +14,16 @@ 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.
 
-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].
+== 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.
 
 include::../modules/proc_migrating-mgr-from-controller-nodes.adoc[leveloffset=+1]
 
 include::assembly_migrating-mon-from-controller-nodes.adoc[leveloffset=+1]
 
+[role="_additional-resources"]
+== Additional resources
+* xref:red-hat-ceph-storage-prerequisites_configuring-network[{Ceph} prerequisites]
+
 ifdef::parent-context[:context: {parent-context}]
 ifndef::parent-context[:!context:]
diff --git a/docs_user/assemblies/assembly_migrating-ceph-rgw.adoc b/docs_user/assemblies/assembly_migrating-ceph-rgw.adoc
@@ -10,13 +10,19 @@ ifdef::context[:parent-context: {context}]
 [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.
 
-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].
+== 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.
 
 include::../modules/proc_migrating-the-rgw-backends.adoc[leveloffset=+1]
 
 include::../modules/proc_deploying-a-ceph-ingress-daemon.adoc[leveloffset=+1]
 
 include::../modules/proc_updating-the-object-storage-endpoints.adoc[leveloffset=+1]
 
+[role="_additional-resources"]
+== Additional resources
+* xref:red-hat-ceph-storage-prerequisites_configuring-network[{Ceph} prerequisites]
+
 ifdef::parent-context[:context: {parent-context}]
 ifndef::parent-context[:!context:]
diff --git a/docs_user/assemblies/assembly_migrating-mon-from-controller-nodes.adoc b/docs_user/assemblies/assembly_migrating-mon-from-controller-nodes.adoc
@@ -13,11 +13,11 @@ deployed by {OpenStackPreviousInstaller} with a Hyperconverged Infrastructure (H
 
 To migrate the Ceph Monitor daemons, you must perform the following high-level steps:
 
-. xref:configuring-target-nodes-for-ceph-monitor-migration_{context}[Configure the target nodes for Ceph Monitor migration].
-. xref:draining-the-source-node_{context}[Drain the source node].
-. xref:migrating-the-ceph-monitor-ip-address_{context}[Migrate your Ceph Monitor IP addresses to the target nodes].
-. xref:redeploying-a-ceph-monitor-on-the-target-node_{context}[Redeploy the Ceph Monitor on the target node].
-. xref:verifying-the-cluster-after-ceph-mon-migration_{context}[Verify that the {Cephcluster} cluster is healthy].
+. Configure the target nodes for Ceph Monitor migration.
+. Drain the source node
+. Migrate your Ceph Monitor IP addresses to the target nodes
+. Redeploy the Ceph Monitor on the target node
+. Verify that the {Cephcluster} cluster is healthy
 
 Repeat these steps for any additional Controller node that hosts a Ceph Monitor until you migrate all the Ceph Monitor daemons to the target nodes.
 

diff --git a/docs_user/assemblies/assembly_migrating-the-object-storage-service.adoc b/docs_user/assemblies/assembly_migrating-the-object-storage-service.adoc
@@ -10,7 +10,7 @@ ifdef::context[:parent-context: {context}]
 [role="_abstract"]
 If you are using the {rhos_prev_long} {object_storage_first_ref} as an Object Storage service, you must migrate your Object Storage service to {rhos_long_noacro} nodes.
 
-If you are using the Object Storage API of the Ceph Object Gateway (RGW), you can skip this chapter and migrate your Red Hat Ceph Storage cluster. For more information, see xref:ceph-migration_adopt-control-plane[Migrate the {Ceph} cluster]. If you are not planning to migrate Ceph daemons from Controller nodes, you must perform the steps that are described in xref:deploying-a-ceph-ingress-daemon_migrating-ceph-rgw[Deploying a Ceph ingress daemon] and xref:updating-the-object-storage-endpoints_migrating-ceph-rgw[Create or update the Object Storage service endpoints].
+If you are using the Object Storage API of the Ceph Object Gateway (RGW), you can skip this chapter and migrate your Red Hat Ceph Storage cluster. For more information, see "Migrating the {Ceph} cluster". If you are not planning to migrate Ceph daemons from Controller nodes, you must perform the steps that are described in "Deploying a Ceph ingress daemon" and "Create or update the Object Storage service endpoints".
 
 The data migration happens replica by replica. For example, if you have 3 replicas, move them one at a time to ensure that the other 2 replicas are still operational, which enables you to continue to use the {object_storage} during the migration.
 
@@ -22,5 +22,11 @@ include::../modules/proc_migrating-object-storage-data-to-rhoso-nodes.adoc[level
 
 include::../modules/con_troubleshooting-object-storage-migration.adoc[leveloffset=+1]
 
+[role="_additional-resources"]
+== Additional resources
+* xref:ceph-migration_adopt-control-plane[Migrating the {Ceph} cluster]
+* xref:deploying-a-ceph-ingress-daemon_migrating-ceph-rgw[Deploying a Ceph ingress daemon]
+* xref:updating-the-object-storage-endpoints_migrating-ceph-rgw[Create or update the Object Storage service endpoints]
+
 ifdef::parent-context[:context: {parent-context}]
 ifndef::parent-context[:!context:]
diff --git a/docs_user/assemblies/assembly_planning-your-ipam-configuration.adoc b/docs_user/assemblies/assembly_planning-your-ipam-configuration.adoc
@@ -45,13 +45,17 @@ to be deployed, their replica numbers, and the number of {OpenShiftShort} worker
 
 Additional IP addresses might be required in future {OpenStackShort} releases, so you must plan for some extra capacity for each of the allocation pools that are used in the new environment.
 
-After you determine the required IP pool size for the new deployment, you can choose to define new IP address ranges or reuse your existing IP address ranges. Regardless of the scenario, the VLAN tags in the existing deployment are reused in the new deployment. Ensure that the VLAN tags are properly retained in the new configuration. For more information, see xref:configuring-isolated-networks_configuring-network[Configuring isolated networks].
+After you determine the required IP pool size for the new deployment, you can choose to define new IP address ranges or reuse your existing IP address ranges. Regardless of the scenario, the VLAN tags in the existing deployment are reused in the new deployment. Ensure that the VLAN tags are properly retained in the new configuration.
 
 ifeval::["{build_variant}" != "ospdo"]
 include::../modules/proc_using-new-subnet-ranges.adoc[leveloffset=+1]
 endif::[]
 
 include::../modules/proc_reusing-existing-subnet-ranges.adoc[leveloffset=+1]
 
+[role="_additional-resources"]
+== Additional resources
+*  xref:configuring-isolated-networks_configuring-network[Configuring isolated networks]
+
 ifdef::parent-context[:context: {parent-context}]
 ifndef::parent-context[:!context:]
diff --git a/docs_user/assemblies/assembly_red-hat-ceph-storage-prerequisites.adoc b/docs_user/assemblies/assembly_red-hat-ceph-storage-prerequisites.adoc
@@ -8,19 +8,17 @@ ifdef::context[:parent-context: {context}]
 = {Ceph} prerequisites
 
 [role="_abstract"]
-Before you migrate your {Ceph} cluster daemons from your Controller nodes, complete the following tasks in your {rhos_prev_long} {rhos_prev_ver} environment:
+Before you migrate your {Ceph} cluster daemons from your Controller nodes, you must complete the following tasks in your {rhos_prev_long} {rhos_prev_ver} environment to prepare for the {rhos_long} adoption.
 
-* Upgrade your {Ceph} cluster to release {CephVernum}. For more information, see link:https://docs.redhat.com/en/documentation/red_hat_openstack_platform/17.1/html-single/framework_for_upgrades_16.2_to_17.1/index#assembly_ceph-6-to-7_upgrade_post-upgrade-external-ceph[Upgrading Red Hat Ceph Storage 6 to 7] in _Framework for upgrades (16.2 to 17.1)_.
+* Upgrade your {Ceph} cluster to release {CephVernum}. For more information, see "Upgrading Red Hat Ceph Storage 6 to 7" in _Framework for upgrades (16.2 to 17.1)_.
 * Your {Ceph} {CephVernum} deployment is managed by `cephadm`.
 * The undercloud is still available, and the nodes and networks are managed by {OpenStackPreviousInstaller}.
 * If you use an externally deployed {Ceph} cluster, you must recreate a `ceph-nfs` cluster in the target nodes as well as propogate the `StorageNFS` network.
-
-Complete the prerequisites for your specific {Ceph} environment:
-
-* xref:completing-prerequisites-for-migrating-ceph-monitoring-stack_{context}[{Ceph} with monitoring stack components]
-* xref:completing-prerequisites-for-migrating-ceph-rgw_{context}[{Ceph} RGW]
-* xref:completing-prerequisites-for-rbd-migration_{context}[{Ceph} RBD]
-* xref:creating-a-ceph-nfs-cluster_{context}[NFS Ganesha]
+* Complete the prerequisites for your specific {Ceph} environment:
+** {Ceph} with monitoring stack components
+** {Ceph} RGW
+** {Ceph} RBD
+** NFS Ganesha
 
 
 include::../modules/proc_completing-prerequisites-for-migrating-ceph-monitoring-stack.adoc[leveloffset=+1]
@@ -31,5 +29,9 @@ include::../modules/proc_completing-prerequisites-for-migrating-ceph-rbd.adoc[le
 
 include::../modules/proc_creating-a-ceph-nfs-cluster.adoc[leveloffset=+1]
 
+[role="_additional-resources"]
+== Additional resources
+* link:https://docs.redhat.com/en/documentation/red_hat_openstack_platform/17.1/html-single/framework_for_upgrades_16.2_to_17.1/index#assembly_ceph-6-to-7_upgrade_post-upgrade-external-ceph[Upgrading Red Hat Ceph Storage 6 to 7]
+
 ifdef::parent-context[:context: {parent-context}]
 ifndef::parent-context[:!context:]