restructuring ctl plane pt 3

docs_user/assemblies/assembly_adopting-openstack-control-plane-services.adoc

@@ -24,4 +24,6 @@ include::../assemblies/assembly_adopting-the-shared-file-systems-service.adoc[le
 
 include::../modules/proc_adopting-telemetry-services.adoc[leveloffset=+1]
 
-include::../modules/proc_adopting-autoscaling.adoc[leveloffset=+1]
+include::../modules/proc_adopting-autoscaling.adoc[leveloffset=+1]
+
+include::../modules/proc_rolling-back-the-control-plane-adoption.adoc[leveloffset=+1]

docs_user/assemblies/openstack_adoption.adoc

@@ -16,7 +16,6 @@ include::../modules/openstack-ironic_adoption.adoc[leveloffset=+1]
 include::../modules/openstack-heat_adoption.adoc[leveloffset=+1]
 include::../modules/openstack-stop_remaining_services.adoc[leveloffset=+1]
 include::../modules/openstack-dataplane_adoption.adoc[leveloffset=+1]
-include::../modules/openstack-rolling_back.adoc[leveloffset=+1]
 
 ifdef::parent-context[:context: {parent-context}]
 ifndef::parent-context[:!context:]

docs_user/modules/openstack-rolling_back.adoc → docs_user/modules/proc_rolling-back-the-control-plane-adoption.adoc

@@ -1,41 +1,35 @@
-[id="rolling-back-control-plane_{context}"]
+[id="rolling-back-control-plane-adoption_{context}"]
 
 = Rolling back the control plane adoption
 
-If you encountered a problem during the adoption of the OpenStack
-control plane services that prevents you from following the adoption
-procedure to completion, you can roll back the control plane adoption.
+If you encountered a problem during the adoption of the {rhos_prev_long} ({OpenStackShort}) control plane services that prevents you from completing the adoption procedure, you can roll back the control plane adoption.
 
-*Important: The roll back operation is only possible during the
-control plane parts of the adoption procedure. Altering the data plane
-nodes in any way during the procedure marks the point of no return and
-the roll back is no longer possible after that.*
-
-== Overview of the rollback procedure
+[IMPORTANT]
+The roll back operation is only possible during the
+control plane parts of the adoption procedure. If you altered the data plane
+nodes in any way during the procedure, the roll back is not possible.
 
 During the control plane adoption, services on the source cloud's
 control plane are stopped but not removed. The databases on the source
 control plane are not edited by the adoption procedure. The
-destination podified control plane received a copy of the original
+destination control plane received a copy of the original
 control plane databases. The roll back procedure assumes that the data
 plane has not yet been touched by the adoption procedure and it is
 still connected to the source control plane.
 
-The rollback procedure therefore consists of:
+The rollback procedure consists of the following steps:
 
 * Restoring the functionality of the source control plane.
 
-* Removing the partially or fully deployed destination podified
+* Removing the partially or fully deployed destination
   control plane.
 
-== Control plane rollback procedure
-
-=== Restoring the source control plane
+.Procedure
 
-To restore the source cloud to a working state, start the OpenStack
+. To restore the source cloud to a working state, start the {OpenStackShort}
 control plane services that you previously stopped during the adoption
 procedure:
-
++
 ----
 ServicesToStart=("tripleo_horizon.service"
                  "tripleo_keystone.service"
@@ -142,28 +136,23 @@ for i in {1..3}; do
 done
 ----
 
-If the Ceph NFS service is running on the deployment as a OpenStack Manila
+. If the Ceph NFS service is running on the deployment as a {rhos_component_storage_file_first_ref}
 backend, you must restore the pacemaker ordering and colocation constraints
 involving the "openstack-manila-share" service:
-
++
 ----
 
 sudo pcs constraint order start ceph-nfs then openstack-manila-share kind=Optional id=order-ceph-nfs-openstack-manila-share-Optional
 sudo pcs constraint colocation add openstack-manila-share with ceph-nfs score=INFINITY id=colocation-openstack-manila-share-ceph-nfs-INFINITY
 
 ----
 
-Now you can verify that the source cloud is operational again, e.g. by
-running `openstack` CLI commands or using the Horizon Dashboard.
-
-=== Removing the podified control plane
-
-After restoring the original control plane functionality, the
-partially or fully deployed podified control plane should be removed:
-so that another adoption attempt can be made later.
-
-To delete the podified control plane:
+. Verify that the source cloud is operational again, e.g. by
+running `openstack` CLI commands or using the {dashboard_first_ref}.
+//kgilliga: Should we be more specific? Which CLI commands?
 
+. Remove the partially or fully deployed control plane so that another adoption attempt can be made later:
++
 ----
 oc delete --ignore-not-found=true --wait=false openstackcontrolplane/openstack
 oc patch openstackcontrolplane openstack --type=merge --patch '
@@ -184,13 +173,14 @@ oc delete --ignore-not-found=true --wait=false pod ovn-copy-data
 oc delete --ignore-not-found=true secret osp-secret
 ----
 
-== Before retrying the adoption procedure
-
+[NOTE]
 Since restoring the source control plane services, their internal
 state may have changed. Before retrying the adoption procedure, it is
-important to verify that the podified control plane resources have
+important to verify that the control plane resources have
 been removed and there are no leftovers which could affect the
 following adoption procedure attempt. Notably, the previously created
 copies of the database contents must not be used in another adoption
 attempt, and new copies must be made according to the adoption
 procedure documentation.
+
+//kgilliga: How do users verify that the control plane resources have all been removed?