18.0 fr5 cherrypick limitations

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]

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

@@ -24,11 +24,15 @@ 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_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_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/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_troubleshooting-hsm[Configuring control plane networking for spine-leaf topologies]

docs_user/modules/con_adoption-limitations.adoc

@@ -10,7 +10,7 @@ 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
 +
 The following {compute_service_first_ref} features are Technology Previews:
 +
@@ -29,7 +29,7 @@ Unsupported features::
 +
 The adoption process does not support the following features:
 +
-* Distributed Compute node architecture (DCN)
+* 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

docs_user/modules/con_adoption-process-overview.adoc

@@ -33,3 +33,4 @@ 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].
+* Enable TLS Everywhere (TLS-e). For more information about enabling TLS-e after completing the adoption, see 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_.

docs_user/modules/con_dcn-adoption-overview.adoc

@@ -0,0 +1,75 @@
+:_mod-docs-content-type: CONCEPT
+[id="dcn-adoption-overview_{context}"]
+
+= Overview of Distributed Compute Node adoption
+
+[role="_abstract"]
+The process to adopt Distributed Compute Node (DCN) deployment from {rhos_prev_long} ({OpenStackShort}) to {rhos_long} requires additional adoption tasks:
+
+* You must map a multi-stack deployment to multiple node sets.
+* You must map additional networking configurations.
+
+Multi-stack to multi-node set mapping:: In {OpenStackPreviousInstaller} deployments, DCN environments use multiple Heat stacks:
++
+** The Central stack is templating for Controllers and central Compute nodes.
+** An edge stack is templating for Edge Compute nodes in a stack. There is one stack per DCN site.
++
+When you perform an adoption, map {OpenStackPreviousInstaller} stacks to `OpenStackDataPlaneNodeSet` custom resources (CRs):
++
+.Mapping {OpenStackPreviousInstaller} stacks to {rhos_acro} nodesets
+[options="header"]
+|===
+| {OpenStackPreviousInstaller} stack | {rhos_acro} nodeset | Availability zone
+| Central stack (Compute role) | `openstack-edpm` or `openstack-cell1` | az-central
+| DCN1 stack (ComputeDcn1 role) | `openstack-edpm-dcn1` or `openstack-cell1-dcn1` | az-dcn1
+| DCN2 stack (ComputeDcn2 role) | `openstack-edpm-dcn2` or `openstack-cell1-dcn2` | az-dcn2
+|===
++
+[NOTE]
+====
+Keep all node sets in the same Nova cell to maintain unified scheduling through a shared cell. The default cell is `cell1`.
+====
+
+Key differences from standard adoption:: The following table summarizes the differences between standard adoption and DCN adoption:
++
+.Comparison of standard and DCN adoption
+[options="header"]
+|===
+| Aspect | Standard adoption | DCN adoption
+| Director stacks | Single stack | Multiple stacks (central + edge sites)
+| Network topology | Flat L2 networks | Routed L3 networks with multiple subnets
+| Data plane node sets | Single node set | Multiple node sets (one per site minimum)
+| Network routes | Usually not required | Required for inter-site connectivity
+| Physnets | Single physnet (e.g., `datacentre`) | Multiple physnets (e.g., `leaf0`, `leaf1`, `leaf2`)
+| Availability zones | Often single AZ | Multiple AZs (one per site)
+| OVN bridge mappings | Single mapping | Site-specific mappings
+| Provider networks | Single segment | Multi-segment routed provider networks
+|===
+
+Requirements for DCN adoption:: Before adopting a DCN deployment, ensure you have:
++
+** Network topology information for all sites (IP ranges, VLANs, gateways)
+** Inter-site routing configuration (routes between site subnets)
+** Mapping of {OpenStackPreviousInstaller} roles to availability zones
+** OVN bridge mapping configuration for each site
+
+[IMPORTANT]
+====
+The adoption of the control plane must complete before adopting any data plane nodes. However, once the control plane is adopted, the edge site data plane adoptions can proceed in parallel with the central site data plane adoption.
+====
+
+DCN Adoption workflow overview:: The adoption of a Distributed Compute Node (DCN) deployment from {rhos_prev_long} ({OpenStackShort}) to {rhos_long}
++
+. **Control plane adoption**: Adopt all control plane services from the central {OpenStackPreviousInstaller} stack to the {rhos_acro} control plane. This is identical to standard adoption.
+. **Network configuration**: Configure multi-subnet `NetConfig` and `NetworkAttachmentDefinition` CRs to support all site networks.
+. **Data plane node set creation**: Create separate `OpenStackDataPlaneNodeSet` CRs for each site, each with site-specific network configurations:
++
+** Network subnet references
+** OVN bridge mappings (physnets)
+** Inter-site routing configuration
+. **Data plane deployment**: Deploy all node sets. The edge site node sets can be deployed in parallel after the central site control plane is adopted.
+
+
+[role="_additional-resources"]
+.Additional resources
+* xref:adopting-spine-leaf-networks_planning[Configuring spine-leaf networks for the {rhos_long_noacro} deployment]

docs_user/modules/con_preventing-config-loss-when-using-oc-patch.adoc

@@ -0,0 +1,18 @@
+:_mod-docs-content-type: CONCEPT
+[id="preventing-config-loss-when-using-oc-patch_{context}"]
+
+= 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.
+
+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:
+
+----
+$ oc get <resource_type> <resource_name> -o yaml > <filename>.yaml
+----
+
+For example:
+----
+$ oc get OpenStackControlPlane openstack-control-plane -o yaml > openstack_control_plane.yaml
+----