Merge pull request #1190 from klgill/docs-19956-UpdateOSPdONetworkingSteps

ospdo updates

Author: openshift-merge-bot[bot]

docs_user/assemblies/assembly_configuring-network-for-RHOSO-deployment.adoc

@@ -21,6 +21,9 @@ 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 VLAN tags, always reuse the configuration from the existing deployment.
 
 [NOTE]

docs_user/assemblies/assembly_planning-your-ipam-configuration.adoc

@@ -47,7 +47,9 @@ Additional IP addresses might be required in future {OpenStackShort} releases, s
 
 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].
 
+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]
 

docs_user/modules/proc_reusing-existing-subnet-ranges.adoc

@@ -6,7 +6,9 @@
 [role="_abstract"]
 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].
+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.