openstack-k8s-operators · openshift-merge-bot · Apr 2, 2026 · Mar 31, 2026
diff --git a/docs_user/assemblies/assembly_migrating-ceph-cluster.adoc b/docs_user/assemblies/assembly_migrating-ceph-cluster.adoc
@@ -31,9 +31,9 @@ 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/ref_ceph-migration-dcn.adoc[leveloffset=+1]
 
-include::../modules/con_ceph-daemon-cardinality.adoc[leveloffset=+1]
+include::../modules/ref_ceph-daemon-cardinality.adoc[leveloffset=+1]
 
 include::assembly_migrating-ceph-monitoring-stack.adoc[leveloffset=+1]
 

diff --git a/docs_user/assemblies/assembly_red-hat-ceph-storage-prerequisites.adoc b/docs_user/assemblies/assembly_red-hat-ceph-storage-prerequisites.adoc
@@ -27,7 +27,7 @@ include::../modules/proc_completing-prerequisites-for-migrating-ceph-monitoring-
 
 include::../modules/proc_completing-prerequisites-for-migrating-ceph-rgw.adoc[leveloffset=+1]
 
-include::../modules/proc_completing-prerequisites-for-migrating-ceph-rbd.adoc[leveloffset=+1]
+include::../modules/con_completing-prerequisites-for-migrating-ceph-rbd.adoc[leveloffset=+1]
 
 include::../modules/proc_creating-a-ceph-nfs-cluster.adoc[leveloffset=+1]
 

diff --git a/docs_user/assemblies/assembly_rhoso-180-adoption-overview.adoc b/docs_user/assemblies/assembly_rhoso-180-adoption-overview.adoc
@@ -18,11 +18,11 @@ include::../modules/con_adoption-limitations.adoc[leveloffset=+1]
 
 //include::../modules/con_known-issues-adoption.adoc[leveloffset=+1]
 
-include::../modules/con_adoption-prerequisites.adoc[leveloffset=+1]
+include::../modules/ref_adoption-prerequisites.adoc[leveloffset=+1]
 
 include::../modules/con_adoption-guidelines.adoc[leveloffset=+1]
 
-include::../modules/con_adoption-process-overview.adoc[leveloffset=+1]
+include::../modules/ref_adoption-process-overview.adoc[leveloffset=+1]
 
 include::../modules/con_dcn-adoption-overview.adoc[leveloffset=+1]
 

diff --git a/docs_user/assemblies/assembly_storage-requirements.adoc b/docs_user/assemblies/assembly_storage-requirements.adoc
@@ -19,13 +19,13 @@ Before you can deploy the services in {rhos_long}, you must review the storage r
 
 include::../modules/con_storage-driver-certification.adoc[leveloffset=+1]
 
-include::../modules/con_block-storage-service-requirements.adoc[leveloffset=+1]
+include::../modules/ref_block-storage-service-requirements.adoc[leveloffset=+1]
 
 include::../modules/con_block-storage-service-limitations.adoc[leveloffset=+1]
 
-include::../modules/con_openshift-preparation-for-block-storage-adoption.adoc[leveloffset=+1]
+include::../modules/ref_openshift-preparation-for-block-storage-adoption.adoc[leveloffset=+1]
 
-include::../modules/proc_preparing-block-storage-service-by-customizing-configuration.adoc[leveloffset=+1]
+include::../modules/ref_preparing-block-storage-service-by-customizing-configuration.adoc[leveloffset=+1]
 
 include::../modules/con_changes-to-cephFS-via-NFS.adoc[leveloffset=+1]
 

diff --git a/docs_user/modules/con_bare-metal-provisioning-service-configurations.adoc b/docs_user/modules/con_bare-metal-provisioning-service-configurations.adoc
@@ -4,7 +4,7 @@
 = {bare_metal} configurations
 
 [role="_abstract"]
