From 64876faefca2304ab415f576b412cdb60a6f0018 Mon Sep 17 00:00:00 2001 From: Katie Gilligan Date: Fri, 3 May 2024 11:42:43 -0400 Subject: [PATCH 1/2] fixed broken xrefs --- ...mbly_adopting-openstack-control-plane-services.adoc | 1 + .../con_block-storage-service-requirements.adoc | 2 +- ...oc_adopting-compute-services-to-the-data-plane.adoc | 3 ++- .../modules/proc_adopting-the-compute-service.adoc | 10 +++++----- .../proc_adopting-the-object-storage-service.adoc | 2 +- .../modules/proc_adopting-the-placement-service.adoc | 2 +- .../proc_migrating-databases-to-mariadb-instances.adoc | 6 ++---- .../modules/proc_reusing-existing-subnet-ranges.adoc | 2 +- 8 files changed, 14 insertions(+), 14 deletions(-) diff --git a/docs_user/assemblies/assembly_adopting-openstack-control-plane-services.adoc b/docs_user/assemblies/assembly_adopting-openstack-control-plane-services.adoc index add2cb956..8bb62ca9f 100644 --- a/docs_user/assemblies/assembly_adopting-openstack-control-plane-services.adoc +++ b/docs_user/assemblies/assembly_adopting-openstack-control-plane-services.adoc @@ -23,6 +23,7 @@ include::../modules/proc_adopting-the-placement-service.adoc[leveloffset=+1] include::../modules/proc_adopting-the-compute-service.adoc[leveloffset=+1] include::../assemblies/assembly_adopting-the-block-storage-service.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] diff --git a/docs_user/modules/con_block-storage-service-requirements.adoc b/docs_user/modules/con_block-storage-service-requirements.adoc index a3d08d4b1..ded2362e8 100644 --- a/docs_user/modules/con_block-storage-service-requirements.adoc +++ b/docs_user/modules/con_block-storage-service-requirements.adoc @@ -21,5 +21,5 @@ RBD, iSCSI, FC, NFS, NVMe-oF, etc. Once you know all the transport protocols that you are using, you can make sure that you are taking them into consideration when placing the Block Storage services (as mentioned above in the Node Roles section) and the right storage transport related binaries are running on the OpenShift nodes. -Detailed information about the specifics for each storage transport protocol can be found in the xref:adopting-the-block-storage-service_adopt-control-plane[Adopting the Block Storage service]. +Detailed information about the specifics for each storage transport protocol can be found in the xref:adopting-the-block-storage-service_adopt-control-plane[Adopting the {block_storage}]. diff --git a/docs_user/modules/proc_adopting-compute-services-to-the-data-plane.adoc b/docs_user/modules/proc_adopting-compute-services-to-the-data-plane.adoc index e918335ba..b6bdb62ff 100644 --- a/docs_user/modules/proc_adopting-compute-services-to-the-data-plane.adoc +++ b/docs_user/modules/proc_adopting-compute-services-to-the-data-plane.adoc @@ -74,8 +74,9 @@ spec: vlan: 22 EOF ---- -+ + * When `neutron-sriov-nic-agent` is running on the existing Compute nodes, check the physical device mappings and ensure that they match the values that are defined in the `OpenStackDataPlaneNodeSet` custom resource (CR). For more information, see xref:reviewing-the-openstack-control-plane-configuration_adopt-control-plane[Reviewing the {rhos_prev_long} control plane configuration]. + * Define the shell variables necessary to run the script that runs the fast-forward upgrade. Omit setting `CEPH_FSID`, if the local storage backend is going to be configured by Nova for Libvirt. The storage backend cannot be changed during adoption, and must match the one used on the source cloud: ---- PODIFIED_DB_ROOT_PASSWORD=$(oc get -o json secret/osp-secret | jq -r .data.DbRootPassword | base64 -d) diff --git a/docs_user/modules/proc_adopting-the-compute-service.adoc b/docs_user/modules/proc_adopting-the-compute-service.adoc index 101c3a055..b9d5f38f2 100644 --- a/docs_user/modules/proc_adopting-the-compute-service.adoc +++ b/docs_user/modules/proc_adopting-the-compute-service.adoc @@ -15,16 +15,16 @@ here this time). * Previous Adoption steps completed. Notably, ** the xref:migrating-databases-to-mariadb-instances_migrating-databases[Migrating databases to MariaDB instances] must already be imported into the control plane MariaDB; - ** the xref:adopting-the-identity-service_{context}[Adopting the Identity service] needs to be imported; - ** the xref:adopting-the-key-manager-service_{context}[Adopting the Key Manager service] needs to be imported; + ** the xref:adopting-the-identity-service_adopt-control-plane[Adopting the Identity service] needs to be imported; + ** the xref:adopting-the-key-manager-service_adopt-control-plane[Adopting the Key Manager service] needs to be imported; ** the xref:adopting-the-placement-service_{context}[Adopting the Placement service] needs to be imported; - ** the xref:adopting-the-image-service_{context}[Adopting the Image service] needs to be imported; + ** the xref:adopting-the-image-service_adopt-control-plane[Adopting the Image service] needs to be imported; ** the xref:migrating-ovn-data_migrating-databases[Migrating OVN data] need to be imported; - ** the xref:adopting-the-networking-service_{context}[Adopting the Networking service] needs to be imported; + ** the xref:adopting-the-networking-service_adopt-control-plane[Adopting the Networking service] needs to be imported; ** the xref:adopting-the-bare-metal-provisioning-service_{context}[Adopting the Openstack Baremetal service] needs to be imported; //kgilliga:Need to revist this xref. Might rewrite this section anyway. ** Required services specific topology -xref:proc_retrieving-services-topology-specific-configuration_{context}[Retrieving services from a topology specific-configuration]. +xref:proc_retrieving-services-topology-specific-configuration_adopt-control-plane[Retrieving services from a topology specific-configuration]. ** {rhos_prev_long} services have been stopped. For more information, see xref:stopping-openstack-services_migrating-databases[Stopping {rhos_prev_long} services]. * Define the following shell variables. The values that are used are examples. Replace these example values with values that are correct for your environment: ---- diff --git a/docs_user/modules/proc_adopting-the-object-storage-service.adoc b/docs_user/modules/proc_adopting-the-object-storage-service.adoc index 37e6c6657..ae0485614 100644 --- a/docs_user/modules/proc_adopting-the-object-storage-service.adoc +++ b/docs_user/modules/proc_adopting-the-object-storage-service.adoc @@ -135,4 +135,4 @@ Hello World! [NOTE] At this point data is still stored on the previously existing nodes. For more information about migrating the actual data from the old -to the new deployment, see xref:migrating-the-object-storage-service_migrate-object-storage-service[Object Storage service migration]. +to the new deployment, see xref:migrating-the-object-storage-service_migrate-object-storage-service[Migrating the {object_storage_first_ref} to {rhos_long} nodes]. diff --git a/docs_user/modules/proc_adopting-the-placement-service.adoc b/docs_user/modules/proc_adopting-the-placement-service.adoc index 74a0401b6..f3a8614ad 100644 --- a/docs_user/modules/proc_adopting-the-placement-service.adoc +++ b/docs_user/modules/proc_adopting-the-placement-service.adoc @@ -9,7 +9,7 @@ * Previous Adoption steps completed. Notably, ** the xref:migrating-databases-to-mariadb-instances_migrating-databases[Migrating databases to MariaDB instances] must already be imported into the control plane MariaDB. - ** the xref:adopting-the-identity-service_{context}[Adopting the Identity service] needs to be imported. + ** the xref:adopting-the-identity-service_adopt-control-plane[Adopting the Identity service] needs to be imported. ** the Memcached operator needs to be deployed (nothing to import for it from the source environment). diff --git a/docs_user/modules/proc_migrating-databases-to-mariadb-instances.adoc b/docs_user/modules/proc_migrating-databases-to-mariadb-instances.adoc index 6963f71f6..5c80e8c98 100644 --- a/docs_user/modules/proc_migrating-databases-to-mariadb-instances.adoc +++ b/docs_user/modules/proc_migrating-databases-to-mariadb-instances.adoc @@ -19,8 +19,7 @@ here this time). * Make sure the previous Adoption steps have been performed successfully. ** The `OpenStackControlPlane` resource must be already created. ** The control plane MariaDB and RabbitMQ are running. No other control plane services are running. - ** Required services specific topology. For more information, see xref:pulling-the-openstack-configuration_{context}[Pulling the {rhos_prev_long} configuration]. -//kgilliga: this xref should specifically point to the Get services topology specific configuration module when it's ready. + ** Required services specific topology. For more information, see xref:proc_retrieving-services-topology-specific-configuration_adopt-control-plane[Retrieving services from a topology specific-configuration]. ** {OpenStackShort} services have been stopped. For more information, see xref:stopping-openstack-services_{context}[Stopping {rhos_prev_long} services]. ** There must be network routability between the original MariaDB and the MariaDB for the control plane. * Define the following shell variables. The values that are used are examples. Replace these example values with values that are correct for your environment: @@ -228,8 +227,7 @@ EOF .Verification Compare the following outputs with the topology specific configuration. -For more information, see xref:pulling-the-openstack-configuration_{context}[Pulling the {rhos_prev_long} configuration]. -//kgilliga: this xref should specifically point to the Get services topology specific configuration module when it's ready.: +For more information, see xref:proc_retrieving-services-topology-specific-configuration_adopt-control-plane[Retrieving services from a topology specific-configuration]. . Check that the databases were imported correctly: + diff --git a/docs_user/modules/proc_reusing-existing-subnet-ranges.adoc b/docs_user/modules/proc_reusing-existing-subnet-ranges.adoc index 70bc3f6f1..8f5c8df11 100644 --- a/docs_user/modules/proc_reusing-existing-subnet-ranges.adoc +++ b/docs_user/modules/proc_reusing-existing-subnet-ranges.adoc @@ -14,7 +14,7 @@ allocated to existing cluster nodes. This scenario implies that the remaining IP addresses in the existing subnet is enough for the new control plane services. If not, xref:using-new-subnet-ranges_{context}[Scenario 1: Using new subnet ranges] should be used -instead. For more information, see xref:planning-your-ipam-configuration_network-requirements[Planning your IPAM configuration]. +instead. For more information, see xref:planning-your-ipam-configuration_configuring-network[Planning your IPAM configuration]. No special routing configuration is required in this scenario; the only thing to pay attention to is to make sure that already consumed IP addresses don't From dcde74803590151c5e54113e8a986de7cfde207b Mon Sep 17 00:00:00 2001 From: Katie Gilligan Date: Fri, 3 May 2024 15:38:03 -0400 Subject: [PATCH 2/2] updating links and adding ifevals --- ...embly_configuring-network-for-RHOSO-deployment.adoc | 9 +++------ docs_user/modules/con_about-machine-configs.adoc | 2 +- docs_user/modules/con_about-node-selector.adoc | 9 +++------ .../modules/proc_adopting-the-networking-service.adoc | 2 ++ .../proc_adopting-the-orchestration-service.adoc | 2 ++ ...figuring-networking-for-control-plane-services.adoc | 10 ++++------ .../modules/proc_creating-a-ceph-nfs-cluster.adoc | 9 ++++++++- 7 files changed, 23 insertions(+), 20 deletions(-) diff --git a/docs_user/assemblies/assembly_configuring-network-for-RHOSO-deployment.adoc b/docs_user/assemblies/assembly_configuring-network-for-RHOSO-deployment.adoc index 5f208abe0..a4b333f61 100644 --- a/docs_user/assemblies/assembly_configuring-network-for-RHOSO-deployment.adoc +++ b/docs_user/assemblies/assembly_configuring-network-for-RHOSO-deployment.adoc @@ -9,12 +9,9 @@ it is important to plan it carefully. The general network requirements for the OpenStack services are not much different from the ones in a {OpenStackPreviousInstaller} deployment, but the way you handle them is. [NOTE] -More details about the network architecture and configuration can be -found in the -https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/18.0-dev-preview/html/deploying_red_hat_openstack_platform_18.0_development_preview_3_on_red_hat_openshift_container_platform/assembly_preparing-rhocp-for-rhosp#doc-wrapper[general -OpenStack documentation] as well as -https://docs.openshift.com/container-platform/4.14/networking/about-networking.html[OpenShift -Networking guide]. This document will address concerns specific to adoption. +For more information about the network architecture and configuration, see +link:https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/18.0-dev-preview/html/deploying_red_hat_openstack_platform_18.0_development_preview_3_on_red_hat_openshift_container_platform/assembly_preparing-rhocp-for-rhosp[_Deploying Red Hat OpenStack Platform 18.0 Development Preview 3 on Red Hat OpenShift Container Platform_] and link:https://docs.openshift.com/container-platform/4.15/networking/about-networking.html[About +networking] in _OpenShift Container Platform 4.15 Documentation_. This document will address concerns specific to adoption. // TODO: update the openstack link with the final documentation diff --git a/docs_user/modules/con_about-machine-configs.adoc b/docs_user/modules/con_about-machine-configs.adoc index 110e551f9..6fb133f10 100644 --- a/docs_user/modules/con_about-machine-configs.adoc +++ b/docs_user/modules/con_about-machine-configs.adoc @@ -43,7 +43,7 @@ metadata: < . . . > ---- -Refer to the https://docs.openshift.com/container-platform/4.13/post_installation_configuration/machine-configuration-tasks.html[OpenShift documentation for additional information on `MachineConfig` and `MachineConfigPools`] +Refer to the link:https://docs.openshift.com/container-platform/4.15/post_installation_configuration/machine-configuration-tasks.html[Postinstallation machine configuration tasks] in _OpenShift Container Platform 4.15 Documentation_. *WARNING:* Applying a `MachineConfig` to an OpenShift node will make the node reboot. diff --git a/docs_user/modules/con_about-node-selector.adoc b/docs_user/modules/con_about-node-selector.adoc index 32db8963e..221437a92 100644 --- a/docs_user/modules/con_about-node-selector.adoc +++ b/docs_user/modules/con_about-node-selector.adoc @@ -16,9 +16,7 @@ You either label the OpenShift nodes or use existing labels, and then use those `nodeSelector` field. The `nodeSelector` field in the OpenStack manifests follows the standard -OpenShift `nodeSelector` field, please refer to https://docs.openshift.com/container-platform/4.13/nodes/scheduling/nodes-scheduler-node-selectors.html[the OpenShift documentation on -the matter] -additional information. +OpenShift `nodeSelector` field. For more information, see link:https://docs.openshift.com/container-platform/4.15/nodes/scheduling/nodes-scheduler-node-selectors.html[About node selectors] in _OpenShift Container Platform 4.15 Documentation_. This field is present at all the different levels of the OpenStack manifests: @@ -92,6 +90,5 @@ The Block Storage service operator does not currently have the possibility of de the `nodeSelector` in `cinderVolumes`, so you need to specify it on each of the backends. -It's possible to leverage labels added by https://docs.openshift.com/container-platform/4.13/hardware_enablement/psap-node-feature-discovery-operator.html[the node feature discovery -operator] -to place OpenStack services. +It is possible to leverage labels added by the Node Feature Discovery (NFD) Operator to place OpenStack services. For more information, see link:https://docs.openshift.com/container-platform/4.13/hardware_enablement/psap-node-feature-discovery-operator.html[Node Feature Discovery Operator] in _OpenShift Container Platform 4.15 Documentation_. + diff --git a/docs_user/modules/proc_adopting-the-networking-service.adoc b/docs_user/modules/proc_adopting-the-networking-service.adoc index e0afac215..5fecd3b26 100644 --- a/docs_user/modules/proc_adopting-the-networking-service.adoc +++ b/docs_user/modules/proc_adopting-the-networking-service.adoc @@ -20,7 +20,9 @@ should be already adopted. .Procedure //The following link takes me to a 404. Do we need this text? I think we should start the procedure at "Patch OpenStackControlPlane..." +ifeval::["{build}" != "downstream"] As already done for https://github.com/openstack-k8s-operators/data-plane-adoption/blob/main/keystone_adoption.md[Keystone], the Neutron Adoption follows the same pattern. +endif::[] * Patch `OpenStackControlPlane` to deploy {networking}: + diff --git a/docs_user/modules/proc_adopting-the-orchestration-service.adoc b/docs_user/modules/proc_adopting-the-orchestration-service.adoc index 450092d33..67a953d98 100644 --- a/docs_user/modules/proc_adopting-the-orchestration-service.adoc +++ b/docs_user/modules/proc_adopting-the-orchestration-service.adoc @@ -26,7 +26,9 @@ trying to adopt {orchestration}. .Procedure //kgilliga: I get an error when I click this link. Do we need it in the downstream docs? +ifeval::["{build}" != "downstream"] As already done for https://github.com/openstack-k8s-operators/data-plane-adoption/blob/main/keystone_adoption.md[Keystone], the Heat Adoption follows a similar pattern. +endif::[] . Patch the `osp-secret` to update the `HeatAuthEncryptionKey` and `HeatPassword`. This needs to match what you have configured in the existing {OpenStackPreviousInstaller} {orchestration} configuration. You can retrieve and verify the existing `auth_encryption_key` and `service` passwords via: diff --git a/docs_user/modules/proc_configuring-networking-for-control-plane-services.adoc b/docs_user/modules/proc_configuring-networking-for-control-plane-services.adoc index dd2ee9f85..f6323e529 100644 --- a/docs_user/modules/proc_configuring-networking-for-control-plane-services.adoc +++ b/docs_user/modules/proc_configuring-networking-for-control-plane-services.adoc @@ -2,15 +2,13 @@ = Configuring the networking for control plane services -//== Pod connectivity to isolated networks -//Heading 2s are commented out until I rewrite this file for GA. - Once NMState operator created the desired hypervisor network configuration for isolated networks, we need to configure OpenStack services to use configured interfaces. This is achieved by defining `NetworkAttachmentDefinition` custom resources (CRs) for -each isolated network. (In some clusters, these CRs are managed by -https://docs.openshift.com/container-platform/4.14/networking/cluster-network-operator.html[Cluster -Network Operator], in which case `Network` CRs should be used instead.) +each isolated network. (In some clusters, these CRs are managed by the Cluster +Network Operator in which case `Network` CRs should be used instead. For more information, see +link:https://docs.openshift.com/container-platform/4.15/networking/cluster-network-operator.html[Cluster +Network Operator] in _OpenShift Container Platform 4.15 Documentation_.) For example, diff --git a/docs_user/modules/proc_creating-a-ceph-nfs-cluster.adoc b/docs_user/modules/proc_creating-a-ceph-nfs-cluster.adoc index 752f20b5b..2c7ab591b 100644 --- a/docs_user/modules/proc_creating-a-ceph-nfs-cluster.adoc +++ b/docs_user/modules/proc_creating-a-ceph-nfs-cluster.adoc @@ -92,9 +92,16 @@ with a 3-node NFS cluster. * The `ingress-mode` argument must be set to ``haproxy-protocol``. No other ingress-mode will be supported. This ingress mode will allow enforcing client restrictions through {rhos_component_storage_file}. +ifeval::["{build}" != "downstream"] * For more information on deploying the clustered Ceph NFS service, see the link:https://docs.ceph.com/en/latest/cephadm/services/nfs/[ceph orchestrator -documentation] +documentation]. +endif::[] +ifeval::["{build}" != "upstream"] +For more information on deploying the clustered Ceph NFS service, see the +link:https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/7/html-single/operations_guide/index#management-of-nfs-ganesha-gateway-using-the-ceph-orchestrator[Management of NFS-Ganesha gateway using the Ceph Orchestrator (Limited Availability)] in _Red Hat Ceph Storage 7 Operations Guide_. +endif::[] +//kgilliga: Confirm that we should link to the Ceph Operations Guide downstream. * The following commands are run inside a `cephadm shell` to create a clustered Ceph NFS service. +