Merge pull request #449 from klgill/BetaDocs-FixCrossReferences

fixing cross-references

docs_user/assemblies/assembly_configuring-isolated-networks.adoc

@@ -11,16 +11,14 @@ Before proceeding, you should have a list of the following IP address
 allocations to be used for the new control plane services:
 
 * 1 IP address, per isolated network, per {OpenShift} worker node. (These
-  addresses will <<_configure_openshift_worker_nodes,translate>> to
-  `NodeNetworkConfigurationPolicy` custom resources (CRs).)
+  addresses configure openshift worker nodes to
+  `NodeNetworkConfigurationPolicy` custom resources (CRs).) For more information, see xref:configuring-openshift-worker-nodes_isolated-networks[Configuring {OpenShift} worker nodes].
 * IP range, per isolated network, for the data plane nodes. (These ranges will
-  <<_configure_data_plane_nodes,translate>> to `NetConfig` CRs.)
+  configure data plane nodes to `NetConfig` CRs.) For more information, see xref:configuring-data-plane-nodes_isolated-networks[Configuring data plane nodes].
 * IP range, per isolated network, for control plane services. (These ranges
-  will <<_pod_connectivity_to_isolated_networks,translate>> to
-  `NetworkAttachmentDefinition` CRs.)
-* IP range, per isolated network, for load balancer IP addresses. (These ranges
-  will <<_load_balancer_ip_addresses,translate>> to `IPAddressPool` CRs for
-  MetalLB.)
+  will enable pod connectivity to isolated networks to
+  `NetworkAttachmentDefinition` CRs.) For more information, see xref:configuring-networking-for-control-plane-services_isolated-networks[Configuring the networking for control plane services].
+* IP range, per isolated network, for load balancer IP addresses. (These ranges will define load balancer IP addresses to `IPAddressPool` CRs for MetalLB.) For more information, see xref:configuring-networking-for-control-plane-services_isolated-networks[Configuring the networking for control plane services].
 
 [IMPORTANT]
 Make sure you have the information listed above before proceeding with the next steps.

docs_user/modules/con_openshift-preparation-for-block-storage-adoption.adoc

@@ -199,11 +199,8 @@ checking on the host:
 cat /sys/module/nvme_core/parameters/multipath
 ----
 +
-IMPORTANT: ANA doesn't use the Linux Multipathing Device Mapper, but the
-*current {OpenStackShort}
-code requires `multipathd` on compute nodes to be running for {compute_service_first_ref} to be able to
-use multipathing, so please remember to follow the multipathing part for compute
-nodes on the <<multipathing,multipathing section>>.
+IMPORTANT: ANA does not use the Linux Multipathing Device Mapper, but the
+current {OpenStackShort} code requires `multipathd` on Compute nodes to be running for {compute_service_first_ref} to be able to use multipathing.
 
 //*TODO:* Add, or at least mention, the Nova eDPM side for NVMe-oF.
 

docs_user/modules/proc_adopting-image-service-with-block-storage-backend.adoc

@@ -77,7 +77,7 @@ spec:
 ----
 +
 Having {block_storage} as a backend establishes a dependency between the two services, and any deployed `GlanceAPI` instance would not work if the {image_service} is configured with {block_storage} that is still not available in the `OpenStackControlPlane`.
-Once {block_storage}, and in particular `CinderVolume`, has been adopted through the procedure described in <<adopting-the-block-storage-service>>, it is possible to proceed with the `GlanceAPI` adoption.
+Once {block_storage}, and in particular `CinderVolume`, has been adopted, it is possible to proceed with the `GlanceAPI` adoption.
 
 . Verify that `CinderVolume` is available:
 +

docs_user/modules/proc_adopting-image-service-with-object-storage-backend.adoc

@@ -73,7 +73,7 @@ spec:
 ----
 +
 Having {object_storage} as a backend establishes a dependency between the two services, and any deployed `GlanceAPI` instance would not work if {image_service} is configured with {object_storage} that is still not available in the `OpenStackControlPlane`.
-Once {object_storage}, and in particular `SwiftProxy`, has been adopted through the procedure described in <<adopting-object-storage-service>>, it is possible to proceed with the `GlanceAPI` adoption.
+Once {object_storage}, and in particular `SwiftProxy`, has been adopted, it is possible to proceed with the `GlanceAPI` adoption. For more information, see xref:adopting-the-object-storage-service_adopt-control-plane[Adopting the Object Storage service].
 
 . Verify that `SwiftProxy` is available:
 +

docs_user/modules/proc_adopting-the-compute-service.adoc

@@ -142,7 +142,7 @@ $ openstack endpoint list | grep nova
 $ openstack server list
 ----
 
-Compare the following outputs with the topology specific configuration in xref:proc_retrieving-services-topology-specific-configuration_{context}[Retrieving services from a topology specific-configuration].
+Compare the following outputs with the topology specific configuration in xref:proc_retrieving-services-topology-specific-configuration_adopt-control-plane[Retrieving services from a topology specific-configuration].
 
 * Query the superconductor for cell1 existance and compare it to pre-adoption values:
 +

docs_user/modules/proc_configuring-data-plane-nodes.adoc

@@ -21,8 +21,7 @@ per-node).
 To make sure the latest network configuration is used during the data plane adoption, you
 should also set `edpm_network_config_update: true` in the `nodeTemplate`.
 
-You will proceed with <<adopting-dataplane_openstack-adoption,Data Plane Adoption
-process>> once the {OpenShiftShort} control plane is deployed in the
+You will proceed with the data plane adoption once the {OpenShiftShort} control plane is deployed in the
 {OpenShiftShort} cluster. When doing so, you will configure `NetConfig` and
 `OpenstackDataplaneNodeSet` CRs, using the same VLAN tags and IPAM
 configuration as determined in the previous steps.