Review suggestions

Co-authored-by: Katie Gilligan <kgilliga@redhat.com>

Author: cschwede

docs_user/assemblies/assembly_migrating-the-object-storage-service.adoc

@@ -8,14 +8,14 @@ ifdef::context[:parent-context: {context}]
 = Migrating the {object_storage} to {rhos_long_noacro} nodes
 
 [role="_abstract"]
-If you are using the {rhos_prev_long} {object_storage_first_ref} as an Object Storage service, you must migrate your Object Storage service to {rhos_long_noacro} nodes.
+If you are using the {rhos_prev_long} {object_storage_first_ref} as an Object Storage service, you must migrate your Object Storage service to {rhos_long} nodes.
 
 If you are using the Object Storage API of the Ceph Object Gateway (RGW), you can skip this chapter and migrate your Red Hat Ceph Storage cluster. For more information, see "Migrating the {Ceph} cluster". If you are not planning to migrate Ceph daemons from Controller nodes, you must perform the steps that are described in "Deploying a Ceph ingress daemon" and "Create or update the Object Storage service endpoints".
 
 You have two options for handling the existing {object_storage} storage nodes:
 
-* *Migrate data to new {rhos_acro} nodes* -- Provision new storage nodes on {rhocp_long} and gradually move data using `swift-ring-tool`.
-* *Convert existing nodes to data plane nodes* -- Keep the data on the same nodes and convert them to data plane nodes managed by the EDPM operator. No data movement is required.
+* *Migrate data to new {rhos_acro} nodes* : Provision new storage nodes on {rhocp_long} and gradually move data by using the `swift-ring-tool`.
+* *Convert existing nodes to data plane nodes*: Keep the data on the same nodes and convert them to data plane nodes that are managed by the data plane operator. 
 
 The data migration happens replica by replica. For example, if you have 3 replicas, move them one at a time to ensure that the other 2 replicas are still operational, which enables you to continue to use the {object_storage} during the migration.
 

docs_user/modules/proc_adopting-the-object-storage-service.adoc

@@ -136,6 +136,6 @@ Hello World!
 
 After the initial adoption, the {object_storage} data is still stored on the existing {OpenStackShort} nodes. You have two options for handling these storage nodes:
 
-* *Migrate data to new {rhos_acro} nodes* -- Provision new storage nodes on {rhocp_long} and gradually move data using `swift-ring-tool`. For more information, see xref:migrating-object-storage-data-to-rhoso-nodes_migrate-object-storage-service[Migrating the {object_storage_first_ref} data from {OpenStackShort} to {rhos_long} nodes].
+* *Migrate data to new {rhos_acro} nodes*: Provision new storage nodes on {rhocp_long} and gradually move data by using the `swift-ring-tool`. For more information, see xref:migrating-object-storage-data-to-rhoso-nodes_migrate-object-storage-service[Migrating the {object_storage_first_ref} data from {OpenStackShort} to {rhos_long} nodes].
 
-* *Convert existing nodes to dataplane nodes* -- Keep the data on the same nodes and convert them to dataplane nodes managed by the openstack-operators. No data movement is required. For more information, see xref:converting-object-storage-nodes[Converting {object_storage} storage nodes].
+* *Convert existing nodes to dataplane nodes*: Keep the data on the same nodes and convert them to data plane nodes that are managed by the `openstack-operators`. For more information, see xref:converting-object-storage-nodes[Converting {object_storage} storage nodes].

docs_user/modules/proc_converting-object-storage-nodes.adoc

@@ -7,35 +7,34 @@
 If you used external {object_storage} storage nodes, you can convert these
 nodes after the initial {object_storage_first_ref} adoption is complete. This
 step reconfigures the nodes in-place while keeping the {object_storage}
-available throughout the process.
-
-.Key concepts
-* *Pre-provisioned nodes*: Setting `preProvisioned: true` in the
-  `OpenStackDataPlaneNodeSet` skips provisioning the node from scratch and does
-  not reinstall the operating system.
-* *{object_storage} disk and mount preservation*: `edpm_swift_disks: []` must be
-  set in *both* the `nodeTemplate` *and* in the individual node definition under
-  `nodes` to ensure that no disks are formatted or mounted differently, leaving
-  existing disk mounts untouched. The `SwiftRawDisks` parameter from
-  {OpenStackPreviousInstaller} is not migrated or converted -- disks on
+available throughout the process. 
+
+Before you begin, review the following key concepts:
+Pre-provisioned nodes:: Setting `preProvisioned: true` in the
+  `OpenStackDataPlaneNodeSet` custom resource (CR) skips provisioning the node from scratch and does not reinstall the operating system.
+{object_storage} disk and mount preservation:: `edpm_swift_disks: []` must be
+  set in both the `nodeTemplate` and in the individual node definition under
+  `nodes` to ensure that no disks are formatted or mounted differently. 
+  Existing disk mounts are untouched. The `SwiftRawDisks` parameter from
+  {OpenStackPreviousInstaller} is not migrated or converted. Disks on
   converted nodes must be managed manually.
-* *Rolling conversion with multiple node sets*: In production, do not convert
+Rolling conversion with multiple node sets:: In production, do not convert
   all {object_storage} nodes at once. Instead, create separate
-  `OpenStackDataPlaneNodeSet` resources and deploy them sequentially.  Align
+  `OpenStackDataPlaneNodeSet` custom resources and deploy them sequentially.  Align
   groups with ring zones or regions so that no more than one replica of any
   partition is affected during the conversion.
 
 .Prerequisites
 
 * The initial {object_storage} adoption is complete. For more information, see
-  xref:adopting-the-object-storage-service[Adopting the
+  xref:adopting-the-object-storage-service_hsm-integration[Adopting the
   {object_storage}].
 
 .Procedure
 
-. Create a cleanup `OpenStackDataPlaneService` CR to remove remaining
-  {OpenStackPreviousInstaller} artifacts (containers, systemd units,
-  configuration) from the node:
+. Create a `OpenStackDataPlaneService` custom resource (CR) to remove remaining
+  {OpenStackPreviousInstaller} artifacts, such as containers, `systemd` units, and
+  configuration, from the node:
 +
 ----
 $ oc apply -f - <<EOF
@@ -50,7 +49,7 @@ EOF
 ----
 
 ifeval::["{build}" == "upstream"]
-. Create a repo-setup `OpenStackDataPlaneService` CR to configure RPM repositories on the node:
+. Create a `OpenStackDataPlaneService` CR to configure RPM repositories on the node:
 +
 ----
 $ oc apply -f - <<EOF
@@ -160,7 +159,6 @@ endif::[]
   - swift
   tlsEnabled: true
 ----
-+
 
 . Apply the `OpenStackDataPlaneNodeSet` CR:
 +
@@ -189,7 +187,7 @@ EOF
 $ oc wait --for condition=Ready openstackdataplanedeployment/openstack-edpm-ipam --timeout=30m
 ----
 
-. Monitor progress:
+.. Monitor the progress:
 +
 ----
 $ watch oc get pod -l app=openstackansibleee
@@ -207,7 +205,7 @@ $ oc logs -l app=openstackansibleee -f --max-log-requests 20
 $ oc get openstackdataplanenodeset openstack-edpm-ipam
 ----
 
-* Verify that {object_storage} services are running on the converted node:
+* Verify that the Object Storage services are running on the converted node:
 +
 ----
 $ ssh cloud-admin@192.168.122.100 "sudo systemctl status edpm_swift_*"