-You configure the {bare_metal_first_ref} by using configuration snippets. For more information about configuring the control plane with the {bare_metal}, see link:{customizing-rhoso}/index[{customizing-rhoso-t}].
+You configure the {bare_metal_first_ref} by using configuration snippets.
 
 Some {bare_metal} configuration is overridden in {OpenStackPreviousInstaller}, for example, PXE Loader file names are often overridden at intermediate layers. You must pay attention to the settings you apply in your {rhos_long} deployment. The `ironic-operator` applies a reasonable working default configuration, but if you override them with your prior configuration, your experience might not be ideal or your new {bare_metal} fails to operate. Similarly, additional configuration might be necessary, for example, if you enable and use additional hardware types in your `ironic.conf` file.
 
@@ -38,3 +38,7 @@ The instances of `kernel_append_params`, formerly `pxe_append_params` in the `[p
 
 [WARNING]
 You cannot migrate hardware types that are set with the `ironic.conf` file `enabled_hardware_types` parameter, and hardware type driver interfaces starting with `staging-` into the adopted configuration.
+
+[role="_additional-resources"]
+.Additional resources
+* link:{customizing-rhoso}/index[{customizing-rhoso-t}]
diff --git a/docs_user/modules/con_block-storage-service-config-generation-helper-tool.adoc b/docs_user/modules/con_block-storage-service-config-generation-helper-tool.adoc
@@ -1,4 +1,4 @@
-:_mod-docs-content-type: CONCEPT
+:_mod-docs-content-type: REFERENCE
 [id="block-storage-configuration-generation-helper-tool_{context}"]
 
 = About the {block_storage} configuration generation helper tool

diff --git a/docs_user/modules/con_changes-to-cephFS-via-NFS.adoc b/docs_user/modules/con_changes-to-cephFS-via-NFS.adoc
@@ -22,4 +22,7 @@ Before you begin the adoption, review the following information to understand th
 
 * While the old `ceph-nfs` service only supported NFS version 4.1 and later, the new clustered NFS service supports NFS protocols 3 and 4.1 and later. Mixing protocol versions with an export results in unintended consequences. You should mount a given share across all clients by using a consistent NFS protocol version.
 
-For more information on setting up a clustered NFS service, see xref:creating-a-ceph-nfs-cluster_ceph-prerequisites[Creating an NFS Ganesha cluster].
+
+[role="_additional-resources"]
+.Additional resources
+* xref:creating-a-ceph-nfs-cluster_ceph-prerequisites[Creating an NFS Ganesha cluster]
diff --git a/...prerequisites-for-migrating-ceph-rbd.adoc → ...prerequisites-for-migrating-ceph-rbd.adoc b/...prerequisites-for-migrating-ceph-rbd.adoc → ...prerequisites-for-migrating-ceph-rbd.adoc
@@ -1,4 +1,4 @@
-:_mod-docs-content-type: PROCEDURE
+:_mod-docs-content-type: CONCEPT
 [id="completing-prerequisites-for-rbd-migration_{context}"]
 
 = Completing prerequisites for a {Ceph} RBD migration
@@ -7,13 +7,12 @@
 Complete the following prerequisites before you begin the {Ceph} Rados Block Device (RBD) migration.
 
 * The target CephStorage or ComputeHCI nodes are configured to have both `storage` and `storage_mgmt` networks. This ensures that you can use both {Ceph} public and cluster networks from the same node. From {rhos_prev_long} {rhos_prev_ver} and later you do not have to run a stack update.
-* NFS Ganesha is migrated from a {OpenStackPreviousInstaller} deployment to `cephadm`. For more information, see xref:creating-a-ceph-nfs-cluster_ceph-prerequisites[Creating an NFS Ganesha
-cluster].
+* NFS Ganesha is migrated from a {OpenStackPreviousInstaller} deployment to `cephadm`. For more information, see "Creating an NFS Ganesha cluster".
 * Ceph Metadata Server, monitoring stack, Ceph Object Gateway, and any other daemon that is deployed on Controller nodes.
 ifeval::["{build}" != "upstream"]
 * The daemons distribution follows the cardinality constraints that are
-described in link:https://access.redhat.com/articles/1548993[Red Hat Ceph
-Storage: Supported configurations].
+described in "Red Hat Ceph
+Storage: Supported configurations".
 endif::[]
 * The {Ceph} cluster is healthy, and the `ceph -s` command returns `HEALTH_OK`.
 * Run `os-net-config` on the bare metal node and configure additional networks:
@@ -57,3 +56,10 @@ $ openstack overcloud node provision \
 7: vlan11    inet 172.16.11.172/24 brd 172.16.11.255 scope global vlan11\       valid_lft forever preferred_lft forever
 8: vlan12    inet 172.16.12.46/24 brd 172.16.12.255 scope global vlan12\       valid_lft forever preferred_lft forever
 ----
+
+[role="_additional-resources"]
+.Additional resources
+ifeval::["{build}" != "upstream"]
+* link:https://access.redhat.com/articles/1548993[Red Hat Ceph Storage: Supported configurations]
+endif::[]
+* xref:creating-a-ceph-nfs-cluster_ceph-prerequisites[Creating an NFS Ganesha cluster]
diff --git a/docs_user/modules/con_fips-support.adoc b/docs_user/modules/con_fips-support.adoc
@@ -10,4 +10,6 @@ There is a major difference with how FIPS was configured in {OpenStackPreviousIn
 
 If your cluster is FIPS enabled, you must deploy a FIPS {rhocp_long} cluster to adopt your {OpenStackShort} {rhos_prev_ver} FIPS control plane.
 
-For more information about enabling FIPS in {OpenShiftShort}, see link:https://docs.openshift.com/container-platform/latest/installing/installing-fips.html[Support for FIPS cryptography] in _OpenShift Container Platform Documentation_.
+[role="_additional-resources"]
+.Additional resources
+* link:https://docs.openshift.com/container-platform/latest/installing/installing-fips.html[Support for FIPS cryptography]
diff --git a/docs_user/modules/con_identity-service-authentication.adoc b/docs_user/modules/con_identity-service-authentication.adoc
@@ -15,4 +15,6 @@ Red Hat does not support customized roles or policies. Syntax errors or misappli
 
 After you adopt a {OpenStackPreviousInstaller}-based OpenStack deployment to a {rhos_long_noacro} deployment, the {identity_service} performs user authentication and authorization by using Secure RBAC (SRBAC). If SRBAC is already enabled, then there is no change to how you perform operations. If SRBAC is disabled, then adopting a {OpenStackPreviousInstaller}-based OpenStack deployment might change how you perform operations due to changes in API access policies.
 
-For more information on SRBAC, see link:{defaultURL}/performing_security_operations/assembly_srbac-in-rhoso_performing-security-services#assembly_srbac-in-rhoso_performing-security-services[Secure role based access control in Red Hat OpenStack Services on OpenShift] in _Performing security operations_.
+[role="_additional-resources"]
+.Additional resources
+* link:{defaultURL}/performing_security_operations/assembly_srbac-in-rhoso_performing-security-services#assembly_srbac-in-rhoso_performing-security-services[Secure role based access control in Red Hat OpenStack Services on OpenShift]
diff --git a/docs_user/modules/con_key-manager-service-support-for-crypto-plugins.adoc b/docs_user/modules/con_key-manager-service-support-for-crypto-plugins.adoc
@@ -1,4 +1,4 @@
-:_mod-docs-content-type: CONCEPT
+:_mod-docs-content-type: REFERENCE
 [id="key-manager-service-support-for-crypto-plug-ins_{context}"]
 
 = Key Manager service support for crypto plug-ins

diff --git a/docs_user/modules/con_post-adoption-tasks.adoc b/docs_user/modules/con_post-adoption-tasks.adoc
@@ -15,9 +15,9 @@ Perform the following post-adoption tasks to ensure that your {rhos_long} enviro
 * Verify that you migrated all services from the Controller nodes, and then power off the nodes. If any services are still running in the Controller nodes, such as Open Virtual Networking (ML2/OVN), {object_storage_first_ref}, or {Ceph}, do not power off the nodes.
 * Optional: Run tempest to verify that the entire adoption process is working correctly.
 
+[role="_additional-resources"]
 .Additional resources
-
 * link:https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/18.0/html/updating_your_environment_to_the_latest_maintenance_release/index[Updating your environment to the latest maintenance release]
 * xref:enabling-high-availability-for-instances_data-plane[Enabling the high availability for Compute instances service]
-* link:https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/18.0/html-single/configuring_security_services/index#assembly_enabling-TLS-on-a-deployed-RHOSO-environment[Enabling TLS on a deployed RHOSO environment] in _Configuring security services_
+* link:https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/18.0/html-single/configuring_security_services/index#assembly_enabling-TLS-on-a-deployed-RHOSO-environment[Enabling TLS on a deployed RHOSO environment]
 * link:https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/18.0/html/validating_and_troubleshooting_the_deployed_cloud/index[Validating and troubleshooting the deployed cloud]
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
@@ -17,8 +17,7 @@ Review the following guidelines for preparing your {rhos_component_storage_file}
 * Ignore the `osapi_share_listen` configuration. In {rhos_long} {rhos_curr_ver}, you rely on {rhocp_long} routes and ingress.
 * Check for policy overrides. In {rhos_acro} {rhos_curr_ver}, the {rhos_component_storage_file} ships with a secure default Role-based access control (RBAC), and overrides might not be necessary.
 ifeval::["{build}" != "downstream"]
-Please review RBAC defaults by using the https://docs.openstack.org/oslo.policy/latest/cli/oslopolicy-policy-generator.html[Oslo policy generator]
-tool.
+Review RBAC defaults by using the Oslo policy generator tool.
 endif::[]
 * If a custom policy is necessary, you must provide it as a `ConfigMap`. The following example spec illustrates how you can set up a `ConfigMap` called `manila-policy` with the contents of a file called `policy.yaml`:
 +
@@ -58,7 +57,7 @@ endif::[]
 section in `manila: template: manilaScheduler`.
 * If you have multiple storage back-end drivers configured with {OpenStackShort} {rhos_prev_ver}, you need to split them up when deploying {rhos_acro} {rhos_curr_ver}. Each storage back-end driver needs to use its own instance of the `manila-share` service.
 * If a storage back-end driver needs a custom container image, find it in the
-link:https://catalog.redhat.com/software/containers/search?gs&q=manila[Red Hat Ecosystem Catalog], and create or modify an `OpenStackVersion` custom resource (CR) to specify the custom image using the same `custom name`.
+Red Hat Ecosystem Catalog, and create or modify an `OpenStackVersion` custom resource (CR) to specify the custom image using the same `custom name`.
 +
 The following example shows a manila spec from the `OpenStackControlPlane` CR that includes multiple storage back-end drivers, where only one is using a custom container image:
 +
@@ -167,3 +166,10 @@ $ oc create secret generic osp-secret-manila-netapp --from-file=~/<secret>
            replicas: 1
     < . . . >
 ----
+
+[role="_additional-resources"]
+.Additional resources
+ifeval::["{build}" != "downstream"]
+* https://docs.openstack.org/oslo.policy/latest/cli/oslopolicy-policy-generator.html[Oslo policy generator]
+endif::[]
+* link:https://catalog.redhat.com/software/containers/search?gs&q=manila[Red Hat Ecosystem Catalog]
diff --git a/docs_user/modules/con_storage-driver-certification.adoc b/docs_user/modules/con_storage-driver-certification.adoc
@@ -4,6 +4,8 @@
 = 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}.
+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.
 
-For information on software certified for use with {rhos_acro} {rhos_curr_ver}, see the link:https://catalog.redhat.com/search?searchType=software&certified_versions=Red%20Hat%20OpenStack%20Services%20on%20OpenShift%2018&p=1[Red Hat Ecosystem Catalog].
+[role="_additional-resources"]
+.Additional resources
+* link:https://catalog.redhat.com/search?searchType=software&certified_versions=Red%20Hat%20OpenStack%20Services%20on%20OpenShift%2018&p=1[Red Hat Ecosystem Catalog]
diff --git a/docs_user/modules/proc_adopting-the-block-storage-service.adoc b/docs_user/modules/proc_adopting-the-block-storage-service.adoc
@@ -362,4 +362,4 @@ You do not boot a {compute_service_first_ref} instance by using the new `volume
 
 .Additional resources
 
