From 25253dfdfb38ab2d5e190e2a89be82731b78a87c Mon Sep 17 00:00:00 2001 From: Katie Gilligan Date: Wed, 8 May 2024 14:58:16 -0400 Subject: [PATCH] fixing cross-references --- .../assembly_configuring-isolated-networks.adoc | 14 ++++++-------- ...ift-preparation-for-block-storage-adoption.adoc | 7 ++----- ...g-image-service-with-block-storage-backend.adoc | 2 +- ...-image-service-with-object-storage-backend.adoc | 2 +- .../modules/proc_adopting-the-compute-service.adoc | 2 +- .../modules/proc_configuring-data-plane-nodes.adoc | 3 +-- 6 files changed, 12 insertions(+), 18 deletions(-) diff --git a/docs_user/assemblies/assembly_configuring-isolated-networks.adoc b/docs_user/assemblies/assembly_configuring-isolated-networks.adoc index 00c8c22d2..91f756a63 100644 --- a/docs_user/assemblies/assembly_configuring-isolated-networks.adoc +++ b/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. diff --git a/docs_user/modules/con_openshift-preparation-for-block-storage-adoption.adoc b/docs_user/modules/con_openshift-preparation-for-block-storage-adoption.adoc index 245e7e016..2529bde2a 100644 --- a/docs_user/modules/con_openshift-preparation-for-block-storage-adoption.adoc +++ b/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 <>. +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. diff --git a/docs_user/modules/proc_adopting-image-service-with-block-storage-backend.adoc b/docs_user/modules/proc_adopting-image-service-with-block-storage-backend.adoc index 1b4c0001e..6b41d5c67 100644 --- a/docs_user/modules/proc_adopting-image-service-with-block-storage-backend.adoc +++ b/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 <>, 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: + diff --git a/docs_user/modules/proc_adopting-image-service-with-object-storage-backend.adoc b/docs_user/modules/proc_adopting-image-service-with-object-storage-backend.adoc index b26ac0c9a..55ec95787 100644 --- a/docs_user/modules/proc_adopting-image-service-with-object-storage-backend.adoc +++ b/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 <>, 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: + diff --git a/docs_user/modules/proc_adopting-the-compute-service.adoc b/docs_user/modules/proc_adopting-the-compute-service.adoc index a625d2510..71513ce7b 100644 --- a/docs_user/modules/proc_adopting-the-compute-service.adoc +++ b/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: + diff --git a/docs_user/modules/proc_configuring-data-plane-nodes.adoc b/docs_user/modules/proc_configuring-data-plane-nodes.adoc index 91ba592b1..fff759a3f 100644 --- a/docs_user/modules/proc_configuring-data-plane-nodes.adoc +++ b/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 <> 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.