updating service names

docs_user/modules/con_node-roles.adoc

@@ -32,7 +32,7 @@ high disk and network usage since many of its operations are in the data path
 the cinder-backup service which has high memory, network, and CPU (to compress
 data) requirements.
 
-The {image_service_first_ref} and Swift components are in the data path, as well as RabbitMQ and Galera services.
+The {image_service_first_ref} and {object_storage_first_ref} components are in the data path, as well as RabbitMQ and Galera services.
 
 Given these requirements it may be preferable not to let these services wander
 all over your {OpenShiftShort} worker nodes with the possibility of impacting other

docs_user/modules/proc_adopting-compute-services-to-the-data-plane.adoc

@@ -209,7 +209,7 @@ EOF
 The secret `nova-cell<X>-compute-config` is auto-generated for each
 `cell<X>`. You must specify `nova-cell<X>-compute-config` and `nova-migration-ssh-key` for each custom `OpenStackDataPlaneService` related to the Compute service.
 
-That service removes pre-FFU workarounds and configures Nova compute
+That service removes pre-FFU workarounds and configures Compute
 services for local storage backend.
 
 * Or, create a `nova-compute-extra-config` service (with Ceph backend for libvirt):
@@ -261,7 +261,7 @@ spec:
 EOF
 ----
 +
-That service removes pre-FFU workarounds and configures Nova compute
+That service removes pre-FFU workarounds and configures Compute
 services for Ceph storage backend.
 Provided above resources should contain a cell-specific configurations.
 For multi-cell, config maps and {rhos_prev_long} data plane services should be named like `nova-custom-ceph-cellX` and `nova-compute-extraconfig-cellX`.
@@ -471,7 +471,7 @@ endif::[]
 EOF
 ----
 +
-* Prepare adopted EDPM workloads to use Ceph backend for Cinder, if configured so
+* Prepare adopted EDPM workloads to use Ceph backend for Block Storage service (cinder), if configured so
 +
 [source,yaml]
 ----
@@ -648,7 +648,7 @@ oc logs -l app=openstackansibleee -f --max-log-requests 20
 oc wait --for condition=Ready osdpns/openstack --timeout=30m
 ----
 
-. Verify that neutron agents are alive:
+. Verify that {networking_first_ref} agents are alive:
 +
 ----
 oc exec openstackclient -- openstack network agent list

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

@@ -27,7 +27,7 @@ spec
 
 .Prerequisites
 
-* Previous Adoption steps completed. Notably, MariaDB, Keystone and Barbican
+* Previous Adoption steps completed. Notably, MariaDB, {identity_service_first_ref} and {key_manager_first_ref}
 should be already adopted.
 
 .Procedure

docs_user/modules/proc_adopting-image-service-with-ceph-backend.adoc

@@ -6,7 +6,7 @@ Adopt the {image_service_first_ref} that you deployed with a {Ceph} backend. Use
 
 .Prerequisites
 
-* Previous Adoption steps completed. Notably, MariaDB, Keystone and Barbican
+* Previous Adoption steps completed. Notably, MariaDB, {identity_service_first_ref} and {key_manager_first_ref}
 should be already adopted.
 * Make sure the Ceph-related secret (`ceph-conf-files`) was created in
 the `openstack` namespace and that the `extraMounts` property of the

docs_user/modules/proc_adopting-image-service-with-nfs-ganesha-backend.adoc

@@ -9,7 +9,7 @@ Adopt the {image_service_first_ref} that you deployed with an NFS Ganesha backen
 
 .Prerequisites
 
-* Previous Adoption steps completed. Notably, MariaDB, Keystone and Barbican
+* Previous Adoption steps completed. Notably, MariaDB, {identity_service_first_ref} and {key_manager_first_ref}
 should be already adopted.
 * In the source cloud, verify the NFS Ganesha parameters used by the overcloud to configure the {image_service} backend.
 In particular, find among the {OpenStackPreviousInstaller} heat templates the following variables that are usually an override of the default content provided by

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

@@ -25,7 +25,7 @@ spec
 
 .Prerequisites
 
-* Previous Adoption steps completed. Notably, MariaDB, Keystone and Barbican
+* Previous Adoption steps completed. Notably, MariaDB, {identity_service_first_ref} and {key_manager_first_ref}
 should be already adopted.
 
 .Procedure

