18.0 fr5 manualcherrypick

docs_user/assemblies/assembly_adopting-key-manager-service-with-hsm.adoc

@@ -10,22 +10,25 @@ ifdef::context[:parent-context: {context}]
 [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.
 
+For additional information about the {key_manager} before you start the adoption, see the following resources:
+
+* {key_manager} service configuration documentation
+* Hardware security module vendor-specific documentation
+* OpenStack Barbican PKCS#11 plugin documentation
+
 include::../modules/con_key-manager-service-hsm-adoption-approaches.adoc[leveloffset=+1]
 
 include::../modules/proc_adopting-key-manager-service-with-proteccio-hsm.adoc[leveloffset=+1]
 
 include::../modules/proc_adopting-key-manager-service-with-hsm-integration.adoc[leveloffset=+1]
 
-include::../modules/ref_troubleshooting-key-manager-hsm-adoption.adoc[leveloffset=+1]
+include::../assemblies/assembly_troubleshooting-key-manager-hsm-adoption.adoc[leveloffset=+1]
 
-include::../modules/ref_troubleshooting-key-manager-proteccio-adoption.adoc[leveloffset=+1]
+include::../assemblies/assembly_troubleshooting-key-manager-proteccio-adoption.adoc[leveloffset=+1]
+
+include::../modules/proc_rolling-back-the-hsm-adoption.adoc[leveloffset=+1]
 
-[role="_additional-resources"]
-== Additional resources
 
-* {key_manager} service configuration documentation
-* Hardware security module vendor-specific documentation
-* OpenStack Barbican PKCS#11 plugin documentation
 
 ifdef::parent-context[:context: {parent-context}]
 ifndef::parent-context[:!context:]

docs_user/assemblies/assembly_adopting-openstack-control-plane-services.adoc

@@ -20,6 +20,8 @@ include::../assemblies/assembly_adopting-key-manager-service-with-hsm.adoc[level
 
 include::../modules/proc_adopting-the-networking-service.adoc[leveloffset=+1]
 
+include::../modules/proc_configuring-control-plane-networking-for-spine-leaf.adoc[leveloffset=+1]
+
 include::../modules/proc_adopting-the-object-storage-service.adoc[leveloffset=+1]
 
 include::../assemblies/assembly_adopting-the-image-service.adoc[leveloffset=+1]
@@ -32,6 +34,8 @@ include::../modules/proc_adopting-the-compute-service.adoc[leveloffset=+1]
 
 include::../modules/proc_adopting-the-block-storage-service.adoc[leveloffset=+1]
 
+include::../modules/proc_adopting-block-storage-service-with-dcn-backend.adoc[leveloffset=+1]
+
 include::../modules/proc_adopting-the-openstack-dashboard.adoc[leveloffset=+1]
 
 include::../assemblies/assembly_adopting-the-shared-file-systems-service.adoc[leveloffset=+1]

docs_user/assemblies/assembly_adopting-the-data-plane.adoc

@@ -24,11 +24,17 @@ include::../modules/proc_stopping-infrastructure-management-and-compute-services
 
 include::../modules/proc_adopting-compute-services-to-the-data-plane.adoc[leveloffset=+1]
 
+include::../modules/proc_configuring-dcn-data-plane-nodesets.adoc[leveloffset=+1]
+
+include::../modules/proc_adopting-compute-services-with-dcn-backend.adoc[leveloffset=+1]
+
 include::../modules/proc_performing-a-fast-forward-upgrade-on-compute-services.adoc[leveloffset=+1]
 
 include::../modules/proc_adopting-networker-services-to-the-data-plane.adoc[leveloffset=+1]
 
 include::../modules/proc_enabling-high-availability-for-instances.adoc[leveloffset=+1]
 
+include::../modules/proc_performing-post-adoption-cleanup-of-load-balancers.adoc[leveloffset=+1]
+
 ifdef::parent-context[:context: {parent-context}]
 ifndef::parent-context[:!context:]

docs_user/assemblies/assembly_adopting-the-image-service.adoc

@@ -31,6 +31,8 @@ include::../modules/proc_adopting-image-service-with-nfs-backend.adoc[leveloffse
 
 include::../modules/proc_adopting-image-service-with-ceph-backend.adoc[leveloffset=+1]
 
+include::../modules/proc_adopting-image-service-with-dcn-backend.adoc[leveloffset=+1]
+
 include::../modules/proc_verifying-the-image-service-adoption.adoc[leveloffset=+1]
 
 ifdef::parent-context[:context: {parent-context}]

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]
 

docs_user/assemblies/assembly_rhoso-180-adoption-overview.adoc

@@ -24,12 +24,16 @@ include::../modules/con_adoption-guidelines.adoc[leveloffset=+1]
 
 include::../modules/con_adoption-process-overview.adoc[leveloffset=+1]
 
+include::../modules/con_dcn-adoption-overview.adoc[leveloffset=+1]
+
 include::../modules/proc_installing-the-systemd-container-package-on-compute-hosts.adoc[leveloffset=+1]
 
 include::../modules/con_identity-service-authentication.adoc[leveloffset=+1]
 
 include::../assemblies/assembly_configuring-network-for-RHOSO-deployment.adoc[leveloffset=+1]
 
+include::../modules/con_adopting-spine-leaf-networks.adoc[leveloffset=+1]
+
 include::../assemblies/assembly_storage-requirements.adoc[leveloffset=+1]
 
 include::../assemblies/assembly_red-hat-ceph-storage-prerequisites.adoc[leveloffset=+1]
@@ -38,5 +42,7 @@ include::../assemblies/assembly_preparing-an-instance-HA-deployment-for-adoption
 
 include::../modules/proc_comparing-configuration-files-between-deployments.adoc[leveloffset=+1]
 
+include::../modules/con_preventing-config-loss-when-using-oc-patch.adoc[leveloffset=+1]
+
 ifdef::parent-context[:context: {parent-context}]
 ifndef::parent-context[:!context:]

docs_user/assemblies/assembly_troubleshooting-key-manager-hsm-adoption.adoc

@@ -0,0 +1,41 @@
+:_mod-docs-content-type: ASSEMBLY
+ifdef::context[:parent-context: {context}]
+
+[id="troubleshooting-key-manager-hsm-adoption_{context}"]
+
+= Troubleshooting Key Manager HSM adoption
+
+:context: troubleshooting-hsm
+
+[role="_abstract"]
+Review troubleshooting guidance for common issues that you might encounter while you perform the HSM-enabled Key Manager (Barbican) service adoption.
+
+If issues persist after following the troubleshooting guide:
+
+* Collect adoption logs and configuration for analysis.
+* Check the HSM vendor documentation for vendor-specific troubleshooting.
+* Verify HSM server status and connectivity independently.
+* Review the adoption summary report for additional diagnostic information.
+
+include::../modules/proc_resolving-config-validation-failures.adoc[leveloffset=+1]
+
+include::../modules/proc_resolving-missing-HSM-file-prerequisites.adoc[leveloffset=+1]
+
+include::../modules/proc_resolving-connectivity-issues.adoc[leveloffset=+1]
+
+include::../modules/proc_resolving-HSM-secret-creation-failures.adoc[leveloffset=+1]
+
+include::../modules/proc_resolving-custom-image-registry-issues.adoc[leveloffset=+1]
+
+include::../modules/proc_resolving-hsm-backend-detection-failures.adoc[leveloffset=+1]
+
+include::../modules/proc_resolving-database-migration-issues.adoc[leveloffset=+1]
+
+include::../modules/proc_resolving-service-startup-failures.adoc[leveloffset=+1]
+
+include::../modules/proc_resolving-performance-and-connectivity-issues.adoc[leveloffset=+1]
+
+
+
+ifdef::parent-context[:context: {parent-context}]
+ifndef::parent-context[:!context:]

docs_user/assemblies/assembly_troubleshooting-key-manager-proteccio-adoption.adoc

@@ -0,0 +1,23 @@
+:_mod-docs-content-type: ASSEMBLY
+ifdef::context[:parent-context: {context}]
+
+[id="troubleshooting-key-manager-proteccio-adoption_{context}"]
+
+:context: troubleshooting-proteccio
+
+= Troubleshooting {key_manager} Proteccio HSM adoption
+
+[role="_abstract"]
+Use this reference to troubleshoot common issues that might occur during {key_manager_first_ref} adoption with Proteccio HSM integration. If Proteccio HSM issues persist, consult the Eviden Trustway documentation and ensure that HSM server configuration matches the client settings.
+
+include::../modules/proc_resolving-prerequisite-validation-failures.adoc[leveloffset=+1]
+include::../modules/proc_resolving-ssh-connection-failures.adoc[leveloffset=+1]
+include::../modules/proc_resolving-database-import-failures.adoc[leveloffset=+1]
+include::../modules/proc_resolving-custom-image-pull-failures.adoc[leveloffset=+1]
+include::../modules/proc_resolving-hsm-certificate-mounting-issues.adoc[leveloffset=+1]
+include::../modules/proc_resolving-service-startup-failures.adoc[leveloffset=+1]
+include::../modules/proc_resolving-adoption-verification-failures.adoc[leveloffset=+1]
+
+
+ifdef::parent-context[:context: {parent-context}]
+ifndef::parent-context[:!context:]

docs_user/main.adoc

@@ -31,3 +31,5 @@ include::assemblies/assembly_adopting-the-data-plane.adoc[leveloffset=+1]
 include::assemblies/assembly_migrating-the-object-storage-service.adoc[leveloffset=+1]
 
 include::assemblies/assembly_migrating-ceph-cluster.adoc[leveloffset=+1]
+
+include::modules/con_post-adoption-tasks.adoc[leveloffset=+1]

docs_user/modules/con_adopting-spine-leaf-networks.adoc

@@ -0,0 +1,123 @@
+:_mod-docs-content-type: CONCEPT
+[id="adopting-spine-leaf-networks_{context}"]
+
+= 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.
+
+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]
+====
+DHCP relay is not supported in adopted {rhos_long} environments with spine-leaf topologies. This affects bare-metal provisioning scenarios that use PXE boot.
+
+If you need to provision bare-metal nodes at edge sites, use Redfish virtual media or similar BMC virtual media features instead of PXE boot.
+====
+
+.Example routes required on DCN1 Compute nodes
+[options="header"]
+|===
+| Destination network | Next hop | Purpose
+| 172.17.0.0/24 | 172.17.10.1 | Route to central internalapi
+| 172.17.20.0/24 | 172.17.10.1 | Route to DCN2 internalapi
+| 172.18.0.0/24 | 172.18.10.1 | Route to central storage
+| 172.18.20.0/24 | 172.18.10.1 | Route to DCN2 storage
+|===
+
+You configure these routes in the `edpm_network_config_template` within the `OpenStackDataPlaneNodeSet` custom resource (CR) for each site.
+
+.Example network topology for a three-site DCN deployment
+[options="header"]
+|===
+| Network | Central site | DCN1 site | DCN2 site
+| Control plane | 192.168.122.0/24 | 192.168.133.0/24 | 192.168.144.0/24
+| Internal API | 172.17.0.0/24 | 172.17.10.0/24 | 172.17.20.0/24
+| Storage | 172.18.0.0/24 | 172.18.10.0/24 | 172.18.20.0/24
+| Tenant | 172.19.0.0/24 | 172.19.10.0/24 | 172.19.20.0/24
+|===
+
+When you adopt a spine-leaf deployment, you configure the `NetConfig` CR with multiple subnets for each service network. Each subnet represents a different site.
+
+.Example NetConfig with multiple subnets per network
+[source,yaml]
+----
+apiVersion: network.openstack.org/v1beta1
+kind: NetConfig
+metadata:
+  name: netconfig
+spec:
+  networks:
+  - name: ctlplane
+    dnsDomain: ctlplane.example.com
+    subnets:
+    - name: subnet1              # Central site
+      allocationRanges:
+      - end: 192.168.122.120
+        start: 192.168.122.100
+      cidr: 192.168.122.0/24
+      gateway: 192.168.122.1
+    - name: ctlplanedcn1         # DCN1 site
+      allocationRanges:
+      - end: 192.168.133.120
+        start: 192.168.133.100
+      cidr: 192.168.133.0/24
+      gateway: 192.168.133.1
+    - name: ctlplanedcn2         # DCN2 site
+      allocationRanges:
+      - end: 192.168.144.120
+        start: 192.168.144.100
+      cidr: 192.168.144.0/24
+      gateway: 192.168.144.1
+  - name: internalapi
+    dnsDomain: internalapi.example.com
+    subnets:
+    - name: subnet1              # Central site
+      allocationRanges:
+      - end: 172.17.0.250
+        start: 172.17.0.100
+      cidr: 172.17.0.0/24
+      vlan: 20
+    - name: internalapidcn1      # DCN1 site
+      allocationRanges:
+      - end: 172.17.10.250
+        start: 172.17.10.100
+      cidr: 172.17.10.0/24
+      vlan: 30
+    - name: internalapidcn2      # DCN2 site
+      allocationRanges:
+      - end: 172.17.20.250
+        start: 172.17.20.100
+      cidr: 172.17.20.0/24
+      vlan: 40
+----
+
+* Each network defines multiple subnets, one for each site.
+* Each site uses unique VLAN IDs. In this example, central uses VLANs 20-23, DCN1 uses VLANs 30-33, and DCN2 uses VLANs 40-43.
+* The subnet naming convention typically uses `subnet1` for the central site and site-specific names like `internalapidcn1` for edge sites.
+
+Because the sites are geopgraphically distributed, each site requires its own provider network (physnet). The {networking_first_ref} must be configured to recognize all physnets.
+
+.Example Neutron ML2 configuration for multiple physnets
+[source,yaml]
+----
+[ml2_type_vlan]
+network_vlan_ranges = leaf0:1:1000,leaf1:1:1000,leaf2:1:1000
+
+[neutron]
+physnets = leaf0,leaf1,leaf2
+----
+
+* `leaf0` corresponds to the central site.
+* `leaf1` corresponds to the DCN1 site.
+* `leaf2` corresponds to the DCN2 site.
+
+When you create routed provider networks in {rhos_acro}, you create network segments that map to these physnets:
+
+* Segment for central: `physnet=leaf0`, subnet=192.168.122.0/24
+* Segment for DCN1: `physnet=leaf1`, subnet=192.168.133.0/24
+* Segment for DCN2: `physnet=leaf2`, subnet=192.168.144.0/24
+
+[role="_additional-resources"]
+.Additional resources
+* xref:configuring-control-plane-networking-for-spine-leaf_hsm-integration[Configuring control plane networking for spine-leaf topologies]

docs_user/modules/con_adoption-limitations.adoc

@@ -10,7 +10,10 @@ Technology Preview::
 +
 The following features are Technology Previews and have not been tested within the context of the {rhos_long} adoption:
 +
-* FC-based drivers for {block_storage_first_ref}
+* {key_manager_first_ref} adoption with Proteccio hardware security module (HSM) integration
+* {dns_first_ref}
+
+{compute_service} Technology Previews::
 +
 The following {compute_service_first_ref} features are Technology Previews:
 +
@@ -29,9 +32,6 @@ Unsupported features::
 +
 The adoption process does not support the following features:
 +
-* Distributed Compute node architecture (DCN)
-* 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
 

docs_user/modules/con_adoption-process-overview.adoc

@@ -4,7 +4,7 @@
 = Adoption process overview
 
 [role="_abstract"]
-Familiarize yourself with the steps of the adoption process and the optional post-adoption tasks.
+Familiarize yourself with the steps of the adoption process.
 
 Main adoption process::
 +
@@ -22,14 +22,20 @@ endif::[]
 .. xref:migrating-ceph-rgw_migrating-ceph-monitoring[Migrate {Ceph} RGW to external RHEL nodes].
 .. xref:migrating-ceph-rbd_migrating-ceph-monitoring[Migrate {Ceph} RBD to external RHEL nodes].
 
-Post-adoption tasks::
+Distributed Compute Node (DCN) architecture process::
++
+. xref:dcn-adoption-overview_planning[Overview of Distributed Compute Node adoption]
+. xref:adopting-spine-leaf-networks_configuring-network[Configuring spine-leaf networks for the {rhos_long_noacro} deployment]
+. xref:configuring-control-plane-networking-for-spine-leaf_hsm-integration[Configuring control plane networking for spine-leaf topologies]
+. xref:configuring-dcn-data-plane-nodesets_data-plane[Configuring data plane node sets for DCN sites]
++
+If you use a DCN architecture with storage, the following additional steps apply, depending on the services that are included in your deployment:
 +
-* Optional: Run tempest to verify that the entire adoption process is working correctly. For more information, see 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].
-* After adoption, {rhos_long} data plane nodes run Red Hat Enterprise Linux (RHEL) 9.2. The data plane nodes can remain on RHEL 9.2; however, you must perform a system update to use the full feature set from the release, and to align your environment with the maximum support lifecycle of {rhos_acro}.
-** You can perform a system update any time after you complete the adoption procedure.
-** You can defer the system update to a separate maintenance window.
-** You can perform the system update on one nodeset at a time. For example, you can update one nodeset from RHEL 9.2 to RHEL 9.4 in one maintenance window, and then update a different nodeset in another maintenance window later.
+.. xref:adopting-image-service-with-dcn-backend_image-service[Adopting the {image_service} with multiple {Ceph} back ends (DCN)]
+.. xref:adopting-block-storage-service-with-dcn-backend_hsm-integration[Adopt the {block_storage} service with multiple {Ceph} back ends (DCN)]
+.. xref:adopting-compute-services-with-dcn-backend_data-plane[Adopting Compute services with multiple Red Hat Ceph Storage back ends (DCN)]
+.. xref:ceph-migration-dcn_migrating-ceph[{Ceph} migration for Distributed Compute Node deployments]
+
+Post-adoption tasks::
 +
-For more information about updating your environment, see 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].
-* Optional: 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.
-* If you enabled the high availability for Compute instances (Instance HA) service, remove the Pacemaker components from your Compute nodes. For more information, see xref:enabling-high-availability-for-instances_data-plane[Enabling the high availability for Compute instances service].
+* For more details on the tasks you must perform after completing the adoption, see xref:post-adoption-tasks_migrating-ceph-rbd[Post-adoption tasks].