OSDOCS-14501: Prune Operators

modules/olm-about-catalogs.adoc

@@ -10,7 +10,14 @@ 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 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 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 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.
 

modules/olm-catalog-source-and-psa.adoc

@@ -8,13 +8,25 @@
 
 _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.
 
-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`.
+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`.
 
 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 {product-title} {product-version}.
+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[]
 
 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.
 ====

modules/olm-catalogsource-image-template.adoc

@@ -12,7 +12,13 @@ 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 {product-title} {product-version}.
+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[]
 
 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:
 
@@ -38,7 +44,7 @@ Starting in {product-title} 4.9, cluster administrators can add the `olm.catalog
 
 [NOTE]
 ====
-You must specify the Kubernetes cluster version and not an {product-title} cluster version, as the latter is not currently available for templating.
+You must specify the Kubernetes cluster version and not the {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.
@@ -77,7 +83,14 @@ 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 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:
+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:
 
 [source,terminal]
 ----

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[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 As a cluster administrator,
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 As an administrator with the `dedicated-admin` role,
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 you can bypass this default behavior manually by using the following workflow:
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 . Create a namespace for the installation of the Operator.
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 // In OSD/ROSA, dedicated-admins can create projects, but not namespaces.
-ifdef::openshift-dedicated,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 . Create a project for the installation of the Operator.
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 . 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.
 

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[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 Cluster administrators
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 Administrators with the `dedicated-admin` role
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 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[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 [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[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 // In OSD/ROSA, a dedicated-admin can update catalog sources in the console by searching for them.
-ifdef::openshift-dedicated,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 [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[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 .Prerequisites
 
 * You built and pushed an index image to a registry.
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * You have access to the cluster as a user with the `cluster-admin` role.
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * You have access to the cluster as a user with the `dedicated-admin` role.
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 .Procedure
 

modules/olm-creating-etcd-cluster-from-operator.adoc

@@ -6,25 +6,25 @@ This procedure walks through creating a new etcd cluster using the etcd Operator
 
 .Prerequisites
 
-ifndef::openshift-dedicated,openshift-rosa[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 * Access to an {product-title} {product-version} cluster.
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
-* Access to an {product-title} cluster.
-endif::openshift-dedicated,openshift-rosa[]
+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[]
 * The etcd Operator already installed cluster-wide by an administrator.
 
 .Procedure
 
 . 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[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 cluster administrator
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 dedicated-admin
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 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 <user> -n <target_project>
 ----
 
 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[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 cluster administrators
-endif::openshift-dedicated,openshift-rosa[]
-ifdef::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 dedicated-admins
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 or developers with proper access can now easily use the database with their applications.

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 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.
+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.
 
 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.
 

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 an {product-title} cluster using an account with
+- You have access to the {product-title} cluster using an account with
 ifdef::openshift-enterprise,openshift-webscale,openshift-origin[]
 `cluster-admin` permissions.
 endif::[]
-ifdef::openshift-dedicated,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 `dedicated-admin` permissions.
-endif::openshift-dedicated,openshift-rosa[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 - The OpenShift CLI (`oc`) is installed on your workstation.
 
 .Procedure

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 an {product-title} cluster web console using an account with
+- You have access to the {product-title} cluster web console using an account with
 ifdef::openshift-enterprise,openshift-webscale,openshift-origin[]
 `cluster-admin` permissions.
 endif::[]

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} cluster, OLM reads catalog sources to know which Operators are available for installation.
+On {product-title} clusters, 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 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`).
+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`).
 
 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.
 

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[]
+ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 [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[]
+endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
 
 .Prerequisites
 * You have the following on your workstation: