1
0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00

Consolidate "Installing from OperatorHub" procs & Single vs AllNamespace improvements

This commit is contained in:
Alex Dellapenta
2024-07-24 13:07:58 -06:00
committed by openshift-cherrypick-robot
parent 96c84312cb
commit d1ceff6083
7 changed files with 190 additions and 304 deletions

Binary file not shown.

Before

Width:  |  Height:  |  Size: 168 KiB

View File

@@ -13,10 +13,17 @@ endif::[]
:_mod-docs-content-type: PROCEDURE
[id="olm-installing-operator-from-operatorhub-using-cli_{context}"]
= Installing from OperatorHub using the CLI
= Installing from OperatorHub by using the CLI
Instead of using the {product-title} web console, you can install an Operator from OperatorHub by using the CLI. Use the `oc` command to create or update a `Subscription` object.
For `SingleNamespace` install mode, you must also ensure an appropriate Operator group exists in the related namespace. An Operator group, defined by an `OperatorGroup` object, selects target namespaces in which to generate required RBAC access for all Operators in the same namespace as the Operator group.
[TIP]
====
In most cases, the web console method of this procedure is preferred because it automates tasks in the background, such as handling the creation of `OperatorGroup` and `Subscription` objects automatically when choosing `SingleNamespace` mode.
====
.Prerequisites
ifndef::olm-user[]
@@ -45,22 +52,25 @@ $ oc get packagemanifests -n openshift-marketplace
----
+
.Example output
[%collapsible]
====
[source,terminal]
----
NAME CATALOG AGE
3scale-operator Red Hat Operators 91m
advanced-cluster-management Red Hat Operators 91m
amq7-cert-manager Red Hat Operators 91m
...
# ...
couchbase-enterprise-certified Certified Operators 91m
crunchy-postgres-operator Certified Operators 91m
mongodb-enterprise Certified Operators 91m
...
# ...
etcd Community Operators 91m
jaeger Community Operators 91m
kubefed Community Operators 91m
...
# ...
----
====
+
Note the catalog for your desired Operator.
@@ -70,33 +80,97 @@ Note the catalog for your desired Operator.
----
$ oc describe packagemanifests <operator_name> -n openshift-marketplace
----
. An Operator group, defined by an `OperatorGroup` object, selects target namespaces in which to generate required RBAC access for all Operators in the same namespace as the Operator group.
+
The namespace to which you subscribe the Operator must have an Operator group that matches the install mode of the Operator, either the `AllNamespaces` or `SingleNamespace` mode. If the Operator you intend to install uses the `AllNamespaces` mode, the `openshift-operators` namespace already has the appropriate `global-operators` Operator group in place.
+
However, if the Operator uses the `SingleNamespace` mode and you do not already have an appropriate Operator group in place, you must create one.
+
[NOTE]
.Example output
[%collapsible]
====
* The web console version of this procedure handles the creation of the `OperatorGroup` and `Subscription` objects automatically behind the scenes for you when choosing `SingleNamespace` mode.
* You can only have one Operator group per namespace. For more information, see "Operator groups".
[source,terminal]
----
# ...
Kind: PackageManifest
# ...
Install Modes: <1>
Supported: true
Type: OwnNamespace
Supported: true
Type: SingleNamespace
Supported: false
Type: MultiNamespace
Supported: true
Type: AllNamespaces
# ...
Entries:
Name: example-operator.v3.7.11
Version: 3.7.11
Name: example-operator.v3.7.10
Version: 3.7.10
Name: stable-3.7 <2>
# ...
Entries:
Name: example-operator.v3.8.5
Version: 3.8.5
Name: example-operator.v3.8.4
Version: 3.8.4
Name: stable-3.8 <2>
Default Channel: stable-3.8 <3>
----
<1> Indicates which install modes are supported.
<2> Example channel names.
<3> The channel selected by default if one is not specified.
====
+
[TIP]
====
You can print an Operator's version and channel information in YAML format by running the following command:
[source,terminal]
----
$ oc get packagemanifests <operator_name> -n <catalog_namespace> -o yaml
----
====
.. Create an `OperatorGroup` object YAML file, for example `operatorgroup.yaml`:
** If more than one catalog is installed in a namespace, run the following command to look up the available versions and channels of an Operator from a specific catalog:
+
.Example `OperatorGroup` object
[source,terminal]
----
$ oc get packagemanifest \
--selector=catalog=<catalogsource_name> \
--field-selector metadata.name=<operator_name> \
-n <catalog_namespace> -o yaml
----
+
[IMPORTANT]
====
If you do not specify the Operator's catalog, running the `oc get packagemanifest` and `oc describe packagemanifest` commands might return a package from an unexpected catalog if the following conditions are met:
* Multiple catalogs are installed in the same namespace.
* The catalogs contain the same Operators or Operators with the same name.
====
. If the Operator you intend to install supports the `AllNamespaces` install mode, and you choose to use this mode, skip this step, because the `openshift-operators` namespace already has an appropriate Operator group in place by default, called `global-operators`.
+
If the Operator you intend to install supports the `SingleNamespace` install mode, and you choose to use this mode, you must ensure an appropriate Operator group exists in the related namespace. If one does not exist, you can create create one by following these steps:
+
[IMPORTANT]
====
You can only have one Operator group per namespace. For more information, see "Operator groups".
====
.. Create an `OperatorGroup` object YAML file, for example `operatorgroup.yaml`, for `SingleNamespace` install mode:
+
.Example `OperatorGroup` object for `SingleNamespace` install mode
[source,yaml]
----
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
name: <operatorgroup_name>
namespace: <namespace>
namespace: <namespace> <1>
spec:
targetNamespaces:
- <namespace>
- <namespace> <1>
----
<1> For `SingleNamespace` install mode, use the same `<namespace>` value for both the `metadata.namespace` and `spec.targetNamespaces` fields.
.. Create the `OperatorGroup` object:
+
@@ -105,21 +179,30 @@ spec:
$ oc apply -f operatorgroup.yaml
----
. Create a `Subscription` object YAML file to subscribe a namespace to an Operator, for example `sub.yaml`:
. Create a `Subscription` object to subscribe a namespace to an Operator:
.. Create a YAML file for the `Subscription` object, for example `subscription.yaml`:
+
[NOTE]
====
If you want to subscribe to a specific version of an Operator, set the `startingCSV` field to the desired version and set the `installPlanApproval` field to `Manual` to prevent the Operator from automatically upgrading if a later version exists in the catalog. For details, see the following "Example `Subscription` object with a specific starting Operator version".
====
+
.Example `Subscription` object
[%collapsible]
====
[source,yaml]
----
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
name: <subscription_name>
namespace: openshift-operators <1>
namespace: <namespace_per_install_mode> <1>
spec:
channel: <channel_name> <2>
name: <operator_name> <3>
source: redhat-operators <4>
sourceNamespace: openshift-marketplace <5>
source: <catalog_name> <4>
sourceNamespace: <catalog_source_namespace> <5>
config:
env: <6>
- name: ARGS
@@ -146,22 +229,45 @@ spec:
nodeSelector: <12>
foo: bar
----
<1> For default `AllNamespaces` install mode usage, specify the `openshift-operators` namespace. Alternatively, you can specify a custom global namespace, if you have created one. Otherwise, specify the relevant single namespace for `SingleNamespace` install mode usage.
<1> For default `AllNamespaces` install mode usage, specify the `openshift-operators` namespace. Alternatively, you can specify a custom global namespace, if you have created one. For `SingleNamespace` install mode usage, specify the relevant single namespace.
<2> Name of the channel to subscribe to.
<3> Name of the Operator to subscribe to.
<4> Name of the catalog source that provides the Operator.
<5> Namespace of the catalog source. Use `openshift-marketplace` for the default OperatorHub catalog sources.
<6> The `env` parameter defines a list of Environment Variables that must exist in all containers in the pod created by OLM.
<7> The `envFrom` parameter defines a list of sources to populate Environment Variables in the container.
<8> The `volumes` parameter defines a list of Volumes that must exist on the pod created by OLM.
<6> The `env` parameter defines a list of environment variables that must exist in all containers in the pod created by OLM.
<7> The `envFrom` parameter defines a list of sources to populate environment variables in the container.
<8> The `volumes` parameter defines a list of volumes that must exist on the pod created by OLM.
<9> The `volumeMounts` parameter defines a list of volume mounts that must exist in all containers in the pod created by OLM. If a `volumeMount` references a `volume` that does not exist, OLM fails to deploy the Operator.
<10> The `tolerations` parameter defines a list of Tolerations for the pod created by OLM.
<10> The `tolerations` parameter defines a list of tolerations for the pod created by OLM.
<11> The `resources` parameter defines resource constraints for all the containers in the pod created by OLM.
<12> The `nodeSelector` parameter defines a `NodeSelector` for the pod created by OLM.
====
+
.Example `Subscription` object with a specific starting Operator version
[%collapsible]
====
[source,yaml]
----
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
name: example-operator
namespace: example-operator
spec:
channel: stable-3.7
installPlanApproval: Manual <1>
name: example-operator
source: custom-operators
sourceNamespace: openshift-marketplace
startingCSV: example-operator.v3.7.10 <2>
----
<1> Set the approval strategy to `Manual` in case your specified version is superseded by a later version in the catalog. This plan prevents an automatic upgrade to a later version and requires manual approval before the starting CSV can complete the installation.
<2> Set a specific version of an Operator CSV.
====
. For clusters on cloud providers with token authentication enabled:
.. For clusters on cloud providers with token authentication enabled, configure your `Subscription` object by following these steps:
.. Ensure the `Subscription` object is set to manual update approvals:
... Ensure the `Subscription` object is set to manual update approvals:
+
[source,yaml]
----
@@ -172,7 +278,7 @@ spec:
----
<1> Subscriptions with automatic update approvals are not recommended because there might be permission changes to make prior to updating. Subscriptions with manual update approvals ensure that administrators have the opportunity to verify the permissions of the later version and take any necessary steps prior to update.
.. Include the relevant cloud provider-specific fields in the `Subscription` object's `config` section:
... Include the relevant cloud provider-specific fields in the `Subscription` object's `config` section:
+
--
* If the cluster is in AWS STS mode, include the following fields:
@@ -210,15 +316,33 @@ spec:
<3> Include the subscription ID.
--
. Create the `Subscription` object:
.. Create the `Subscription` object by running the following command:
+
[source,terminal]
----
$ oc apply -f sub.yaml
$ oc apply -f subscription.yaml
----
+
. If you set the `installPlanApproval` field to `Manual`, manually approve the pending install plan to complete the Operator installation. For more information, see "Manually approving a pending Operator update".
At this point, OLM is now aware of the selected Operator. A cluster service version (CSV) for the Operator should appear in the target namespace, and APIs provided by the Operator should be available for creation.
.Verification
. Check the status of the `Subscription` object for your installed Operator by running the following command:
+
[source,terminal]
----
$ oc describe subscription <subscription_name> -n <namespace>
----
. If you created an Operator group for `SingleNamespace` install mode, check the status of the `OperatorGroup` object by running the following command:
+
[source,terminal]
----
$ oc describe operatorgroup <operatorgroup_name> -n <namespace>
----
ifeval::["{context}" == "olm-installing-operators-in-namespace"]
:!olm-user:
endif::[]