-* xref:adopting-block-storage-service-with-dcn-backend_{context}[Adopting the {block_storage} with multiple {Ceph} back ends (DCN)].
+* 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_adopting-the-object-storage-service.adoc b/docs_user/modules/proc_adopting-the-object-storage-service.adoc
@@ -86,7 +86,7 @@ spec:
 * `spec.swift.swiftStorage.storageClass` must match the {rhos_acro} deployment storage class.
 * `metallb.universe.tf/loadBalancerIPs: <172.17.0.80>` specifies the load balancer IP in your environment. If you use IPv6, change the load balancer IP to the load balancer IP in your environment, for example, `metallb.universe.tf/loadBalancerIPs: fd00:bbbb::80`.
 * `spec.swift.swiftProxy.networkAttachments` must match the network attachment for the previous {object_storage} configuration from the {OpenStackShort} deployment.
-
++
 [NOTE]
 If `SwiftEncryptionEnabled: true` was set in {rhos_prev_long}, ensure that `spec.swift.swiftProxy.encryptionEnabled` is set to `true` and that the {key_manager_first_ref} adoption is complete before proceeding.
 

diff --git a/docs_user/modules/proc_resolving-hsm-backend-detection-failures.adoc b/docs_user/modules/proc_resolving-hsm-backend-detection-failures.adoc
@@ -1,7 +1,7 @@
 :_mod-docs-content-type: PROCEDURE
 [id="resolving-HSM-back-end-detection-failures_{context}"]
 
