diff --git a/modules/olm-about-catalogs.adoc b/modules/olm-about-catalogs.adoc index 67e4fc382949..e7f48791f1f0 100644 --- a/modules/olm-about-catalogs.adoc +++ b/modules/olm-about-catalogs.adoc @@ -10,14 +10,7 @@ An Operator catalog is a repository of metadata that Operator Lifecycle Manager An index image, based on the Operator bundle format, is a containerized snapshot of a catalog. It is an immutable artifact that contains the database of pointers to a set of Operator manifest content. A catalog can reference an index image to source its content for OLM on the cluster. -As catalogs are updated, the latest versions of Operators change, and older versions may be removed or altered. In addition, when OLM runs on -ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[] -an {product-title} -endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[] -ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[] -a {product-title} -endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[] -cluster in a restricted network environment, it is unable to access the catalogs directly from the internet to pull the latest content. +As catalogs are updated, the latest versions of Operators change, and older versions may be removed or altered. In addition, when OLM runs on an {product-title} cluster in a restricted network environment, it is unable to access the catalogs directly from the internet to pull the latest content. As a cluster administrator, you can create your own custom index image, either based on a Red Hat-provided catalog or from scratch, which can be used to source the catalog content on the cluster. Creating and updating your own index image provides a method for customizing the set of Operators available on the cluster, while also avoiding the aforementioned restricted network environment issues. diff --git a/modules/olm-catalog-source-and-psa.adoc b/modules/olm-catalog-source-and-psa.adoc index f44d8de9ce78..ae036e85477b 100644 --- a/modules/olm-catalog-source-and-psa.adoc +++ b/modules/olm-catalog-source-and-psa.adoc @@ -8,25 +8,13 @@ _Pod security admission_ was introduced in {product-title} 4.11 to ensure pod security standards. Catalog sources built using the SQLite-based catalog format and a version of the `opm` CLI tool released before {product-title} 4.11 cannot run under restricted pod security enforcement. -ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[] -In {product-title} {product-version}, -endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[] -ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[] -In {product-title}, -endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[] -namespaces do not have restricted pod security enforcement by default and the default catalog source security mode is set to `legacy`. +In {product-title} {product-version}, namespaces do not have restricted pod security enforcement by default and the default catalog source security mode is set to `legacy`. Default restricted enforcement for all namespaces is planned for inclusion in a future {product-title} release. When restricted enforcement occurs, the security context of the pod specification for catalog source pods must match the restricted pod security standard. If your catalog source image requires a different pod security standard, the pod security admissions label for the namespace must be explicitly set. [NOTE] ==== -If you do not want to run your SQLite-based catalog source pods as restricted, you do not need to update your catalog source in -ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[] -{product-title} {product-version}. -endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[] -ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[] -{product-title}. -endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[] +If you do not want to run your SQLite-based catalog source pods as restricted, you do not need to update your catalog source in {product-title} {product-version}. However, it is recommended that you take action now to ensure your catalog sources run under restricted pod security enforcement. If you do not take action to ensure your catalog sources run under restricted pod security enforcement, your catalog sources might not run in future {product-title} releases. ==== diff --git a/modules/olm-catalogsource-image-template.adoc b/modules/olm-catalogsource-image-template.adoc index d5fad8b2fee8..9b0e8e4bb794 100644 --- a/modules/olm-catalogsource-image-template.adoc +++ b/modules/olm-catalogsource-image-template.adoc @@ -12,13 +12,7 @@ endif::[] [id="olm-catalogsource-image-template_{context}"] = Image template for custom catalog sources -Operator compatibility with the underlying cluster can be expressed by a catalog source in various ways. One way, which is used for the default Red Hat-provided catalog sources, is to identify image tags for index images that are specifically created for a particular platform release, for example -ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[] -{product-title} {product-version}. -endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[] -ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[] -{product-title}. -endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[] +Operator compatibility with the underlying cluster can be expressed by a catalog source in various ways. One way, which is used for the default Red Hat-provided catalog sources, is to identify image tags for index images that are specifically created for a particular platform release, for example {product-title} {product-version}. During a cluster upgrade, the index image tag for the default Red Hat-provided catalog sources are updated automatically by the Cluster Version Operator (CVO) so that Operator Lifecycle Manager (OLM) pulls the updated version of the catalog. For example during an upgrade from {product-title} {ocp-nminus1} to {product-version}, the `spec.image` field in the `CatalogSource` object for the `redhat-operators` catalog is updated from: @@ -44,7 +38,7 @@ Starting in {product-title} 4.9, cluster administrators can add the `olm.catalog [NOTE] ==== -You must specify the Kubernetes cluster version and not the {product-title} cluster version, as the latter is not currently available for templating. +You must specify the Kubernetes cluster version and not an {product-title} cluster version, as the latter is not currently available for templating. ==== Provided that you have created and pushed an index image with a tag specifying the updated Kubernetes version, setting this annotation enables the index image versions in custom catalogs to be automatically changed after a cluster upgrade. The annotation value is used to set or update the image reference in the `spec.image` field of the `CatalogSource` object. This helps avoid cluster upgrades leaving Operator installations in unsupported states or without a continued update path. @@ -83,14 +77,7 @@ If the `spec.image` field and the `olm.catalogImageTemplate` annotation are both If the `spec.image` field is not set and the annotation does not resolve to a usable pull spec, OLM stops reconciliation of the catalog source and sets it into a human-readable error condition. ==== -For -ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[] -an {product-title} {product-version} -endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[] -ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[] -a {product-title} -endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[] -cluster, which uses Kubernetes 1.33, the `olm.catalogImageTemplate` annotation in the preceding example resolves to the following image reference: +For an {product-title} {product-version} cluster, which uses Kubernetes 1.33, the `olm.catalogImageTemplate` annotation in the preceding example resolves to the following image reference: [source,terminal] ---- diff --git a/modules/olm-colocation-namespaces.adoc b/modules/olm-colocation-namespaces.adoc index 078857e9ac9e..6f0538b88640 100644 --- a/modules/olm-colocation-namespaces.adoc +++ b/modules/olm-colocation-namespaces.adoc @@ -20,21 +20,21 @@ These scenarios can lead to the following issues: These issues usually surface because, when installing Operators with the {product-title} web console, the default behavior installs Operators that support the *All namespaces* install mode into the default `openshift-operators` global namespace. -ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifndef::openshift-dedicated,openshift-rosa[] As a cluster administrator, -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] +ifdef::openshift-dedicated,openshift-rosa[] As an administrator with the `dedicated-admin` role, -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] you can bypass this default behavior manually by using the following workflow: -ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifndef::openshift-dedicated,openshift-rosa[] . Create a namespace for the installation of the Operator. -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] // In OSD/ROSA, dedicated-admins can create projects, but not namespaces. -ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifdef::openshift-dedicated,openshift-rosa[] . Create a project for the installation of the Operator. -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] . Create a custom _global Operator group_, which is an Operator group that watches all namespaces. By associating this Operator group with the namespace you just created, it makes the installation namespace a global namespace, which makes Operators installed there available in all namespaces. . Install the desired Operator in the installation namespace. diff --git a/modules/olm-creating-catalog-from-index.adoc b/modules/olm-creating-catalog-from-index.adoc index 7bfa15e02430..46f4c949c290 100644 --- a/modules/olm-creating-catalog-from-index.adoc +++ b/modules/olm-creating-catalog-from-index.adoc @@ -26,39 +26,39 @@ endif::[] = Adding a catalog source to a cluster Adding a catalog source to an {product-title} cluster enables the discovery and installation of Operators for users. -ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifndef::openshift-dedicated,openshift-rosa[] Cluster administrators -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] +ifdef::openshift-dedicated,openshift-rosa[] Administrators with the `dedicated-admin` role -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] can create a `CatalogSource` object that references an index image. OperatorHub uses catalog sources to populate the user interface. // In OSD/ROSA, a dedicated-admin can see catalog sources here, but can't add, edit, or delete them. -ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifndef::openshift-dedicated,openshift-rosa[] [TIP] ==== Alternatively, you can use the web console to manage catalog sources. From the *Administration* -> *Cluster Settings* -> *Configuration* -> *OperatorHub* page, click the *Sources* tab, where you can create, update, delete, disable, and enable individual sources. ==== -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] // In OSD/ROSA, a dedicated-admin can update catalog sources in the console by searching for them. -ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifdef::openshift-dedicated,openshift-rosa[] [TIP] ==== Alternatively, you can use the web console to manage catalog sources. From the *Home* -> *Search* page, select a project, click the *Resources* drop-down and search for `CatalogSource`. You can create, update, delete, disable, and enable individual sources. ==== -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] .Prerequisites * You built and pushed an index image to a registry. -ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifndef::openshift-dedicated,openshift-rosa[] * You have access to the cluster as a user with the `cluster-admin` role. -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] +ifdef::openshift-dedicated,openshift-rosa[] * You have access to the cluster as a user with the `dedicated-admin` role. -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] .Procedure diff --git a/modules/olm-creating-etcd-cluster-from-operator.adoc b/modules/olm-creating-etcd-cluster-from-operator.adoc index 129eeb3b4bfa..5d75cd09ad3c 100644 --- a/modules/olm-creating-etcd-cluster-from-operator.adoc +++ b/modules/olm-creating-etcd-cluster-from-operator.adoc @@ -6,12 +6,12 @@ This procedure walks through creating a new etcd cluster using the etcd Operator .Prerequisites -ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifndef::openshift-dedicated,openshift-rosa[] * Access to an {product-title} {product-version} cluster. -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -* Access to a {product-title} cluster. -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] +ifdef::openshift-dedicated,openshift-rosa[] +* Access to an {product-title} cluster. +endif::openshift-dedicated,openshift-rosa[] * The etcd Operator already installed cluster-wide by an administrator. .Procedure @@ -19,12 +19,12 @@ endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] . Create a new project in the {product-title} web console for this procedure. This example uses a project called `my-etcd`. . Navigate to the *Operators -> Installed Operators* page. The Operators that have been installed to the cluster by the -ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifndef::openshift-dedicated,openshift-rosa[] cluster administrator -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] +ifdef::openshift-dedicated,openshift-rosa[] dedicated-admin -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] and are available for use are shown here as a list of cluster service versions (CSVs). CSVs are used to launch and manage the software provided by the Operator. + [TIP] @@ -59,10 +59,10 @@ $ oc policy add-role-to-user edit -n ---- You now have an etcd cluster that will react to failures and rebalance data as pods become unhealthy or are migrated between nodes in the cluster. Most importantly, -ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifndef::openshift-dedicated,openshift-rosa[] cluster administrators -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] +ifdef::openshift-dedicated,openshift-rosa[] dedicated-admins -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] or developers with proper access can now easily use the database with their applications. diff --git a/modules/olm-csv.adoc b/modules/olm-csv.adoc index 0dcc62c8b092..24744e8dc8b9 100644 --- a/modules/olm-csv.adoc +++ b/modules/olm-csv.adoc @@ -5,7 +5,7 @@ [id="olm-csv_{context}"] = Cluster service version -A _cluster service version_ (CSV) represents a specific version of a running Operator on your {product-title} cluster. It is a YAML manifest created from Operator metadata that assists Operator Lifecycle Manager (OLM) in running the Operator in the cluster. +A _cluster service version_ (CSV) represents a specific version of a running Operator on an {product-title} cluster. It is a YAML manifest created from Operator metadata that assists Operator Lifecycle Manager (OLM) in running the Operator in the cluster. OLM requires this metadata about an Operator to ensure that it can be kept running safely on a cluster, and to provide information about how updates should be applied as new versions of the Operator are published. This is similar to packaging software for a traditional operating system; think of the packaging step for OLM as the stage at which you make your `rpm`, `deb`, or `apk` bundle. diff --git a/modules/olm-deleting-operators-from-a-cluster-using-cli.adoc b/modules/olm-deleting-operators-from-a-cluster-using-cli.adoc index d52d189978d2..d11f90e5508c 100644 --- a/modules/olm-deleting-operators-from-a-cluster-using-cli.adoc +++ b/modules/olm-deleting-operators-from-a-cluster-using-cli.adoc @@ -11,13 +11,13 @@ Cluster administrators can delete installed Operators from a selected namespace .Prerequisites -- You have access to the {product-title} cluster using an account with +- You have 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,openshift-rosa-hcp[] +ifdef::openshift-dedicated,openshift-rosa[] `dedicated-admin` permissions. -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] - The OpenShift CLI (`oc`) is installed on your workstation. .Procedure diff --git a/modules/olm-deleting-operators-from-a-cluster-using-web-console.adoc b/modules/olm-deleting-operators-from-a-cluster-using-web-console.adoc index bd27e2028425..1af151c9c935 100644 --- a/modules/olm-deleting-operators-from-a-cluster-using-web-console.adoc +++ b/modules/olm-deleting-operators-from-a-cluster-using-web-console.adoc @@ -13,7 +13,7 @@ Cluster administrators can delete installed Operators from a selected namespace .Prerequisites -- You have access to the {product-title} cluster web console using an account with +- You have access to an {product-title} cluster web console using an account with ifdef::openshift-enterprise,openshift-webscale,openshift-origin[] `cluster-admin` permissions. endif::[] diff --git a/modules/olm-dependency-resolution-preferences.adoc b/modules/olm-dependency-resolution-preferences.adoc index b5a98155b778..f1ca8b3e7f41 100644 --- a/modules/olm-dependency-resolution-preferences.adoc +++ b/modules/olm-dependency-resolution-preferences.adoc @@ -10,7 +10,7 @@ There can be many options that equally satisfy a dependency of an Operator. The [id="olm-dependency-catalog-priority_{context}"] == Catalog priority -On {product-title} clusters, OLM reads catalog sources to know which Operators are available for installation. +On {product-title} cluster, OLM reads catalog sources to know which Operators are available for installation. .Example `CatalogSource` object [source,yaml] @@ -40,7 +40,7 @@ There are two rules that govern catalog preference: [id="olm-dependency-catalog-ordering_{context}"] == Channel ordering -An Operator package in a catalog is a collection of update channels that a user can subscribe to in {product-title} clusters. Channels can be used to provide a particular stream of updates for a minor release (`1.2`, `1.3`) or a release frequency (`stable`, `fast`). +An Operator package in a catalog is a collection of update channels that a user can subscribe to in an {product-title} cluster. Channels can be used to provide a particular stream of updates for a minor release (`1.2`, `1.3`) or a release frequency (`stable`, `fast`). It is likely that a dependency might be satisfied by Operators in the same package, but different channels. For example, version `1.2` of an Operator might exist in both the `stable` and `fast` channels. diff --git a/modules/olm-filtering-fbc.adoc b/modules/olm-filtering-fbc.adoc index e720bde96c49..e137567b443c 100644 --- a/modules/olm-filtering-fbc.adoc +++ b/modules/olm-filtering-fbc.adoc @@ -23,14 +23,14 @@ You can use the `opm` CLI to update or filter a catalog image that uses the file You can then rebuild the image as an updated version of the catalog. // This note points to a topic that's excluded from OSD and ROSA. -ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifndef::openshift-dedicated,openshift-rosa[] [NOTE] ==== Alternatively, if you already have a catalog image on a mirror registry, you can use the oc-mirror CLI plugin to automatically prune any removed images from an updated source version of that catalog image while mirroring it to the target registry. For more information about the oc-mirror plugin and this use case, see the "Keeping your mirror registry content updated" section, and specifically the "Pruning images" subsection, of "Mirroring images for a disconnected installation using the oc-mirror plugin". ==== -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] .Prerequisites * You have the following on your workstation: diff --git a/modules/olm-injecting-custom-ca.adoc b/modules/olm-injecting-custom-ca.adoc index 7866d5a81db9..7758c680da34 100644 --- a/modules/olm-injecting-custom-ca.adoc +++ b/modules/olm-injecting-custom-ca.adoc @@ -6,25 +6,25 @@ [id="olm-inject-custom-ca_{context}"] = Injecting a custom CA certificate -ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifndef::openshift-dedicated,openshift-rosa[] When a cluster administrator -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] +ifdef::openshift-dedicated,openshift-rosa[] When an administrator with the `dedicated-admin` role -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] adds a custom CA certificate to a cluster using a config map, the Cluster Network Operator merges the user-provided certificates and system CA certificates into a single bundle. You can inject this merged bundle into your Operator running on Operator Lifecycle Manager (OLM), which is useful if you have a man-in-the-middle HTTPS proxy. .Prerequisites -ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifndef::openshift-dedicated,openshift-rosa[] * Access to an {product-title} cluster using an account with ifdef::openshift-enterprise,openshift-webscale,openshift-origin[] `cluster-admin` permissions. endif::[] -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] +ifdef::openshift-dedicated,openshift-rosa[] * Access to a {product-title} cluster as a user with the `dedicated-admin` role. -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] * Custom CA certificate added to the cluster using a config map. * Desired Operator installed and running on OLM. diff --git a/modules/olm-installing-from-operatorhub-using-cli.adoc b/modules/olm-installing-from-operatorhub-using-cli.adoc index f3d3086824b6..192fc7b5d9e9 100644 --- a/modules/olm-installing-from-operatorhub-using-cli.adoc +++ b/modules/olm-installing-from-operatorhub-using-cli.adoc @@ -27,17 +27,17 @@ In most cases, the web console method of this procedure is preferred because it .Prerequisites ifndef::olm-user[] -* Access to your {product-title} cluster using an account with +* 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,openshift-rosa-hcp[] +ifdef::openshift-dedicated,openshift-rosa[] the `dedicated-admin` role. endif::[] endif::[] ifdef::olm-user[] -* Access to your {product-title} cluster using an account with Operator installation permissions. +* Access to an {product-title} cluster using an account with Operator installation permissions. endif::[] * You have installed the OpenShift CLI (`oc`). diff --git a/modules/olm-installing-from-operatorhub-using-web-console.adoc b/modules/olm-installing-from-operatorhub-using-web-console.adoc index 530ae37271cb..9076f59b1a31 100644 --- a/modules/olm-installing-from-operatorhub-using-web-console.adoc +++ b/modules/olm-installing-from-operatorhub-using-web-console.adoc @@ -85,20 +85,12 @@ ifdef::olm-admin[] endif::[] ifdef::olm-user[] .. 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::olm-user[] +endif::[] -ifndef::openshift-rosa[] -.. For clusters on cloud providers with token authentication enabled: -+ --- -* If the cluster uses {aws-short} {sts-full} (*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://docs.redhat.com/en/documentation/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]. -endif::openshift-rosa[] -ifdef::openshift-rosa[] .. For clusters on cloud providers with token authentication enabled: + -- -* If the cluster uses {aws-short} {sts-full} (*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://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws_classic_architecture/4/html/tutorials/cloud-experts-deploy-api-data-protection[Preparing AWS account]. -endif::openshift-rosa[] +* If the cluster uses {aws-short} {sts-full} (*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 fields. diff --git a/modules/olm-installing-global-namespaces.adoc b/modules/olm-installing-global-namespaces.adoc index 8b14cf777b09..199be132bc94 100644 --- a/modules/olm-installing-global-namespaces.adoc +++ b/modules/olm-installing-global-namespaces.adoc @@ -8,27 +8,27 @@ When installing Operators with the {product-title} web console, the default behavior installs Operators that support the *All namespaces* install mode into the default `openshift-operators` global namespace. This can cause issues related to shared install plans and update policies between all Operators in the namespace. For more details on these limitations, see "Multitenancy and Operator colocation". -ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifndef::openshift-dedicated,openshift-rosa[] As a cluster administrator, endif::[] -ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifdef::openshift-dedicated,openshift-rosa[] As an administrator with the `dedicated-admin` role, endif::[] you can bypass this default behavior manually by creating a custom global namespace and using that namespace to install your individual or scoped set of Operators and their dependencies. .Prerequisites -ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifndef::openshift-dedicated,openshift-rosa[] * You have access to the cluster as a user with the `cluster-admin` role. -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] +ifdef::openshift-dedicated,openshift-rosa[] * You have access to the cluster as a user with the `dedicated-admin` role. -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] .Procedure // In OSD/ROSA, dedicated-admins can't create namespaces directly but can create projects. -ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifndef::openshift-dedicated,openshift-rosa[] . Before installing the Operator, create a namespace for the installation of your desired Operator. This installation namespace will become the custom global namespace: .. Define a `Namespace` resource and save the YAML file, for example, `global-operators.yaml`: @@ -47,16 +47,16 @@ metadata: ---- $ oc create -f global-operators.yaml ---- -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] // Slightly different step for OSD/ROSA since dedicated-admins can't create namespaces directly. -ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifdef::openshift-dedicated,openshift-rosa[] . Before installing the Operator, create a namespace for the installation of your desired Operator. You can do this by creating a project. The namespace for this project will become the custom global namespace: + [source,terminal] ---- $ oc new-project global-operators ---- -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] . Create a custom _global Operator group_, which is an Operator group that watches all namespaces: diff --git a/modules/olm-installing-operators-from-operatorhub.adoc b/modules/olm-installing-operators-from-operatorhub.adoc index bbba97bcd171..d881ec43bf02 100644 --- a/modules/olm-installing-operators-from-operatorhub.adoc +++ b/modules/olm-installing-operators-from-operatorhub.adoc @@ -17,16 +17,16 @@ endif::[] OperatorHub is a user interface for discovering Operators; it works in conjunction with Operator Lifecycle Manager (OLM), which installs and manages Operators on a cluster. -ifndef::olm-user,openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifndef::olm-user,openshift-dedicated,openshift-rosa[] As a cluster administrator, you can install an Operator from OperatorHub by using the {product-title} ifdef::openshift-enterprise,openshift-webscale,openshift-origin[] web console or CLI. Subscribing an Operator to one or more namespaces makes the Operator available to developers on your cluster. endif::[] endif::[] -ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifdef::openshift-dedicated,openshift-rosa[] As a `dedicated-admin`, you can install an Operator from OperatorHub by using the {product-title} web console or CLI. Subscribing an Operator to one or more namespaces makes the Operator available to developers on your cluster. -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] ifdef::olm-user[] As a user with the proper permissions, you can install an Operator from OperatorHub by using the {product-title} web console or CLI. @@ -35,7 +35,7 @@ endif::[] During installation, you must determine the following initial settings for the Operator: ifndef::olm-user[] -ifdef::openshift-enterprise,openshift-webscale,openshift-origin,openshift-rosa,openshift-dedicated,openshift-rosa-hcp[] +ifdef::openshift-enterprise,openshift-webscale,openshift-origin,openshift-rosa,openshift-dedicated[] Installation Mode:: Choose *All namespaces on the cluster (default)* to have the Operator installed on all namespaces or choose individual namespaces, if available, to only install the Operator on selected namespaces. This example chooses *All namespaces...* to make the Operator available to all users and projects. endif::[] endif::[] @@ -51,10 +51,10 @@ Approval Strategy:: You can choose automatic or manual updates. If you choose automatic updates for an installed Operator, when a new version of that Operator is available in the selected channel, Operator Lifecycle Manager (OLM) automatically upgrades the running instance of your Operator without human intervention. + If you select manual updates, when a newer version of an Operator is available, OLM creates an update request. As a -ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifndef::openshift-dedicated,openshift-rosa[] cluster administrator, -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] +ifdef::openshift-dedicated,openshift-rosa[] `dedicated-admin`, -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] you must then manually approve that update request to have the Operator updated to the new version. diff --git a/modules/olm-migrating-sqlite-catalog-to-fbc.adoc b/modules/olm-migrating-sqlite-catalog-to-fbc.adoc index 4e9c89c410a2..82d3750aacf4 100644 --- a/modules/olm-migrating-sqlite-catalog-to-fbc.adoc +++ b/modules/olm-migrating-sqlite-catalog-to-fbc.adoc @@ -11,17 +11,13 @@ You can update your deprecated SQLite database format catalogs to the file-based .Prerequisites * You have a SQLite database catalog source. -ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifndef::openshift-dedicated,openshift-rosa[] * You have access to the cluster as a user with the `cluster-admin` role. -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] +ifdef::openshift-dedicated,openshift-rosa[] * You have access to the cluster as a user with the `dedicated-admin` role. -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -* You have the latest version of the `opm` CLI tool released with {product-title} -ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[] -{product-version} -endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[] -on your workstation. +endif::openshift-dedicated,openshift-rosa[] +* You have the latest version of the `opm` CLI tool released with {product-title} {product-version} on your workstation. .Procedure diff --git a/modules/olm-multitenancy-solution.adoc b/modules/olm-multitenancy-solution.adoc index a0566d66f226..4e6638d8b9ca 100644 --- a/modules/olm-multitenancy-solution.adoc +++ b/modules/olm-multitenancy-solution.adoc @@ -9,12 +9,12 @@ While a *Multinamespace* install mode does exist, it is supported by very few Operators. As a middle ground solution between the standard *All namespaces* and *Single namespace* install modes, you can install multiple instances of the same Operator, one for each tenant, by using the following workflow: // In OSD/ROSA, dedicated-admins can create projects, but not namespaces. -ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifndef::openshift-dedicated,openshift-rosa[] . Create a namespace for the tenant Operator that is separate from the tenant's namespace. -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] +ifdef::openshift-dedicated,openshift-rosa[] . Create a namespace for the tenant Operator that is separate from the tenant's namespace. You can do this by creating a project. -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] . Create an Operator group for the tenant Operator scoped only to the tenant's namespace. . Install the Operator in the tenant Operator namespace. @@ -40,9 +40,9 @@ You cannot use different versions of the same Operator on the same cluster. Even ==== // In OSD/ROSA, tenants shouldn't be able to install Operators. Dedicated-admins can, but they can't grant non-admin users the ability to install their own Operators. -ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifndef::openshift-dedicated,openshift-rosa[] [WARNING] ==== As an administrator, use caution when allowing non-cluster administrators to install Operators self-sufficiently, as explained in "Allowing non-cluster administrators to install Operators". These tenants should only have access to a curated catalog of Operators that are known to not have dependencies. These tenants must also be forced to use the same version line of an Operator, to ensure the CRDs do not change. This requires the use of namespace-scoped catalogs and likely disabling the global default catalogs. ==== -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] diff --git a/modules/olm-node-selector.adoc b/modules/olm-node-selector.adoc index 2b7aa3b6845c..639ea1d3d97b 100644 --- a/modules/olm-node-selector.adoc +++ b/modules/olm-node-selector.adoc @@ -9,9 +9,9 @@ .Prerequisites * A `CatalogSource` object of source type `grpc` with `spec.image` is defined. -ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifdef::openshift-dedicated,openshift-rosa[] * You have access to the cluster as a user with the `dedicated-admin` role. -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] .Procedure diff --git a/modules/olm-operator-framework.adoc b/modules/olm-operator-framework.adoc index 6e893115defe..cb055fd599b5 100644 --- a/modules/olm-operator-framework.adoc +++ b/modules/olm-operator-framework.adoc @@ -8,13 +8,7 @@ The Operator Framework is a family of tools and capabilities to deliver on the customer experience described above. It is not just about writing code; testing, delivering, and updating Operators is just as important. The Operator Framework components consist of open source tools to tackle these problems: Operator Lifecycle Manager:: -Operator Lifecycle Manager (OLM) controls the installation, upgrade, and role-based access control (RBAC) of Operators in a cluster. It is deployed by default in -ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[] -{product-title} {product-version}. -endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[] -ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[] -{product-title}. -endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[] +Operator Lifecycle Manager (OLM) controls the installation, upgrade, and role-based access control (RBAC) of Operators in a cluster. It is deployed by default in {product-title} {product-version}. Operator Registry:: The Operator Registry stores cluster service versions (CSVs) and custom resource definitions (CRDs) for creation in a cluster and stores Operator metadata about packages and channels. It runs in a Kubernetes or OpenShift cluster to provide this Operator catalog data to OLM. diff --git a/modules/olm-operatorhub-architecture.adoc b/modules/olm-operatorhub-architecture.adoc index fda352fa3454..18bf2df49aef 100644 --- a/modules/olm-operatorhub-architecture.adoc +++ b/modules/olm-operatorhub-architecture.adoc @@ -11,7 +11,7 @@ The OperatorHub UI component is driven by the Marketplace Operator by default on == OperatorHub custom resource The Marketplace Operator manages an `OperatorHub` custom resource (CR) named `cluster` that manages the default `CatalogSource` objects provided with OperatorHub. -ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifndef::openshift-dedicated,openshift-rosa[] You can modify this resource to enable or disable the default catalogs, which is useful when configuring {product-title} in restricted network environments. .Example `OperatorHub` custom resource @@ -32,4 +32,4 @@ spec: ---- <1> `disableAllDefaultSources` is an override that controls availability of all default catalogs that are configured by default during an {product-title} installation. <2> Disable default catalogs individually by changing the `disabled` parameter value per source. -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] diff --git a/modules/olm-overriding-operator-pod-affinity.adoc b/modules/olm-overriding-operator-pod-affinity.adoc index b1e91bc5817c..11d4bd0a2f1d 100644 --- a/modules/olm-overriding-operator-pod-affinity.adoc +++ b/modules/olm-overriding-operator-pod-affinity.adoc @@ -33,10 +33,10 @@ By default, when you install an Operator, {product-title} installs the Operator The following examples describe situations where you might want to schedule an Operator pod to a specific node or set of nodes: -ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifndef::openshift-dedicated,openshift-rosa[] * If an Operator requires a particular platform, such as `amd64` or `arm64` * If an Operator requires a particular operating system, such as Linux or Windows -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] * If you want Operators that work together scheduled on the same host or on hosts located on the same rack * If you want Operators dispersed throughout the infrastructure to avoid downtime due to network or hardware issues diff --git a/modules/olm-overriding-operatorconditions.adoc b/modules/olm-overriding-operatorconditions.adoc index fbaa79afe23c..105dabab905f 100644 --- a/modules/olm-overriding-operatorconditions.adoc +++ b/modules/olm-overriding-operatorconditions.adoc @@ -6,30 +6,30 @@ [id="olm-supported-operatorconditions_{context}"] = Overriding Operator conditions -ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifndef::openshift-dedicated,openshift-rosa[] As a cluster administrator, -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] +ifdef::openshift-dedicated,openshift-rosa[] As an administrator with the `dedicated-admin` role, -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] you might want to ignore a supported Operator condition reported by an Operator. When present, Operator conditions in the `Spec.Overrides` array override the conditions in the `Spec.Conditions` array, allowing -ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifndef::openshift-dedicated,openshift-rosa[] cluster administrators -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] +ifdef::openshift-dedicated,openshift-rosa[] `dedicated-admin` administrators -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] to deal with situations where an Operator is incorrectly reporting a state to Operator Lifecycle Manager (OLM). [NOTE] ==== By default, the `Spec.Overrides` array is not present in an `OperatorCondition` object until it is added by -ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifndef::openshift-dedicated,openshift-rosa[] a cluster administrator -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] +ifdef::openshift-dedicated,openshift-rosa[] an administrator with the `dedicated-admin` role -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] . The `Spec.Conditions` array is also not present until it is either added by a user or as a result of custom Operator logic. ==== @@ -37,12 +37,12 @@ For example, consider a known version of an Operator that always communicates th .Prerequisites -ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifndef::openshift-dedicated,openshift-rosa[] * You have access to the cluster as a user with the `cluster-admin` role. -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] +ifdef::openshift-dedicated,openshift-rosa[] * You have access to the cluster as a user with the `dedicated-admin` role. -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] * An Operator with an `OperatorCondition` object, installed using OLM. .Procedure @@ -77,9 +77,9 @@ spec: message: "The operator is performing a migration." lastTransitionTime: "2020-08-24T23:15:55Z" ---- -ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifndef::openshift-dedicated,openshift-rosa[] <1> Allows the cluster administrator to change the upgrade readiness to `True`. -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] +ifdef::openshift-dedicated,openshift-rosa[] <1> Allows the `dedicated-admin` user to change the upgrade readiness to `True`. -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] diff --git a/modules/olm-overriding-proxy-settings.adoc b/modules/olm-overriding-proxy-settings.adoc index 9fc51c9defbe..f4fe13a68847 100644 --- a/modules/olm-overriding-proxy-settings.adoc +++ b/modules/olm-overriding-proxy-settings.adoc @@ -7,12 +7,12 @@ = Overriding proxy settings of an Operator If a cluster-wide egress proxy is configured, Operators running with Operator Lifecycle Manager (OLM) inherit the cluster-wide proxy settings on their deployments. -ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifndef::openshift-dedicated,openshift-rosa[] Cluster administrators -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] +ifdef::openshift-dedicated,openshift-rosa[] Administrators with the `dedicated-admin` role -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] can also override these proxy settings by configuring the subscription of an Operator. [IMPORTANT] @@ -22,15 +22,15 @@ Operators must handle setting environment variables for proxy settings in the po .Prerequisites -ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifndef::openshift-dedicated,openshift-rosa[] * Access to an {product-title} cluster using an account with ifdef::openshift-enterprise,openshift-webscale,openshift-origin[] `cluster-admin` permissions. endif::[] -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] +ifdef::openshift-dedicated,openshift-rosa[] * Access to a {product-title} cluster as a user with the `dedicated-admin` role. -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] .Procedure diff --git a/modules/olm-overview.adoc b/modules/olm-overview.adoc index 8dd6fe47db6b..b1d08c277dce 100644 --- a/modules/olm-overview.adoc +++ b/modules/olm-overview.adoc @@ -33,19 +33,20 @@ ifndef::cluster-caps[] .{olmv0} workflow image::olm-workflow.png[] -ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -OLM runs by default in {product-title} {product-version}, which aids cluster administrators -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -OLM runs by default in {product-title}, which aids administrators with the `dedicated-admin` role -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +OLM runs by default in {product-title} {product-version}, which aids +ifndef::openshift-dedicated,openshift-rosa[] +cluster administrators +endif::openshift-dedicated,openshift-rosa[] +ifdef::openshift-dedicated,openshift-rosa[] +administrators with the `dedicated-admin` role +endif::openshift-dedicated,openshift-rosa[] in installing, upgrading, and granting access to Operators running on their cluster. The {product-title} web console provides management screens for -ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifndef::openshift-dedicated,openshift-rosa[] cluster administrators -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] +ifdef::openshift-dedicated,openshift-rosa[] `dedicated-admin` administrators -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] to install Operators, as well as grant specific projects access to use the catalog of Operators available on the cluster. For developers, a self-service experience allows provisioning and configuring instances of databases, monitoring, and big data services without having to be subject matter experts, because the Operator has that knowledge baked into it. diff --git a/modules/olm-preparing-multitenant-operators.adoc b/modules/olm-preparing-multitenant-operators.adoc index 75d8320af3c1..a9d0fcae4abc 100644 --- a/modules/olm-preparing-multitenant-operators.adoc +++ b/modules/olm-preparing-multitenant-operators.adoc @@ -6,21 +6,21 @@ [id="olm-preparing-operators-multitenant_{context}"] = Preparing for multiple instances of an Operator for multitenant clusters -ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifndef::openshift-dedicated,openshift-rosa[] As a cluster administrator, endif::[] -ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifdef::openshift-dedicated,openshift-rosa[] As an administrator with the `dedicated-admin` role, -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] you can add multiple instances of an Operator for use in multitenant clusters. This is an alternative solution to either using the standard *All namespaces* install mode, which can be considered to violate the principle of least privilege, or the *Multinamespace* mode, which is not widely adopted. For more information, see "Operators in multitenant clusters". In the following procedure, the _tenant_ is a user or group of users that share common access and privileges for a set of deployed workloads. The _tenant Operator_ is the instance of an Operator that is intended for use by only that tenant. .Prerequisites -ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifdef::openshift-dedicated,openshift-rosa[] * You have access to the cluster as a user with the `dedicated-admin` role. -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] * All instances of the Operator you want to install must be the same version across a given cluster. + [IMPORTANT] @@ -31,7 +31,7 @@ For more information on this and other limitations, see "Operators in multitenan .Procedure // In OSD/ROSA, dedicated-admins can't create namespaces directly but can create projects. -ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifndef::openshift-dedicated,openshift-rosa[] . Before installing the Operator, create a namespace for the tenant Operator that is separate from the tenant's namespace. For example, if the tenant's namespace is `team1`, you might create a `team1-operator` namespace: .. Define a `Namespace` resource and save the YAML file, for example, `team1-operator.yaml`: @@ -50,16 +50,16 @@ metadata: ---- $ oc create -f team1-operator.yaml ---- -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] // Slightly different step for OSD/ROSA since dedicated-admins can't create namespaces directly. -ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifdef::openshift-dedicated,openshift-rosa[] . Before installing the Operator, create a namespace for the tenant Operator that is separate from the tenant's namespace. You can do this by creating a project. For example, if the tenant's namespace is `team1`, you might create a `team1-operator` project: + [source,terminal] ---- $ oc new-project team1-operator ---- -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] . Create an Operator group for the tenant Operator scoped to the tenant's namespace, with only that one namespace entry in the `spec.targetNamespaces` list: diff --git a/modules/olm-priority-class-name.adoc b/modules/olm-priority-class-name.adoc index 203932d0e55a..5abadae039b1 100644 --- a/modules/olm-priority-class-name.adoc +++ b/modules/olm-priority-class-name.adoc @@ -16,9 +16,9 @@ endif::[] .Prerequisites * A `CatalogSource` object of source type `grpc` with `spec.image` is defined. -ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifdef::openshift-dedicated,openshift-rosa[] * You have access to the cluster as a user with the `dedicated-admin` role. -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] .Procedure diff --git a/modules/olm-sqlite-catalog-configuring-elevated-permissions.adoc b/modules/olm-sqlite-catalog-configuring-elevated-permissions.adoc index 91531b22aadb..887ed3c8e9e8 100644 --- a/modules/olm-sqlite-catalog-configuring-elevated-permissions.adoc +++ b/modules/olm-sqlite-catalog-configuring-elevated-permissions.adoc @@ -19,12 +19,12 @@ The SQLite database catalog format is deprecated, but still supported by Red Hat .Prerequisites * You have a SQLite database catalog source. -ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifndef::openshift-dedicated,openshift-rosa[] * You have access to the cluster as a user with the `cluster-admin` role. -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] +ifdef::openshift-dedicated,openshift-rosa[] * You have access to the cluster as a user with the `dedicated-admin` role. -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] * You have a target namespace that supports running pods with the elevated pod security admission standard of `baseline` or `privileged`. .Procedure @@ -48,11 +48,7 @@ spec: + [TIP] ==== -In {product-title} -ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -{product-version}, -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -the `spec.grpcPodConfig.securityContextConfig` field is set to `legacy` by default. In a future release of {product-title}, it is planned that the default setting will change to `restricted`. If your catalog cannot run under restricted enforcement, it is recommended that you manually set this field to `legacy`. +In {product-title} {product-version}, the `spec.grpcPodConfig.securityContextConfig` field is set to `legacy` by default. In a future release of {product-title}, it is planned that the default setting will change to `restricted`. If your catalog cannot run under restricted enforcement, it is recommended that you manually set this field to `legacy`. ==== . Edit your `.yaml` file to add elevated pod security admission standards to your catalog source namespace, as shown in the following example: diff --git a/modules/olm-tolerations.adoc b/modules/olm-tolerations.adoc index bfdedecc1f6f..4697a2237c27 100644 --- a/modules/olm-tolerations.adoc +++ b/modules/olm-tolerations.adoc @@ -9,9 +9,9 @@ .Prerequisites * A `CatalogSource` object of source type `grpc` with `spec.image` is defined. -ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifdef::openshift-dedicated,openshift-rosa[] * You have access to the cluster as a user with the `dedicated-admin` role. -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] .Procedure diff --git a/modules/olm-updating-index-image.adoc b/modules/olm-updating-index-image.adoc index 3fad7a8bf5ee..45579541b4cc 100644 --- a/modules/olm-updating-index-image.adoc +++ b/modules/olm-updating-index-image.adoc @@ -14,12 +14,12 @@ endif::[] = Updating a SQLite-based index image After configuring OperatorHub to use a catalog source that references a custom index image, -ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifndef::openshift-dedicated,openshift-rosa[] cluster administrators -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] +ifdef::openshift-dedicated,openshift-rosa[] administrators with the `dedicated-admin` role -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] can keep the available Operators on their cluster up-to-date by adding bundle images to the index image. You can update an existing index image using the `opm index add` command. diff --git a/modules/olm-updating-sqlite-catalog-to-a-new-opm-version.adoc b/modules/olm-updating-sqlite-catalog-to-a-new-opm-version.adoc index ba57d7407dba..989510853c34 100644 --- a/modules/olm-updating-sqlite-catalog-to-a-new-opm-version.adoc +++ b/modules/olm-updating-sqlite-catalog-to-a-new-opm-version.adoc @@ -11,17 +11,13 @@ You can rebuild your SQLite database catalog image with the latest version of th .Prerequisites * You have a SQLite database catalog source. -ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifndef::openshift-dedicated,openshift-rosa[] * You have access to the cluster as a user with the `cluster-admin` role. -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] +ifdef::openshift-dedicated,openshift-rosa[] * You have access to the cluster as a user with the `dedicated-admin` role. -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -* You have the latest version of the `opm` CLI tool released with {product-title} -ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -{product-version} -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -on your workstation. +endif::openshift-dedicated,openshift-rosa[] +* You have the latest version of the `opm` CLI tool released with {product-title} {product-version} on your workstation. .Procedure diff --git a/operators/admin/olm-adding-operators-to-cluster.adoc b/operators/admin/olm-adding-operators-to-cluster.adoc index d76f6b5696ab..32f23fed3800 100644 --- a/operators/admin/olm-adding-operators-to-cluster.adoc +++ b/operators/admin/olm-adding-operators-to-cluster.adoc @@ -11,11 +11,12 @@ toc::[] Using Operator Lifecycle Manager (OLM), ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -cluster administrators can install OLM-based Operators to an {product-title} cluster. +cluster administrators endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -administrators with the `dedicated-admin` role can install OLM-based Operators to a {product-title} cluster. +administrators with the `dedicated-admin` role endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +can install OLM-based Operators to an {product-title} cluster. [NOTE] ==== diff --git a/operators/admin/olm-configuring-proxy-support.adoc b/operators/admin/olm-configuring-proxy-support.adoc index ee21faf15378..99727002e128 100644 --- a/operators/admin/olm-configuring-proxy-support.adoc +++ b/operators/admin/olm-configuring-proxy-support.adoc @@ -6,7 +6,7 @@ include::_attributes/common-attributes.adoc[] toc::[] -If a global proxy is configured on your {product-title} cluster, Operator Lifecycle Manager (OLM) automatically configures Operators that it manages with the cluster-wide proxy. However, you can also configure installed Operators to override the global proxy or inject a custom CA certificate. +If a global proxy is configured on the {product-title} cluster, Operator Lifecycle Manager (OLM) automatically configures Operators that it manages with the cluster-wide proxy. However, you can also configure installed Operators to override the global proxy or inject a custom CA certificate. [role="_additional-resources"] .Additional resources @@ -15,9 +15,9 @@ If a global proxy is configured on your {product-title} cluster, Operator Lifecy ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] * xref:../../networking/configuring_network_settings/enable-cluster-wide-proxy.adoc#enable-cluster-wide-proxy[Configuring the cluster-wide proxy] endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifdef::openshift-dedicated,openshift-rosa[] * xref:../../networking/ovn_kubernetes_network_provider/configuring-cluster-wide-proxy.adoc#configuring-cluster-wide-proxy[Configuring a cluster-wide proxy] -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +endif::openshift-dedicated,openshift-rosa[] // This xref points to a topic that is not currently included in the OSD and ROSA docs. ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] diff --git a/operators/admin/olm-cs-podsched.adoc b/operators/admin/olm-cs-podsched.adoc index d85ab74faecc..0c192fa82216 100644 --- a/operators/admin/olm-cs-podsched.adoc +++ b/operators/admin/olm-cs-podsched.adoc @@ -16,7 +16,7 @@ As an administrator, you can override these values by modifying fields in the `C [IMPORTANT] ==== -The Marketplace Operator, `openshift-marketplace`, manages the default `OperatorHub` custom resource's (CR). This CR manages `CatalogSource` objects. If you attempt to modify fields in the `CatalogSource` object's `spec.grpcPodConfig` section, the Marketplace Operator automatically reverts these modifications. By default, if you modify fields in the `spec.grpcPodConfig` section of the `CatalogSource` object, the Marketplace Operator automatically reverts these changes. +The Marketplace Operator, `openshift-marketplace`, manages the default `OperatorHub` custom resource's (CR). This CR manages `CatalogSource` objects. If you attempt to modify fields in the `CatalogSource` object’s `spec.grpcPodConfig` section, the Marketplace Operator automatically reverts these modifications.By default, if you modify fields in the `spec.grpcPodConfig` section of the `CatalogSource` object, the Marketplace Operator automatically reverts these changes. To apply persistent changes to `CatalogSource` object, you must first disable a default `CatalogSource` object. ==== diff --git a/operators/admin/olm-managing-custom-catalogs.adoc b/operators/admin/olm-managing-custom-catalogs.adoc index e6194c00c4f7..a52c03ab15f0 100644 --- a/operators/admin/olm-managing-custom-catalogs.adoc +++ b/operators/admin/olm-managing-custom-catalogs.adoc @@ -86,7 +86,10 @@ include::modules/olm-catalog-source-and-psa.adoc[leveloffset=+1] [role="_additional-resources"] .Additional resources +// TODO-HCP remove conditions for HCP after cli_tools book is migrated +ifndef::openshift-rosa-hcp[] * xref:../../authentication/understanding-and-managing-pod-security-admission.adoc#understanding-and-managing-pod-security-admission[Understanding and managing pod security admission] +endif::openshift-rosa-hcp[] include::modules/olm-migrating-sqlite-catalog-to-fbc.adoc[leveloffset=+2] diff --git a/operators/understanding/olm-multitenancy.adoc b/operators/understanding/olm-multitenancy.adoc index 588a839fec44..002ff524703d 100644 --- a/operators/understanding/olm-multitenancy.adoc +++ b/operators/understanding/olm-multitenancy.adoc @@ -6,14 +6,7 @@ include::_attributes/common-attributes.adoc[] toc::[] -The default behavior for Operator Lifecycle Manager (OLM) aims to provide simplicity during Operator installation. However, this behavior can lack flexibility, especially in multitenant clusters. In order for multiple tenants on -ifndef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[] -an {product-title} -endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[] -ifdef::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[] -a {product-title} -endif::openshift-rosa,openshift-rosa-hcp,openshift-dedicated[] -cluster to use an Operator, the default behavior of OLM requires that administrators install the Operator in *All namespaces* mode, which can be considered to violate the principle of least privilege. +The default behavior for Operator Lifecycle Manager (OLM) aims to provide simplicity during Operator installation. However, this behavior can lack flexibility, especially in multitenant clusters. In order for multiple tenants on a {product-title} cluster to use an Operator, the default behavior of OLM requires that administrators install the Operator in *All namespaces* mode, which can be considered to violate the principle of least privilege. Consider the following scenarios to determine which Operator installation workflow works best for your environment and requirements. diff --git a/operators/understanding/olm-packaging-format.adoc b/operators/understanding/olm-packaging-format.adoc index 73d99a4ffc45..7e6543cd0afa 100644 --- a/operators/understanding/olm-packaging-format.adoc +++ b/operators/understanding/olm-packaging-format.adoc @@ -17,8 +17,10 @@ include::modules/olm-dependencies.adoc[leveloffset=+2] * xref:../../operators/understanding/olm/olm-understanding-dependency-resolution.adoc#olm-understanding-dependency-resolution[Operator Lifecycle Manager dependency resolution] include::modules/olm-about-opm.adoc[leveloffset=+2] - +// TODO-HCP remove conditions for HCP after cli_tools book is migrated +ifndef::openshift-rosa-hcp[] * See xref:../../cli_reference/opm/cli-opm-install.adoc#cli-opm-install[CLI tools] for steps on installing the `opm` CLI. +endif::openshift-rosa-hcp[] ifdef::openshift-origin[] [id="olm-packaging-format-addtl-resources"] @@ -68,7 +70,9 @@ include::modules/olm-fb-catalogs-guidelines.adoc[leveloffset=+2] === CLI usage For instructions about creating file-based catalogs by using the `opm` CLI, see xref:../../operators/admin/olm-managing-custom-catalogs.adoc#olm-creating-fb-catalog-image_olm-managing-custom-catalogs[Managing custom catalogs]. - +// TODO-HCP remove conditions for HCP after cli_tools book is migrated +ifndef::openshift-rosa-hcp[] For reference documentation about the `opm` CLI commands related to managing file-based catalogs, see xref:../../cli_reference/opm/cli-opm-ref.adoc#cli-opm-ref[CLI tools]. +endif::openshift-rosa-hcp[] include::modules/olm-fb-catalogs-automation.adoc[leveloffset=+2]