View File

@@ -30,7 +30,7 @@ endif::[]
:_mod-docs-content-type: PROCEDURE
[id="olm-installing-from-operatorhub-using-web-console_{context}"]
= Installing from OperatorHub using the web console
= Installing from OperatorHub by using the web console
You can install and subscribe to an Operator from OperatorHub by using the {product-title} web console.
@@ -67,10 +67,19 @@ Choosing a Community Operator warns that Red Hat does not certify Community Oper
. Read the information about the Operator and click *Install*.
. On the *Install Operator* page:
. On the *Install Operator* page, configure your Operator installation:
.. If you want to install a specific version of an Operator, select an *Update channel* and *Version* from the lists. You can browse the various versions of an Operator across any channels it might have, view the metadata for that channel and version, and select the exact version you want to install.
+
[NOTE]
====
The version selection defaults to the latest version for the channel selected. If the latest version for the channel is selected, the *Automatic* approval strategy is enabled by default. Otherwise, *Manual* approval is required when not installing the latest version for the selected channel.
Installing an Operator with *Manual* approval causes all Operators installed within the namespace to function with the *Manual* approval strategy and all Operators are updated together. If you want to update Operators independently, install Operators into separate namespaces.
====
ifdef::olm-admin[]
.. Select one of the following:
.. Confirm the installation mode for the Operator:
*** *All namespaces on the cluster (default)* installs the Operator in the default `openshift-operators` namespace to watch and be made available to all namespaces in the cluster. This option is not always available.
*** *A specific namespace on the cluster* allows you to choose a specific, single namespace in which to install the Operator. The Operator will only watch and be made available for use in this single namespace.
endif::[]
@@ -81,17 +90,12 @@ endif::[]
.. For clusters on cloud providers with token authentication enabled:
+
--
* If the cluster uses {aws-short} {sts-short} (*STS Mode* in the web console), enter the Amazon Resource Name (ARN) of the AWS IAM role of your service account in the *role ARN* field.
+
image::oadp-install-operator-role-arn.png[Entering the ARN]
To create the role's ARN, follow the procedure described in link:https://access.redhat.com/documentation/en-us/red_hat_openshift_service_on_aws/4/html/tutorials/cloud-experts-deploy-api-data-protection#prepare-aws-account_cloud-experts-deploy-api-data-protection[Preparing AWS account].
* If the cluster uses {aws-short} {sts-short} (*STS Mode* in the web console), enter the Amazon Resource Name (ARN) of the AWS IAM role of your service account in the *role ARN* field. To create the role's ARN, follow the procedure described in link:https://access.redhat.com/documentation/en-us/red_hat_openshift_service_on_aws/4/html/tutorials/cloud-experts-deploy-api-data-protection#prepare-aws-account_cloud-experts-deploy-api-data-protection[Preparing AWS account].
* If the cluster uses {entra-first} (*Workload Identity / Federated Identity Mode* in the web console), add the client ID, tenant ID, and subscription ID in the appropriate field.
--
.. If more than one update channel is available, select an *Update channel*.
.. Select *Automatic* or *Manual* approval strategy, as described earlier.
.. For *Update approval*, select either the *Automatic* or *Manual* approval strategy.
+
[IMPORTANT]
====
@@ -100,7 +104,7 @@ If the web console shows that the cluster uses {aws-short} {sts-short} or {entra
Subscriptions with automatic update approvals are not recommended because there might be permission changes to make prior to updating. Subscriptions with manual update approvals ensure that administrators have the opportunity to verify the permissions of the later version and take any necessary steps prior to update.
====
. Click *Install* to make the Operator available to the selected namespaces on this {product-title} cluster.
. Click *Install* to make the Operator available to the selected namespaces on this {product-title} cluster:
.. If you selected a *Manual* approval strategy, the upgrade status of the subscription remains *Upgrading* until you review and approve the install plan.
+
@@ -108,13 +112,22 @@ After approving on the *Install Plan* page, the subscription upgrade status move
.. If you selected an *Automatic* approval strategy, the upgrade status should resolve to *Up to date* without intervention.
. After the upgrade status of the subscription is *Up to date*, select *Operators → Installed Operators* to verify that the cluster service version (CSV) of the installed Operator eventually shows up. The *Status* should ultimately resolve to *InstallSucceeded* in the relevant namespace.
.Verification
* After the upgrade status of the subscription is *Up to date*, select *Operators* -> *Installed Operators* to verify that the cluster service version (CSV) of the installed Operator eventually shows up. The *Status* should eventually resolve to *Succeeded* in the relevant namespace.
+
[NOTE]
====
For the *All namespaces...* installation mode, the status resolves to *InstallSucceeded* in the `openshift-operators` namespace, but the status is *Copied* if you check in other namespaces.
For the *All namespaces...* installation mode, the status resolves to *Succeeded* in the `openshift-operators` namespace, but the status is *Copied* if you check in other namespaces.
====
+
If it does not:
.. Check the logs in any pods in the `openshift-operators` project (or other relevant namespace if *A specific namespace...* installation mode was selected) on the *WorkloadsPods* page that are reporting issues to troubleshoot further.
** Check the logs in any pods in the `openshift-operators` project (or other relevant namespace if *A specific namespace...* installation mode was selected) on the *Workloads* -> *Pods* page that are reporting issues to troubleshoot further.
* When the Operator is installed, the metadata indicates which channel and version are installed.
+
[NOTE]
====
The *Channel* and *Version* dropdown menus are still available for viewing other version metadata in this catalog context.
====

View File

@@ -1,206 +0,0 @@
// Module included in the following assemblies:
//
// * operators/user/olm-installing-operators-in-namespace.adoc
// * operators/admin/olm-adding-operators-to-cluster.adoc
ifeval::["{context}" == "olm-installing-operators-in-namespace"]
:olm-user:
endif::[]
:_mod-docs-content-type: PROCEDURE
[id="olm-installing-specific-version-cli_{context}"]
= Installing a specific version of an Operator
You can install a specific version of an Operator by setting the cluster service version (CSV) in a `Subscription` object.
.Prerequisites
ifndef::olm-user[]
- Access to an {product-title} cluster using an account with
ifdef::openshift-enterprise,openshift-webscale,openshift-origin[]
`cluster-admin` permissions
endif::[]
ifdef::openshift-dedicated,openshift-rosa[]
the `dedicated-admin` role.
endif::[]
endif::[]
ifdef::olm-user[]
- Access to an {product-title} cluster using an account with Operator installation permissions.
endif::[]
- You have installed the OpenShift CLI (`oc`).
.Procedure
. Look up the available versions and channels of the Operator you want to install by running the following command:
+
.Command syntax
[source,terminal]
----
$ oc describe packagemanifests <operator_name> -n <catalog_namespace>
----
+
For example, the following command prints the available channels and versions of the Red Hat Quay Operator from OperatorHub:
+
.Example command
[source,terminal]
----
$ oc describe packagemanifests quay-operator -n openshift-marketplace
----
+
.Example output
[%collapsible]
====
[source,text]
----
Name: quay-operator
Namespace: operator-marketplace
Labels: catalog=redhat-operators
catalog-namespace=openshift-marketplace
hypershift.openshift.io/managed=true
operatorframework.io/arch.amd64=supported
operatorframework.io/os.linux=supported
provider=Red Hat
provider-url=
Annotations: <none>
API Version: packages.operators.coreos.com/v1
Kind: PackageManifest
...
Current CSV: quay-operator.v3.7.11
...
Entries:
Name: quay-operator.v3.7.11
Version: 3.7.11
Name: quay-operator.v3.7.10
Version: 3.7.10
Name: quay-operator.v3.7.9
Version: 3.7.9
Name: quay-operator.v3.7.8
Version: 3.7.8
Name: quay-operator.v3.7.7
Version: 3.7.7
Name: quay-operator.v3.7.6
Version: 3.7.6
Name: quay-operator.v3.7.5
Version: 3.7.5
Name: quay-operator.v3.7.4
Version: 3.7.4
Name: quay-operator.v3.7.3
Version: 3.7.3
Name: quay-operator.v3.7.2
Version: 3.7.2
Name: quay-operator.v3.7.1
Version: 3.7.1
Name: quay-operator.v3.7.0
Version: 3.7.0
Name: stable-3.7
...
Current CSV: quay-operator.v3.8.5
...
Entries:
Name: quay-operator.v3.8.5
Version: 3.8.5
Name: quay-operator.v3.8.4
Version: 3.8.4
Name: quay-operator.v3.8.3
Version: 3.8.3
Name: quay-operator.v3.8.2
Version: 3.8.2
Name: quay-operator.v3.8.1
Version: 3.8.1
Name: quay-operator.v3.8.0
Version: 3.8.0
Name: stable-3.8
Default Channel: stable-3.8
Package Name: quay-operator
----
====
+
[TIP]
====
You can print an Operator's version and channel information in the YAML format by running the following command:
[source,terminal]
----
$ oc get packagemanifests <operator_name> -n <catalog_namespace> -o yaml
----
====
** If more than one catalog is installed in a namespace, run the following command to look up the available versions and channels of an Operator from a specific catalog:
+
[source,terminal]
----
$ oc get packagemanifest \
--selector=catalog=<catalogsource_name> \
--field-selector metadata.name=<operator_name> \
-n <catalog_namespace> -o yaml
----
+
[IMPORTANT]
====
If you do not specify the Operator's catalog, running the `oc get packagemanifest` and `oc describe packagemanifest` commands might return a package from an unexpected catalog if the following conditions are met:
* Multiple catalogs are installed in the same namespace.
* The catalogs contain the same Operators or Operators with the same name.
====
. An Operator group, defined by an `OperatorGroup` object, selects target namespaces in which to generate required role-based access control (RBAC) access for all Operators in the same namespace as the Operator group.
+
The namespace to which you subscribe the Operator must have an Operator group that matches the install mode of the Operator, either the `AllNamespaces` or `SingleNamespace` mode. If the Operator you intend to install uses the `AllNamespaces` mode, then the `openshift-operators` namespace already has an appropriate Operator group in place.
+
However, if the Operator uses the `SingleNamespace` mode and you do not already have an appropriate Operator group in place, you must create one:
.. Create an `OperatorGroup` object YAML file, for example `operatorgroup.yaml`:
+
.Example `OperatorGroup` object
[source,yaml]
----
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
name: <operatorgroup_name>
namespace: <namespace>
spec:
targetNamespaces:
- <namespace>
----
.. Create the `OperatorGroup` object:
+
[source,terminal]
----
$ oc apply -f operatorgroup.yaml
----
. Create a `Subscription` object YAML file that subscribes a namespace to an Operator with a specific version by setting the `startingCSV` field. Set the `installPlanApproval` field to `Manual` to prevent the Operator from automatically upgrading if a later version exists in the catalog.
+
For example, the following `sub.yaml` file can be used to install the Red Hat Quay Operator specifically to version 3.7.10:
+
.Subscription with a specific starting Operator version
[source,yaml]
----
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
name: quay-operator
namespace: quay
spec:
channel: stable-3.7
installPlanApproval: Manual <1>
name: quay-operator
source: redhat-operators
sourceNamespace: openshift-marketplace
startingCSV: quay-operator.v3.7.10 <2>
----
<1> Set the approval strategy to `Manual` in case your specified version is superseded by a later version in the catalog. This plan prevents an automatic upgrade to a later version and requires manual approval before the starting CSV can complete the installation.
<2> Set a specific version of an Operator CSV.
. Create the `Subscription` object:
+
[source,terminal]
----
$ oc apply -f sub.yaml
----
. Manually approve the pending install plan to complete the Operator installation.

View File

@@ -1,41 +0,0 @@
// Module included in the following assemblies:
//
// * operators/admin/olm-adding-operators-to-cluster.adoc
:_mod-docs-content-type: PROCEDURE
[id="olm-installing-specific-version-web-console_{context}"]
= Installing a specific version of an Operator in the web console
You can install a specific version of an Operator by using the OperatorHub in the web console. You are able to browse the various versions of an operator across any channels it might have, view the metadata for that channel and version, and select the exact version you want to install.
.Prerequisites
* You must have administrator privileges.
.Procedure
. From the web console, click *Operators* → *OperatorHub*.
. Select an Operator you want to install.
. From the selected Operator, you can select a *Channel* and *Version* from the lists.
+
[NOTE]
====
The version selection defaults to the latest version for the channel selected. If the latest version for the channel is selected, the Automatic approval strategy is enabled by default. Otherwise Manual approval is required when not installing the latest version for the selected channel.
Manual approval applies to all operators installed in a namespace.
Installing an Operator with manual approval causes all Operators installed within the namespace to function with the Manual approval strategy and all Operators are updated together. Install Operators into separate namespaces for updating independently.
====
. Click *Install*
.Verification
* When the operator is installed, the metadata indicates which channel and version are installed.
+
[NOTE]
====
The channel and version dropdown menus are still available for viewing other version metadata in this catalog context.
====

View File

@@ -39,6 +39,12 @@ include::modules/olm-installing-operators-from-operatorhub.adoc[leveloffset=+1]
* xref:../../operators/understanding/olm-understanding-operatorhub.adoc#olm-understanding-operatorhub[Understanding OperatorHub]
include::modules/olm-installing-from-operatorhub-using-web-console.adoc[leveloffset=+1]
[role="_additional-resources"]
.Additional resources
* xref:../../operators/admin/olm-upgrading-operators.adoc#olm-approving-pending-upgrade_olm-upgrading-operators[Manually approving a pending Operator update]
ifdef::openshift-enterprise,openshift-webscale,openshift-origin,openshift-dedicated,openshift-rosa[]
include::modules/olm-installing-from-operatorhub-using-cli.adoc[leveloffset=+1]
@@ -46,16 +52,8 @@ include::modules/olm-installing-from-operatorhub-using-cli.adoc[leveloffset=+1]
.Additional resources
* xref:../../operators/understanding/olm/olm-understanding-operatorgroups.adoc#olm-operatorgroups-about_olm-understanding-operatorgroups[About Operator groups]
include::modules/olm-installing-specific-version-cli.adoc[leveloffset=+1]
[role="_additional-resources"]
.Additional resources
* xref:../../operators/admin/olm-upgrading-operators.adoc#olm-approving-pending-upgrade_olm-upgrading-operators[Manually approving a pending Operator update]
* xref:../../operators/admin/olm-adding-operators-to-cluster.adoc#olm-installing-global-namespaces_olm-adding-operators-to-a-cluster[Installing global Operators in custom namespaces]
include::modules/olm-installing-specific-version-web-console.adoc[leveloffset=+1]
* xref:../../operators/admin/olm-upgrading-operators.adoc#olm-approving-pending-upgrade_olm-upgrading-operators[Manually approving a pending Operator update]
include::modules/olm-preparing-multitenant-operators.adoc[leveloffset=+1]
.Next steps

View File

@@ -32,8 +32,6 @@ include::modules/olm-installing-from-operatorhub-using-cli.adoc[leveloffset=+1]
* xref:../../operators/understanding/olm/olm-understanding-olm.adoc#olm-operatorgroups-about_olm-understanding-olm[Operator groups]
* xref:../../operators/understanding/olm/olm-understanding-olm.adoc#olm-subscription_olm-understanding-olm[Channel names]
include::modules/olm-installing-specific-version-cli.adoc[leveloffset=+1]
[role="_additional-resources"]
.Additional resources