edit pass: azure-operator-service-manager-best-practices

Author: ShawnJackson

articles/operator-service-manager/best-practices-onboard-deploy.md

@@ -121,7 +121,7 @@ Here's the breakdown of resources:
 - **NFDV**: As needed based on use cases that trigger NFDV minor or major version updates.
 - **NSDG**: Single. Combines the NFs and the Kubernetes cluster definitions.
 - **NSDV**: As needed based on the use cases that trigger NSDV minor or major version updates.
-- **CGS**: Single. We recommend that the CGS has subsections for each component and infrastructure being deployed for easier management, and that it includes the versions for NFDs.
+- **CGS**: Single. For easier management, we recommend that the CGS has subsections for each component and infrastructure that you're deploying. We also recommend that the CGS includes the versions for NFDs.
 - **CGV**: Single based on the number of CGSs.
 - **SNS**: Single per NSDV.
 

articles/operator-service-manager/configuration-guide.md

@@ -110,7 +110,7 @@ Consider the following meta-schema guidelines when you're designing three-CGS ob
   A rule of thumb is to expose those parameters by using a direct operation, such as a compute tier or Helm value. Use this approach as opposed to a parameter that another agent acts on, such as `cloudinit` user data.
 * Sort the parameters into site-specific, instance-specific, and security-specific sets.
 * Define required versus optional parameters. For optional parameters, define a reasonable default value.
-* Ensure that paramters don't overlap between CGS objects.
+* Ensure that parameters don't overlap between CGS objects.
 
 This example shows a sample CGS payload:
 

articles/operator-service-manager/helm-requirements.md

@@ -18,7 +18,7 @@ Upon execution of a Helm operation, the charts are rendered into Kubernetes mani
 
 Every Helm chart generally requires `registryPath` and `imagePullSecrets` parameters. Most commonly, you expose these parameters in the `values.yaml` file.
 
-At first, Azure Operator Service Manager depended on publishers managing these values in a strict manner (legacy approach), to be substituted for the proper Azure values during deployment. But not all publishers could easily comply with the strict management of these values. Some charts hide `registryPath` and/or `imagePullSecrets` behind conditionals, or other value restrictions, which were not always met. Some charts declare `registryPath` and/or `imagePullSecrets` as an array instead of as the expected named string.
+At first, Azure Operator Service Manager depended on publishers managing these values in a strict manner (legacy approach), to be substituted for the proper Azure values during deployment. But not all publishers could easily comply with the strict management of these values. Some charts hide `registryPath` and/or `imagePullSecrets` behind conditionals, or other value restrictions, which weren't always met. Some charts declare `registryPath` and/or `imagePullSecrets` as an array instead of as the expected named string.
 
 To reduce the compliance requirements on publishers, Azure Operator Service Manager introduced two improved methods: `injectArtifactStoreDetail` and cluster registry. These newer methods don't depend on `registryPath` or `imagePullSecrets` appearing in the Helm package. Instead, these methods use a webhook to inject proper Azure values directly into pod operations.
 

articles/operator-service-manager/publisher-resource-preview-management.md

@@ -68,7 +68,7 @@ To change the state of an artifact manifest resource, use the following Azure CL
     --state Uploaded
 ```
 
-## NFDV and NSDV states
+## NFDV and NSDV state machine
 
 - **Preview** is the default state.
 - **Deprecated** is a terminal state but can be reversed.