Merge pull request #1420 from klgill/copy-short-description-upstream

syncing short descriptions with downstream repo

Author: openshift-merge-bot[bot]

docs_user/assemblies/assembly_adopting-key-manager-service-with-hsm.adoc

@@ -8,7 +8,7 @@ ifdef::context[:parent-context: {context}]
 = Adopting the {key_manager} with HSM integration
 
 [role="_abstract"]
-Adopt the {key_manager_first_ref} from {OpenStackPreviousInstaller} to {rhos_long} when your source environment includes hardware security module (HSM) integration to preserve HSM functionality and maintain access to HSM-backed secrets. HSM provides enhanced security for cryptographic operations by storing encryption keys in dedicated hardware devices.
+Adopt the {key_manager_first_ref} with HSM integration to {rhos_long} to preserve HSM functionality and maintain access to HSM-backed secrets.
 
 For additional information about the {key_manager} before you start the adoption, see the following resources:
 

docs_user/assemblies/assembly_adopting-the-shared-file-systems-service.adoc

@@ -8,9 +8,9 @@ ifdef::context[:parent-context: {context}]
 = Adopting the {rhos_component_storage_file}
 
 [role="_abstract"]
-The {rhos_component_storage_file_first_ref} in {rhos_long} provides a self-service API to create and manage file shares. File shares (or "shares"), are built for concurrent read/write access from multiple clients. This makes the {rhos_component_storage_file} essential in cloud environments that require a ReadWriteMany persistent storage.
+The {rhos_component_storage_file_first_ref} provides a self-service API to create and manage file shares. File shares are built for concurrent read/write access from multiple clients, making the Shared File Systems service in cloud environments that require a ReadWriteMany persistent storage.
 
-File shares in {rhos_acro} require network access. Ensure that the networking in the {rhos_prev_long} ({OpenStackShort}) {rhos_prev_ver} environment matches the network plans for your new cloud after adoption. This ensures that tenant workloads remain connected to storage during the adoption process. The {rhos_component_storage_file} control plane services are not in the data path. Shutting down the API, scheduler, and share manager services do not impact access to existing shared file systems.
+File shares in {rhos_acro} require network access. Ensure that network plans match the {rhos_prev_long} environment to maintain tenant connectivity during adoption. The {rhos_component_storage_file} control plane services are not in the data path. Shutting down the API, scheduler, and share manager services do not impact access to existing shared file systems.
 
 Typically, storage and storage device management are separate networks. Shared File Systems services only need access to the storage device management network.
 For example, if you used a {CephCluster} cluster in the deployment, the "storage"

docs_user/assemblies/assembly_migrating-ceph-rbd.adoc

@@ -9,10 +9,9 @@ ifdef::context[:parent-context: {context}]
 
 [role="_abstract"]
 For Hyperconverged Infrastructure (HCI) or dedicated Storage nodes that are
-running {Ceph} {CephVernum} or later, you must migrate the daemons that are
-included in the {rhos_prev_long} control plane into the existing external Red
-Hat Enterprise Linux (RHEL) nodes. The external RHEL nodes typically include
-the Compute nodes for an HCI environment or dedicated storage nodes.
+running {Ceph} {CephVernum} or later, migrate the daemons from the {rhos_prev_long} control plane into the existing external Red Hat Enterprise Linux (RHEL) nodes.
+
+The external RHEL nodes typically include the Compute nodes for an HCI environment or dedicated storage nodes.
 
 == Prerequisites
 Before you begin the migration, complete the tasks in your {rhos_prev_long} {rhos_prev_ver} environment. For more information, see the "{Ceph} prerequisites" in the "Adoption overview" chapter.

docs_user/assemblies/assembly_migrating-ceph-rgw.adoc

@@ -8,7 +8,9 @@ ifdef::context[:parent-context: {context}]
 = Migrating {Ceph} RGW to external RHEL nodes
 
 [role="_abstract"]
-For Hyperconverged Infrastructure (HCI) or dedicated Storage nodes, you must migrate the Ceph Object Gateway (RGW) daemons that are included in the {rhos_prev_long} Controller nodes into the existing external Red Hat Enterprise Linux (RHEL) nodes. The external RHEL nodes typically include the Compute nodes for an HCI environment or {Ceph} nodes. Your environment must have {Ceph} {CephVernum} or later and be managed by `cephadm` or Ceph Orchestrator.
+For Hyperconverged Infrastructure (HCI) or dedicated Storage nodes, migrate the Ceph Object Gateway (RGW) daemons from the {rhos_prev_long} Controller nodes into the existing external Red Hat Enterprise Linux (RHEL) nodes.
+
+The RHEL nodes include the Compute nodes for an HCI environment or {Ceph} nodes. Your environment must have {Ceph} {CephVernum} or later and be managed by `cephadm` or Ceph Orchestrator.
 
 == Prerequisites
 

docs_user/assemblies/assembly_migrating-mon-from-controller-nodes.adoc

@@ -8,8 +8,9 @@ ifdef::context[:parent-context: {context}]
 :context: migrating-ceph-mon
 
 [role="_abstract"]
-You must move Ceph Monitor daemons from the {rhos_prev_long} ({OpenStackShort}) Controller nodes to a set of target nodes. Target nodes are either existing {Ceph} nodes, or {OpenStackShort} Compute nodes if {Ceph} is
-deployed by {OpenStackPreviousInstaller} with a Hyperconverged Infrastructure (HCI) topology. Additional Ceph Monitors are deployed to the target nodes, and they are promoted as `_admin` nodes that you can use to manage the {CephCluster} cluster and perform day 2 operations.
+Move Ceph Monitor daemons from the {rhos_prev_long} ({OpenStackShort}) Controller nodes to a set of existing {Ceph} nodes, or to a set of {OpenStackShort} Compute nodes if {Ceph} is deployed by {OpenStackPreviousInstaller} with a Hyperconverged Infrastructure (HCI) topology.
+
+Additional Ceph Monitors are deployed to the target nodes and promoted as _admin nodes to manage the {CephCluster} cluster and perform day 2 operations.
 
 To migrate the Ceph Monitor daemons, you must perform the following high-level steps:
 

docs_user/assemblies/assembly_rhoso-180-adoption-overview.adoc

@@ -8,7 +8,9 @@ ifdef::context[:parent-context: {context}]
 = {rhos_long_noacro} {rhos_curr_ver} adoption overview
 
 [role="_abstract"]
-Adoption is the process of migrating a {rhos_prev_long} ({OpenStackShort}) {rhos_prev_ver} control plane to {rhos_long_noacro} {rhos_curr_ver}, and then completing an in-place upgrade of the data plane. You can retain existing infrastructure investments and modernize your {OpenStackShort} deployment on a containerized {rhocp_long} foundation. To ensure that you understand the entire adoption process and how to sufficiently prepare your {OpenStackShort} environment, review the prerequisites, adoption process, and post-adoption tasks.
+Adoption is the process of migrating a {rhos_prev_long} {rhos_prev_ver} control plane to {rhos_long_noacro} {rhos_curr_ver} and upgrading the data plane in-place. Retain existing infrastructure investments and modernize your {OpenStackShort} deployment on a containerized {rhocp_long} foundation.
+
+To understand the adoption process and to prepare your {OpenStackShort} environment, review the prerequisites, adoption process, and post-adoption tasks.
 
 [IMPORTANT]
 Read the whole adoption guide before you start

docs_user/modules/con_adopting-spine-leaf-networks.adoc

@@ -4,9 +4,9 @@
 = Configuring spine-leaf networks for the {rhos_long_noacro} deployment
 
 [role="_abstract"]
-When you adopt a {rhos_prev_long} ({OpenStackShort}) deployment with spine-leaf networking, like a Distributed Compute Node (DCN) architecture, you must each L2 network segment with a separate IP subnet and create create routed provider networks. Traffic between sites is routed at L3 through spine routers or similar network infrastructure.
+When you adopt a {rhos_prev_long} ({OpenStackShort}) deployment with spine-leaf networking, such as a Distributed Compute Node (DCN) architecture, adopt each L2 network segment with a separate IP subnet and create routed provider networks.
 
-You must configure routing for Compute nodes at edge sites to connect with control plane services, such as RabbitMQ or the database at the central site. The cloud will not function correctly without routes configured.
+Traffic between sites is routed at L3 through spine routers or similar network infrastructure. You must configure routing for Compute nodes at edge sites to connect with control plane services, such as RabbitMQ or the database at the central site. The cloud will not function correctly without routes configured.
 
 [NOTE]
 ====

docs_user/modules/con_adoption-guidelines.adoc

@@ -4,7 +4,7 @@
 = Guidelines for planning the adoption
 
 [role="_abstract"]
-When planning to adopt a {rhos_long} {rhos_curr_ver} environment, consider the scope of the change. An adoption is similar in scope to a data center upgrade. Different firmware levels, hardware vendors, hardware profiles, networking interfaces, storage interfaces, and so on affect the adoption process and can cause changes in behavior during the adoption.
+Adoption is similar in scope to a data center upgrade. Different firmware levels, hardware vendors, hardware profiles, networking interfaces, and storage interfaces can affect the adoption process and change behavior.
 
 Review the following guidelines to adequately plan for the adoption and increase the chance that you complete the adoption successfully:
 

docs_user/modules/con_preparing-the-shared-file-systems-service-configuration.adoc

@@ -4,7 +4,7 @@
 = Guidelines for preparing the {rhos_component_storage_file} configuration
 
 [role="_abstract"]
-To deploy {rhos_component_storage_file_first_ref} on the control plane, you must copy the original configuration file from the {rhos_prev_long} {rhos_prev_ver} deployment. You must review the content in the file to make sure you are adopting the correct configuration for {rhos_long} {rhos_curr_ver}. Not all of the content needs to be brought into the new cloud environment.
+Copy the {rhos_component_storage_file_first_ref} configuration from {rhos_prev_long} {rhos_prev_ver}, and review it to ensure that you copy the correct configuration for {rhos_long} {rhos_curr_ver}.
 
 Review the following guidelines for preparing your {rhos_component_storage_file} configuration file for adoption:
 

docs_user/modules/con_preventing-config-loss-when-using-oc-patch.adoc

@@ -4,9 +4,9 @@
 = Preventing configuration loss when using the `oc patch` command
 
 [role="_abstract"]
-When you use the `oc patch` command to modify a resource, the changes are applied directly to the live object in your OpenShift cluster. If you later edit the custom resource (CR) file for the resource and apply the updates by using `oc apply -f <filename>`, your previous patched changes are overwritten and lost from the resource.
+When you use `oc patch` to modify a resource, the changes are applied directly to live objects in your OpenShift cluster. If you later apply updates to the custom resource (CR) file by using `oc apply -f <filename>`, your previous patched changes are overwritten and lost from the resource.
 
-To prevent loss of configuration, you can use the `--patch-file` option to configure the patch and retain patch files. Alternatively, you can export your `openstackcontrolplane` CR after the patch is applied:
+To prevent configuration loss, use the `--patch-file` option or export your `openstackcontrolplane` CR after the patch is applied.
 
 ----
 $ oc get <resource_type> <resource_name> -o yaml > <filename>.yaml