docs_user/modules/proc_adopting-key-manager-service.adoc

@@ -14,7 +14,7 @@ Additional backends are available, such as PKCS11 and DogTag, however they are n
 
 .Prerequisites
 
-* Previous Adoption steps completed. Notably, MariaDB, RabbitMQ and Keystone.
+* Previous Adoption steps completed. Notably, MariaDB, RabbitMQ, and {identity_service_first_ref}.
 should be already adopted.
 
 .Procedure

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

@@ -32,7 +32,7 @@ alias openstack="oc exec -t openstackclient -- openstack"
 .Procedure
 
 [NOTE]
-This procedure assumes that Nova Metadata is deployed on the top level and not on each cell level, so this example imports it the same way. If the source deployment has a per cell metadata deployment, adjust the given below patch as needed. Metadata service cannot be run in `cell0`.
+This procedure assumes that {compute_service} Metadata is deployed on the top level and not on each cell level, so this example imports it the same way. If the source deployment has a per cell metadata deployment, adjust the given below patch as needed. Metadata service cannot be run in `cell0`.
 
 
 . Patch `OpenStackControlPlane` to deploy the {compute_service}:
@@ -107,7 +107,7 @@ spec:
 '
 ----
 
-* If adopting nova with the Baremetal service (`ironic`), append the following `novaComputeTemplates` in the `cell1` section of the Nova CR patch:
+* If adopting {compute_service_first_ref} with the Baremetal service (`ironic`), append the following `novaComputeTemplates` in the `cell1` section of the {compute_service} CR patch:
 +
 *NOTE*: Set the `[DEFAULT]host` configuration option to match the hostname of the node running the `ironic` compute driver in the source cloud.
 +

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

@@ -15,7 +15,7 @@ This guide also assumes that:
 
 .Prerequisites
 
-* Previous Adoption steps completed. Notably, MariaDB and Keystone and xref:migrating-ovn-data_migrating-databases[Migrating OVN data]
+* Previous Adoption steps completed. Notably, MariaDB,{identity_service_first_ref}, and xref:migrating-ovn-data_migrating-databases[Migrating OVN data]
 should be already adopted.
 
 .Procedure

docs_user/modules/proc_deploying-file-systems-service-control-plane.adoc

@@ -20,10 +20,10 @@ can reach the management network that the storage system is in.
 a new clustered Ceph NFS service is deployed on the Ceph cluster with the help
 of Ceph orchestrator. For more information, see
 xref:creating-a-ceph-nfs-cluster_migrating-databases[Creating a Ceph NFS cluster].
-* Ensure that services such as keystone and memcached are available prior to
+* Ensure that services such as {identity_service_first_ref} and memcached are available prior to
 adopting the Shared File Systems services.
 * If tenant-driven networking was enabled (`driver_handles_share_servers=True`),
-ensure that neutron has been deployed prior to adopting Shared File Systems services.
+ensure that {networking_first_ref} has been deployed prior to adopting Shared File Systems services.
 
 .Procedure
 ifeval::["{build}" != "downstream"]

docs_user/modules/proc_deploying-the-block-storage-services.adoc

@@ -11,7 +11,7 @@ you must apply the patch and wait for the operator to apply the changes and depl
 
 * Previous Adoption steps completed. Notably, {block_storage} must have been
 stopped and the service databases must already be imported into the control plane MariaDB.
-* Keystone and Barbican should be already adopted.
+* {identity_service_first_ref} and {key_manager_first_ref} should be already adopted.
 * Storage network has been properly configured on the {OpenShiftShort} cluster.
 * You need the contents of `cinder.conf` file. Download the file so that you can access it locally:
 +
@@ -198,5 +198,5 @@ openstack --os-volume-api-version 3.47 volume create --backup backup restored
 ----
 
 [NOTE]
-You do not boot a nova instance using the new volume from image or try to detach the old volume because nova and the {block_storage} are still not connected.
+You do not boot a {compute_service_first_ref} instance using the new volume from image or try to detach the old volume because {compute_service} and the {block_storage} are still not connected.
 

docs_user/modules/proc_migrating-databases-to-mariadb-instances.adoc

@@ -151,10 +151,10 @@ oc run mariadb-client --image $MARIADB_IMAGE -i --rm --restart=Never -- \
 ----
 +
 [NOTE]