-==  Resolving HSM back-end detection failures
+=  Resolving HSM back-end detection failures
 
 [role="_abstract"]
 If the adoption role cannot detect hardware security module (HSM) configuration in the source environment, you must force the HSM adoption.

diff --git a/docs_user/modules/proc_reusing-existing-subnet-ranges.adoc b/docs_user/modules/proc_reusing-existing-subnet-ranges.adoc
@@ -1,4 +1,4 @@
-:_mod-docs-content-type: PROCEDURE
+:_mod-docs-content-type: CONCEPT
 [id="reusing-existing-subnet-ranges_{context}"]
 
 = Reusing existing subnet ranges
@@ -7,11 +7,16 @@
 You can reuse existing subnet ranges if they have enough IP addresses to allocate to the new control plane services. You configure the new control plane services to use the same subnet as you used in the {rhos_prev_long} ({OpenStackShort}) environment, and configure the allocation pools that are used by the new services to exclude IP addresses that are already allocated to existing cluster nodes. By reusing existing subnets, you avoid additional link local route configuration between the existing and new subnets.
 
 ifeval::["{build_variant}" != "ospdo"]
-If your existing subnets do not have enough IP addresses in the existing subnet ranges for the new control plane services, you must create new subnet ranges. For more information, see xref:using-new-subnet-ranges_{context}[Using new subnet ranges].
+If your existing subnets do not have enough IP addresses in the existing subnet ranges for the new control plane services, you must create new subnet ranges.
 endif::[]
 
 No special routing configuration is required to reuse subnet ranges. However, you must ensure that the IP addresses that are consumed by {OpenStackShort} services do not overlap with the new allocation pools configured for {rhos_long_noacro} control plane services.
 
 If you are especially constrained by the size of the existing subnet, you may
 have to apply elaborate exclusion rules when defining allocation pools for the
