diff --git a/content/en/docs/Tasks/creating-operator-bundle.md b/content/en/docs/Tasks/creating-operator-bundle.md index c8ddb3a9..8932d22d 100644 --- a/content/en/docs/Tasks/creating-operator-bundle.md +++ b/content/en/docs/Tasks/creating-operator-bundle.md @@ -74,7 +74,7 @@ etcd The `annotations.yaml` contains the following information as labels that are used to annotate the operator bundle container image: * The label `operators.operatorframework.io.bundle.mediatype.v1` reflects the media type or format of the operator bundle. It could be helm charts, plain Kubernetes manifests etc. -* The label `operators.operatorframework.io.bundle.manifests.v1 `reflects the path in the image to the directory that contains the operator manifests. This label is reserved for the future use and is set to `manifests/` for the time being. +* The label `operators.operatorframework.io.bundle.manifests.v1` reflects the path in the image to the directory that contains the operator manifests. This label is reserved for the future use and is set to `manifests/` for the time being. * The label `operators.operatorframework.io.bundle.metadata.v1` reflects the path in the image to the directory that contains metadata files about the bundle. This label is reserved for the future use and is set to `metadata/` for the time being. * The `manifests.v1` and `metadata.v1` labels imply the bundle type: * The value `manifests.v1` implies that this bundle contains operator manifests. diff --git a/content/en/docs/Tasks/creating-operator-manifests.md b/content/en/docs/Tasks/creating-operator-manifests.md index fc4f84d8..e18c1fbd 100644 --- a/content/en/docs/Tasks/creating-operator-manifests.md +++ b/content/en/docs/Tasks/creating-operator-manifests.md @@ -240,7 +240,7 @@ The absence of any required `nativeAPIs` from a cluster will pause the installat TODO: example status -`nativeAPIs` is an optional field, but the more information you give OLM about the context in which your operator should be run, the more informed decisions OLM can make. +`nativeAPIs` is an optional field, but the more information you give OLM about the context in which your operator should be running, the more informed decisions OLM can make. ## Packaging Additional Objects Alongside an Operator @@ -257,7 +257,7 @@ Operators can include additional objects alongside their `CSV` in the `/manifest - PrometheusRule - ServiceMonitor - [PodDisruptionBudget](https://github.com/operator-framework/operator-lifecycle-manager/blob/master/doc/design/adding-pod-disruption-budgets.md) -- [PriorityClasse](https://github.com/operator-framework/operator-lifecycle-manager/blob/master/doc/design/adding-priority-classes.md) +- [PriorityClass](https://github.com/operator-framework/operator-lifecycle-manager/blob/master/doc/design/adding-priority-classes.md) - [VerticalPodAutoscaler](https://github.com/operator-framework/operator-lifecycle-manager/blob/master/doc/design/adding-vertical-pod-autoscaler.md) - ConsoleYAMLSample - ConsoleQuickStart diff --git a/content/en/docs/Tasks/install-operator-with-olm.md b/content/en/docs/Tasks/install-operator-with-olm.md index a4c0590c..58320564 100644 --- a/content/en/docs/Tasks/install-operator-with-olm.md +++ b/content/en/docs/Tasks/install-operator-with-olm.md @@ -134,7 +134,7 @@ spec: Notice that `approval` has been set to `Manual` as well in order to keep OLM from immediately updating your Operator, if `1.1.0` happens to be superseded by a newer version in `my-catalog`. Follow the instructions from the [previous example](#example-install-the-latest-version-of-an-operator) to approve the initial `InstallPlan` for this `Subscription`, so `1.1.0` is allowed to be installed. -If your intent is to pin an installed Operator to the particular version `1.1.0` you don't need to do anything. After approving the initial `InstallPlan` OLM will install version `1.1.0` of your Operator and keep it at that version. When updates are discovered in the catalog, OLM will wait not proceed unless you manual approve the update. +If your intent is to pin an installed Operator to the particular version `1.1.0` you don't need to do anything. After approving the initial `InstallPlan` OLM will install version `1.1.0` of your Operator and keep it at that version. When updates are discovered in the catalog, OLM will wait not proceed unless you manually approve the update. [create-catsrc-doc]: /docs/tasks/make-catalog-available-on-cluster [subscription-doc]: /docs/concepts/crds/subscription