-You need to transition Nova services imported later on into a
+You need to transition {compute_service_first_ref} services imported later on into a
 superconductor architecture. For that, delete the old service records in
 cells DBs, starting from the cell1. New records will be registered with
-different hostnames provided by the Nova service operator. All Nova
+different hostnames provided by the {compute_service} service operator. All {compute_service}
 services, except the compute agent, have no internal state, and its service
 records can be safely deleted. You also need to rename the former `default` cell
 to `cell1`.
@@ -261,7 +261,7 @@ default=$(grep -E ' default$' <<<$left_behind)
 test $(grep -Ec ' \S+$' <<<$changed) -eq 1
 grep -qE " $(awk '{print $1}' <<<$default) cell1$" <<<$changed
 
-# ensure the registered Nova compute service name has not changed
+# ensure the registered Compute service name has not changed
 novadb_svc_records=$(oc exec openstack-cell1-galera-0 -c galera -- mysql -rs -uroot "-p$PODIFIED_DB_ROOT_PASSWORD" \
   nova_cell1 -e "select host from services where services.binary='nova-compute' order by host asc;")
 diff -Z <(echo $novadb_svc_records) <(echo $PULL_OPENSTACK_CONFIGURATION_NOVA_COMPUTE_HOSTNAMES)

docs_user/modules/proc_migrating-ovn-data.adoc

@@ -4,15 +4,15 @@
 
 This document describes how to move OVN northbound and southbound databases
 from the original {rhos_prev_long} deployment to `ovsdb-server` instances running in the {OpenShift} cluster.
-While it may be argued that the control plane Neutron ML2/OVN driver and OVN northd service will reconstruct the databases on startup, the reconstruction may be time consuming on large existing clusters. The procedure below allows to speed up data migration and avoid unnecessary data plane disruptions due to incomplete OpenFlow table contents.
+While it may be argued that the control plane {networking_first_ref} ML2/OVN driver and OVN northd service will reconstruct the databases on startup, the reconstruction may be time consuming on large existing clusters. The procedure below allows to speed up data migration and avoid unnecessary data plane disruptions due to incomplete OpenFlow table contents.
 
 .Prerequisites
 
 * Make sure the previous Adoption steps have been performed successfully.
  ** The `OpenStackControlPlane` resource must be already created at this point.
  ** NetworkAttachmentDefinition custom resource definitions (CRDs) for the original cluster are already
 defined. Specifically, `openstack/internalapi` network is defined.
- ** Control plane MariaDB and RabbitMQ may already run. Neutron and OVN are not running yet.
+ ** Control plane MariaDB and RabbitMQ may already run. The {networking} and OVN are not running yet.
  ** Original OVN is older or equal to the control plane version.
  ** Original Neutron Server and OVN northd services are stopped.
  ** There must be network routability between:

docs_user/modules/proc_performing-a-fast-forward-upgrade-on-compute-services.adoc

@@ -109,7 +109,7 @@ oc exec -it nova-cell0-conductor-0 -- nova-manage db online_data_migrations
 oc exec -it nova-cell1-conductor-0 -- nova-manage db online_data_migrations
 ----
 
-. Discover Nova compute hosts in the cell:
+. Discover Compute hosts in the cell:
 +
 ----
 oc rsh nova-cell0-conductor-0 nova-manage cell_v2 discover_hosts --verbose

docs_user/modules/proc_stopping-infrastructure-management-and-compute-services.adoc

@@ -5,7 +5,7 @@
 The source cloud's control plane can be decomissioned,
 which is taking down only cloud controllers, database and messaging nodes.
 Nodes that must remain functional are those running the Compute, storage,
-or networker roles (in terms of composable roles covered by Tripleo Heat
+or networker roles (in terms of composable roles covered by {OpenStackPreviousInstaller} Heat
 Templates).
 
 .Prerequisites

docs_user/modules/proc_stopping-openstack-services.adoc

@@ -17,9 +17,9 @@ Note that you should not stop the infrastructure management services yet, such a
 * RabbitMQ
 * HAProxy Load Balancer
 * ceph-nfs
-* Nova compute service
+* Compute service
 * containerized modular libvirt daemons
-* Swift storage backend services
+* {object_storage_first_ref} backend services
 
 .Prerequisites