-new control plane services. For more information, see xref:configuring-isolated-networks_configuring-network[Configuring isolated networks].
+new control plane services.
+
+[role="_additional-resources"]
+.Additional resources
+* xref:using-new-subnet-ranges_{context}[Using new subnet ranges]
+* xref:configuring-isolated-networks_configuring-network[Configuring isolated networks]
diff --git a/...r/modules/con_adoption-prerequisites.adoc → ...r/modules/ref_adoption-prerequisites.adoc b/...r/modules/con_adoption-prerequisites.adoc → ...r/modules/ref_adoption-prerequisites.adoc
@@ -1,4 +1,4 @@
-:_mod-docs-content-type: CONCEPT
+:_mod-docs-content-type: REFERENCE
 [id="adoption-prerequisites_{context}"]
 
 = Adoption prerequisites

diff --git a/...odules/con_adoption-process-overview.adoc → ...odules/ref_adoption-process-overview.adoc b/...odules/con_adoption-process-overview.adoc → ...odules/ref_adoption-process-overview.adoc
@@ -1,4 +1,4 @@
-:_mod-docs-content-type: CONCEPT
+:_mod-docs-content-type: REFERENCE
 [id="adoption-process-overview_{context}"]
 
 = Adoption process overview

diff --git a/...n_block-storage-service-requirements.adoc → ...f_block-storage-service-requirements.adoc b/...n_block-storage-service-requirements.adoc → ...f_block-storage-service-requirements.adoc
@@ -1,4 +1,4 @@
-:_mod-docs-content-type: CONCEPT
+:_mod-docs-content-type: REFERENCE
 [id="block-storage-requirements_{context}"]
 
 = {block_storage} guidelines

