Ceph NFS doc: Apply suggestions from code review

Co-authored-by: Katie Gilligan <[email protected]>

Author: gouthampacha

docs_user/modules/con_changes-to-cephFS-via-NFS.adoc

@@ -14,9 +14,9 @@ Before you begin the adoption, review the following information to understand th
 
 * To ensure that NFS users are not required to make any networking changes to their existing workloads, assign an IP address from the same isolated `StorageNFS` network to the clustered Ceph NFS service. NFS users only need to discover and re-mount their shares by using new export paths. When the adoption is complete, {rhos_acro} users can query the {rhos_component_storage_file} API to list the export locations on existing shares to identify the preferred paths to mount these shares. These preferred paths correspond to the new clustered Ceph NFS service in contrast to other non-preferred export paths that continue to be displayed until the old isolated, standalone NFS service is decommissioned.
 
-* When migrating, users must ensure that exports are not consumed from both the old NFS service as well as the new clustered Ceph NFS service at the same time. This simultaneous access is considered dangerous and bypasses the protections for concurrent access ensured by the NFS protocol. When migrating the workloads to use exports from the new NFS service, care must be taken to migrate the use of each export entirely so that no part of the workload stays connected to the old NFS service.
+* When you migrate your workloads from the old NFS service, you must ensure that exports are not consumed from both the old NFS service and the new clustered Ceph NFS service at the same time. This simultaneous access to both services is considered dangerous and bypasses the protections for concurrent access that is ensured by the NFS protocol. When you migrate the workloads to use exports from the new NFS service, you must ensure that you migrate the use of each export entirely so that no part of the workload stays connected to the old NFS service.
 
-* You can no longer control the old Pacemaker-managed `ceph-nfs` service through the {rhos_prev_long} {OpenStackPreviousInstaller} after the control plane adoption is complete. This means that there is no support for updating the NFS Ganesha software, or changing any configuration. While data is protected in case of server crashes or restarts, high availability and data recovery is still very limited, and these maintenance issues are no longer visible to {rhos_component_storage_file}.
+* You can no longer control the old Pacemaker-managed `ceph-nfs` service through the {rhos_prev_long} {OpenStackPreviousInstaller} after the control plane adoption is complete. This means that there is no support for updating the NFS Ganesha software, or changing any configuration. While data is protected from server crashes or restarts, high availability and data recovery is still limited, and these maintenance issues are no longer visible to {rhos_component_storage_file}.
 
 * Cloud administrators must ensure a reasonably short window to switch over all end-user workloads to the new NFS service.