diff --git a/release_notes/ocp-4-9-release-notes.adoc b/release_notes/ocp-4-9-release-notes.adoc index 2e2c3d28cffb..7db388b477be 100644 --- a/release_notes/ocp-4-9-release-notes.adoc +++ b/release_notes/ocp-4-9-release-notes.adoc @@ -417,6 +417,8 @@ For more information, see xref:../storage/persistent_storage/persistent-storage- [id="ocp-4-9-olm"] === Operator lifecycle +The following new features and enhancements relate to running Operators with Operator Lifecycle Manager (OLM). + [id="ocp-4-9-olm-k8s-1-22"] ==== Operator Lifecycle Manager (OLM) upgraded to Kubernetes 1.22 @@ -427,6 +429,15 @@ Starting in {product-title} {product-version}, Operator Lifecycle Manager (OLM) Kubernetes 1.22 introduces link:https://kubernetes.io/docs/reference/using-api/deprecation-guide/#customresourcedefinition-v122[several notable changes] to `v1` of the `CustomResorceDefinition` API. ==== +[id="ocp-4-9-fb-catalogs"] +==== File-based catalogs + +File-based catalogs are the latest iteration of the catalog format in Operator Lifecycle Manager (OLM). The format is a plain text-based (JSON or YAML) and declarative config evolution of the earlier, and now deprecated, xref:../release_notes/ocp-4-9-release-notes.adoc#ocp-4-9-sqlite-catalogs-deprecated[SQLite database format], and it is fully backwards compatible. The goal of this format is to enable Operator catalog editing, composability, and extensibility. + +For more information about the file-based catalog specification, see xref:../operators/understanding/olm-packaging-format.adoc#olm-file-based-catalogs_olm-packaging-format[Operator Framework packaging format]. + +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]. + [id="ocp-4-9-olm-operand-deletion"] ==== Removing Operands when uninstalling an Operator using the web console @@ -449,9 +460,29 @@ Before this release, if an install plan failed, the subscription condition would ===== Indicating resolution conflicts on subscription statuses Because dependency resolution treats all components in a namespace as a single unit, if a resolution failure occurs, all subscriptions on the namespace now indicate the error. +[id="ocp-4-9-catalog-image-template"] +==== Image template for custom catalog sources + +To avoid cluster upgrades potentially leaving Operator installations in an unsupported state or without a continued update path, you can enable automatically changing your Operator catalog's index image version as part of cluster upgrades. + +Set the `olm.catalogImageTemplate` annotation to your catalog image name and use one or more of the Kubernetes cluster version variables when constructing the template for the image tag. + +For more information, see xref:../operators/understanding/olm/olm-understanding-olm.adoc#olm-catalogsource-image-template_olm-understanding-olm[Image template for custom catalog sources]. + [id="ocp-4-9-osdk"] === Operator development +The following new features and enhancements relate to developing Operators with the Operator SDK. + +[id="ocp-4-9-osdk-ha-sno"] +==== High-availability or single node cluster detection and support + +An {product-title} cluster can be configured in high-availability (HA) mode, which uses multiple nodes, or in non-HA mode, which uses a single node. A single node cluster, also known as Single Node OpenShift (SNO), is likely to have more conservative resource constraints. Therefore, it is important that Operators installed on a single node cluster can adjust accordingly and still run well. + +By accessing the cluster high-availability mode API provided in {product-title}, Operator authors can use the Operator SDK to enable their Operator to detect a cluster's infrastructure topology, either HA or non-HA mode. Custom Operator logic can be developed that uses the detected cluster topology to automatically switch the resource requirements, both for the Operator and for any Operands or workloads it manages, to a profile that best fits the topology. + +For more information, see xref:../operators/operator_sdk/osdk-ha-sno.adoc#osdk-ha-sno[High-availability or single node cluster detection and support]. + [id="ocp-4-9-builds"] === Builds @@ -593,6 +624,8 @@ For more information, see xref:../authentication/managing_cloud_provider_credent {product-title} 4.9 introduces the following notable technical changes. +// Note: use [discrete] for these sub-headings. + [discrete] [id="octavia-ovn-nodeport-changes"] ==== Octavia OVN NodePort changes @@ -603,8 +636,6 @@ Previously, on {rh-openstack-first} deployments, opening traffic on NodePorts wa ==== OpenStack Platform LoadBalancer configuration changes The {rh-openstack-first} cloud provider LoadBalancer configuration now defaults to `use-octavia=True`. An exception to this rule is a deployment with Kuryr, in which case `use-octavia` is set to `false`, because Kuryr handles LoadBalancer services on its own. -// Note: use [discrete] for these sub-headings. - [discrete] [id="ocp-4-9-haproxy-2.2.15-upgrade"] ==== Ingress Controller upgraded to HAProxy 2.2.15 @@ -637,6 +668,19 @@ For more information, see the xref:../operators/operator-reference.adoc#cluster- With {product-title} 4.9, a new process to perform a canary rollout update has been introduced. For a detailed overview of this process, see xref:../updating/update-using-custom-machine-config-pools.adoc#update-using-custom-machine-config-pools[Performing a canary rollout update]. +[discrete] +[id="ocp-4-9-operator-sdk-v-1-10-1"] +==== Operator SDK v1.10.1 + +{product-title} 4.9 supports Operator SDK v1.10.1. See xref:../cli_reference/osdk/cli-osdk-install.adoc#cli-osdk-install[Installing the Operator SDK CLI] to install or update to this latest version. + +[NOTE] +==== +Operator SDK v1.10.1 supports Kubernetes 1.21. +==== + +If you have any Operator projects that were previously created or maintained with Operator SDK v1.8.0, see xref:../operators/operator_sdk/osdk-upgrading-projects.adoc#osdk-upgrading-projects[Upgrading projects for newer Operator SDK versions] to ensure your projects are upgraded to maintain compatibility with Operator SDK v1.10.1. + [id="ocp-4-9-deprecated-removed-features"] == Deprecated and removed features @@ -661,17 +705,22 @@ In the table, features are marked with the following statuses: |Package manifest format (Operator Framework) |DEP |REM -| +|REM + +|SQLite database format for Operator catalogs +|GA +|GA +|DEP |`oc adm catalog build` |DEP |REM -| +|REM |`--filter-by-os` flag for `oc adm catalog mirror` |DEP |REM -| +|REM |v1beta1 CRDs |DEP @@ -743,6 +792,16 @@ In the table, features are marked with the following statuses: [id="ocp-4-9-deprecated-features"] === Deprecated features +[id="ocp-4-9-sqlite-catalogs-deprecated"] +==== SQLite database format for Operator catalogs + +The SQLite database format used by Operator Lifecycle Manager (OLM) for catalogs and index images has been deprecated, including the related `opm` CLI commands. Cluster administrators and catalog maintainers are encouraged to familiarize themselves with the new xref:../release_notes/ocp-4-9-release-notes.adoc#ocp-4-9-fb-catalogs[file-based catalog format] introduced in {product-title} 4.9 and begin migrating catalog workflows. + +[NOTE] +==== +The default xref:../operators/understanding/olm-rh-catalogs.adoc#olm-rh-catalogs[Red Hat-provided Operator catalogs] for {product-title} 4.6 and later are currently still shipped in the SQLite database format. +==== + [id="ocp-4-9-removed-features"] === Removed features