You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: modules/olm-about-catalogs.adoc
+8-1Lines changed: 8 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,7 +10,14 @@ An Operator catalog is a repository of metadata that Operator Lifecycle Manager
10
10
11
11
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.
12
12
13
-
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.
13
+
As catalogs are updated, the latest versions of Operators change, and older versions may be removed or altered. In addition, when OLM runs on
cluster in a restricted network environment, it is unable to access the catalogs directly from the internet to pull the latest content.
14
21
15
22
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.
Copy file name to clipboardExpand all lines: modules/olm-catalog-source-and-psa.adoc
+14-2Lines changed: 14 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,13 +8,25 @@
8
8
9
9
_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.
10
10
11
-
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`.
namespaces do not have restricted pod security enforcement by default and the default catalog source security mode is set to `legacy`.
12
18
13
19
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.
14
20
15
21
[NOTE]
16
22
====
17
-
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}.
23
+
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
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.
Copy file name to clipboardExpand all lines: modules/olm-catalogsource-image-template.adoc
+16-3Lines changed: 16 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,7 +12,13 @@ endif::[]
12
12
[id="olm-catalogsource-image-template_{context}"]
13
13
= Image template for custom catalog sources
14
14
15
-
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}.
15
+
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
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:
18
24
@@ -38,7 +44,7 @@ Starting in {product-title} 4.9, cluster administrators can add the `olm.catalog
38
44
39
45
[NOTE]
40
46
====
41
-
You must specify the Kubernetes cluster version and not an {product-title} cluster version, as the latter is not currently available for templating.
47
+
You must specify the Kubernetes cluster version and not the {product-title} cluster version, as the latter is not currently available for templating.
42
48
====
43
49
44
50
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
77
83
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.
78
84
====
79
85
80
-
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:
Copy file name to clipboardExpand all lines: modules/olm-colocation-namespaces.adoc
+8-8Lines changed: 8 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -20,21 +20,21 @@ These scenarios can lead to the following issues:
20
20
21
21
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.
. 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.
39
39
. Install the desired Operator in the installation namespace.
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.
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.
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.
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,
Copy file name to clipboardExpand all lines: modules/olm-csv.adoc
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,7 +5,7 @@
5
5
[id="olm-csv_{context}"]
6
6
= Cluster service version
7
7
8
-
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.
8
+
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.
9
9
10
10
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.
Copy file name to clipboardExpand all lines: modules/olm-dependency-resolution-preferences.adoc
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,7 +10,7 @@ There can be many options that equally satisfy a dependency of an Operator. The
10
10
[id="olm-dependency-catalog-priority_{context}"]
11
11
== Catalog priority
12
12
13
-
On {product-title} cluster, OLM reads catalog sources to know which Operators are available for installation.
13
+
On {product-title} clusters, OLM reads catalog sources to know which Operators are available for installation.
14
14
15
15
.Example `CatalogSource` object
16
16
[source,yaml]
@@ -40,7 +40,7 @@ There are two rules that govern catalog preference:
40
40
[id="olm-dependency-catalog-ordering_{context}"]
41
41
== Channel ordering
42
42
43
-
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`).
43
+
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`).
44
44
45
45
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.
0 commit comments