Merge pull request #806 from marcoderama/doco

openshift-merge-robot · web-flow · commit a8cd53bb68df · 2019-05-10T00:00:13.000+02:00
documentation:  Fix a few typos.
diff --git a/Documentation/design/building-your-csv.md b/Documentation/design/building-your-csv.md
@@ -147,7 +147,7 @@ The Lifecycle Manager will check against the available CRDs and Operators in the
       description: Represents a cluster of etcd nodes.
 ```
 ## CRD Templates
-Users of your Operator will need to be aware of which options are required vs optional. You can provide templates for each of our CRDs with a minimum set of configuration as an annotation named `alm-examples`. Compatible UIs will pre-enter this template for users to further customize.
+Users of your Operator will need to be aware of which options are required vs optional. You can provide templates for each of your CRDs with a minimum set of configuration as an annotation named `alm-examples`. Compatible UIs will pre-enter this template for users to further customize.
 
 The annotation consists of a list of the `kind`, eg. the CRD name, and the corresponding `metadata` and `spec` of the Kubernetes object. Here’s a full example that provides templates for `EtcdCluster`, `EtcdBackup` and `EtcdRestore`:
 
@@ -238,7 +238,7 @@ The metadata section contains general metadata around the name, version and othe
 
 **Selectors** (optional): A label selector to identify related resources. Set this to select on current labels applied to this CSV object (if applicable).
 
-**InstallModes**: A set of `InstallMode`s that tell OLM which `OperatorGroup`s an Operator can belong to. Belonging to an `OperatorGroup` means that OLM provides the set of targetted namespaces as an annotation on the Operator's CSV and any deployments defined therin. These deployments can then untilize [the Downward API](https://kubernetes.io/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#the-downward-api) to inject the list of namespaces into its container(s). An `InstallMode` consists of an `InstallModeType` field and a boolean `Supported` field. There are four `InstallModeTypes`: 
+**InstallModes**: A set of `InstallMode`s that tell OLM which `OperatorGroup`s an Operator can belong to. Belonging to an `OperatorGroup` means that OLM provides the set of targeted namespaces as an annotation on the Operator's CSV and any deployments defined therein. These deployments can then utilize [the Downward API](https://kubernetes.io/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#the-downward-api) to inject the list of namespaces into their container(s). An `InstallMode` consists of an `InstallModeType` field and a boolean `Supported` field. There are four `InstallModeTypes`:
 * `OwnNamespace`: If supported, the operator can be a member of an `OperatorGroup` that selects its own namespace
 * `SingleNamespace`: If supported, the operator can be a member of an `OperatorGroup` that selects one namespace
 * `MultiNamespace`: If supported, the operator can be a member of an `OperatorGroup` that selects more than one namespace
diff --git a/Documentation/design/debugging.md b/Documentation/design/debugging.md
@@ -1,6 +1,6 @@
 # Debugging a ClusterServiceVersion
 
-We have a ClusterServiceVersion that is failing to report as avialable.
+We have a ClusterServiceVersion that is failing to report as available.
 
 ```sh
 $ kubectl -n ci-olm-pr-188-gc-csvs get clusterserviceversions etcdoperator.v0.8.1 -o yaml
diff --git a/Documentation/design/operatorgroups.md b/Documentation/design/operatorgroups.md
@@ -5,7 +5,7 @@ An `OperatorGroup` is an OLM resource that provides rudimentary multitenant conf
 ## OperatorGroup Overview
 
 * An `OperatorGroup` selects a set of target namespaces in which to generate required RBAC access for its member operators.
-* The set of target namespaces is provided via a comma-delimited string stored in the `olm.targetNamespaces` annotation. This annotation is applied to member operator's `ClusterServiceVersion` (CSV) instances and is projected into their deployments. It accessible to operator containers using [The Downward API](https://kubernetes.io/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#the-downward-api)
+* The set of target namespaces is provided via a comma-delimited string stored in the `olm.targetNamespaces` annotation. This annotation is applied to member operator's `ClusterServiceVersion` (CSV) instances and is projected into their deployments. It is accessible to operator containers using [The Downward API](https://kubernetes.io/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#the-downward-api)
 * An operator is said to be a [member of an `OperatorGroup`](#operatorgroup-membership) if its CSV exists in the same namespace as the `OperatorGroup` and its CSV's [`InstallModes` support the set of namespaces targetted by the `OperatorGroup`](#installmodes-and-supported-operatorgroups)
 * In order to transition, a CSV must be an active member of an `OperatorGroup` that has no [provided API conflicts with intersecting `OperatorGroups`](#operatorgroup-intersection)
 
@@ -128,7 +128,7 @@ When an `OperatorGroup` is created, 3 ClusterRoles each containing a single Aggr
 * `<operatorgroup-name>-edit`
   * ClusterRoleSelector set to match the `olm.opgroup.permissions/aggregate-to-edit: <operatorgroup-name>` label
 
-* `<oepratorgroup-name>-view`
+* `<operatorgroup-name>-view`
   * ClusterRoleSelector set to match the `olm.opgroup.permissions/aggregate-to-view: <operatorgroup-name>` label
 
 When a CSV becomes an active member of an `OperatorGroup` and is not in a failed state with reason InterOperatorGroupOwnerConflict, the following RBAC resources are generated:
diff --git a/README.md b/README.md
@@ -83,7 +83,7 @@ There is no way to express a dependency on a particular version of an operator (
 ## Discovery, Catalogs, and Automated Upgrades
 OLM has the concept of catalogs, which are repositories of application definitions and CRDs. 	
 
-Catalogs contain a set of Packages, which map “channels” to a particular application definition. Channels allow package authors write different upgrade paths for different users (e.g. alpha vs. stable). 
+Catalogs contain a set of Packages, which map “channels” to a particular application definition. Channels allow package authors to write different upgrade paths for different users (e.g. alpha vs. stable).
 
 Example: [etcd package](https://github.com/operator-framework/community-operators/blob/master/community-operators/etcd/etcd.package.yaml)
 