diff --git a/.../modules/con_ceph-daemon-cardinality.adoc → .../modules/ref_ceph-daemon-cardinality.adoc b/.../modules/con_ceph-daemon-cardinality.adoc → .../modules/ref_ceph-daemon-cardinality.adoc
@@ -1,4 +1,4 @@
-:_mod-docs-content-type: CONCEPT
+:_mod-docs-content-type: REFERENCE
 [id="ceph-daemon-cardinality_{context}"]
 
 = {Ceph} daemon cardinality

diff --git a/..._user/modules/con_ceph-migration-dcn.adoc → ..._user/modules/ref_ceph-migration-dcn.adoc b/..._user/modules/con_ceph-migration-dcn.adoc → ..._user/modules/ref_ceph-migration-dcn.adoc
@@ -1,4 +1,4 @@
-:_mod-docs-content-type: CONCEPT
+:_mod-docs-content-type: REFERENCE
 [id="ceph-migration-dcn_{context}"]
 
 = {Ceph} migration for Distributed Compute Node deployments

diff --git a/...eparation-for-block-storage-adoption.adoc → ...eparation-for-block-storage-adoption.adoc b/...eparation-for-block-storage-adoption.adoc → ...eparation-for-block-storage-adoption.adoc
@@ -1,4 +1,4 @@
-:_mod-docs-content-type: CONCEPT
+:_mod-docs-content-type: REFERENCE
 [id="openshift-preparation-for-block-storage-adoption_{context}"]
 
 = {OpenShiftShort} preparation for {block_storage} adoption

diff --git a/...service-by-customizing-configuration.adoc → ...service-by-customizing-configuration.adoc b/...service-by-customizing-configuration.adoc → ...service-by-customizing-configuration.adoc
@@ -1,4 +1,4 @@
-:_mod-docs-content-type: PROCEDURE
+:_mod-docs-content-type: REFERENCE
 [id="preparing-block-storage-by-customizing-configuration_{context}"]
 
 ifeval::["{build}" == "downstream"]
Original file line number	Diff line number	Diff line change
Expand Up		@@ -362,4 +362,4 @@ You do not boot a {compute_service_first_ref} instance by using the new `volume

		.Additional resources

		* xref:adopting-block-storage-service-with-dcn-backend_{context}[Adopting the {block_storage} with multiple {Ceph} back ends (DCN)].
		* xref:adopting-block-storage-service-with-dcn-backend_{context}[Adopting the {block_storage} with multiple {Ceph} back ends (DCN)]