Skip to content

Various OLM/OSDK 4.6 relnotes #25624

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
adellape merged 1 commit into from
Oct 13, 2020
Merged

Various OLM/OSDK 4.6 relnotes #25624

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
130 changes: 116 additions & 14 deletions release_notes/ocp-4-6-release-notes.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -187,7 +187,7 @@ addresses and public load balancers.
[id="ocp-4-6-vsphere-v7"]
==== Installing a cluster to vSphere version 7.0

You can now deploy a cluster to VMware vSphere version 7.0. See xref:../installing/installing_vsphere/installing-vsphere-installer-provisioned.html#installation-vsphere-infrastructure_installing-vsphere-installer-provisioned[VMware vSphere infrastructure requirements] for more information.
You can now deploy a cluster to VMware vSphere version 7.0. See xref:../installing/installing_vsphere/installing-vsphere-installer-provisioned.adoc#installation-vsphere-infrastructure_installing-vsphere-installer-provisioned[VMware vSphere infrastructure requirements] for more information.

[id="ocp-4-6-bare-metal-ipi"]
==== Installing a cluster on bare metal using installer-provisioned infrastructure
Expand Down Expand Up @@ -248,6 +248,13 @@ controlPlane:
...
----

[id="ocp-4-6-latest-version-operators-required"]
==== Latest version of Operators required before cluster upgrade

Starting in {product-title} 4.6, the Red Hat-provided default catalogs used by Operator Lifecycle Manager (OLM) and OperatorHub are now shipped as index images specific to the minor version of {product-title}. Cluster administrators must ensure all Operators previously installed through OLM are updated to their latest versions in their latest channels before upgrading to {product-title} 4.6.

See xref:../release_notes/ocp-4-6-release-notes.adoc#ocp-4-6-operator-catalogs-per-version[Default Operator catalogs now shipped per cluster version] for more details and important Operator upgrade prerequisites.

[id="ocp-4-6-security"]
=== Security

Expand Down Expand Up @@ -471,22 +478,56 @@ The Local Storage Operator now has the ability to:
* Automatically provision local persistent volumes from attached devices. Appropriate devices are filtered and persistent volumes are provisioned based on the filtered devices.

[id="ocp-4-6-operators"]
=== Operators
=== Operator lifecycle

[id="ocp-4-6-metering-operator"]
==== Configuring a retention period of metering Reports
[id="ocp-4-6-version-dependency"]
==== Operator version dependency

Operator developers can now ensure their Operators include dependencies on specific versions of other Operators by using the `olm.package` type in the `dependencies.yaml` file.

See xref:../operators/understanding/olm/olm-understanding-dependency-resolution.adoc#olm-bundle-format-dependencies_olm-understanding-dependency-resolution[Operator Lifecycle Manager dependency resolution] for more information.

[id="ocp-4-6-addtl-objects-bundle"]
==== Additional objects supported in Operator bundles

The Operator Bundle Format now supports the following additional Kubernetes objects:

* PodDisruptionBudget
* PriorityClass
* VerticalPodAutoScaler

See xref:../operators/understanding/olm-packaging-format.adoc#olm-bundle-format-manifests-optional_olm-packaging-format[Operator Framework packaging formats] for more information.

[id="ocp-4-6-selective-mirroring-opm"]
==== Selective bundle image mirroring with `opm`

Operator administrators can now to select which bundle images to mirror by using the `opm index prune` command.

You can now set a retention period on a metering Report. The metering Report custom resource
has a new `expiration` field. If the `expiration` duration value is set on a Report,
and no other Reports or ReportQueries depend on the expiring Report, the Metering Operator
removes the Report from your cluster at the end of its retention period. For more information,
see metering Reports xref:../metering/reports/metering-about-reports.adoc#metering-expiration_metering-about-reports[expiration].
See xref:../operators/admin/olm-restricted-networks.adoc#olm-restricted-networks[Pruning an index image] for more information.

[id="ocp-4-6-conversion-webhook-support"]
==== Conversion webhook support for global Operators

Operator developers can now use conversion webhooks for Operators that target all namespaces, also known as global Operators.

See xref:../operators/operator_sdk/osdk-generating-csvs.adoc#olm-defining-csv-webhook_osdk-generating-csvs[Defining webhooks] for more information.

[id="ocp-4-6-images"]
=== Images

[id="ocp-4-6-samples-operator"]
==== Cluster Samples Operator on Power and Z

Imagestreams and templates for Power and Z architectures are now available and installed by the Cluster Samples Operator by default.

[id="ocp-4-6-metering"]
=== Metering

[id="ocp-4-6-metering-operator"]
==== Configuring a retention period of metering Reports

You can now set a retention period on a metering Report. The metering Report custom resource has a new `expiration` field. If the `expiration` duration value is set on a Report, and no other Reports or ReportQueries depend on the expiring Report, the Metering Operator removes the Report from your cluster at the end of its retention period. For more information, see metering Reports xref:../metering/reports/metering-about-reports.adoc#metering-expiration_metering-about-reports[expiration].

[id="ocp-4-6-nodes"]
=== Nodes

Expand All @@ -504,7 +545,7 @@ See xref:../nodes/nodes/nodes-nodes-audit-config.adoc#nodes-nodes-audit-config[C
[id="ocp-4-6-logging-api-ga"]
==== Log Forwarding API is generally available

The xref:../logging/cluster-logging-external.adoc[Log Forwarding API] is now generally available. The Log Forwarding API allows you to send container, infrastructure, and audit logs to specific endpoints within and outside your cluster by configuring a custom resource with the endpoints to forward the logs. The Log Forwarding API now supports forwarding to Kafka brokers and supports syslog RFC 3164 and RFC 5424 including TLS. You can also forward application logs from a specific projects to an endpoint.
The xref:../logging/cluster-logging-external.adoc[Log Forwarding API] is now generally available. The Log Forwarding API allows you to send container, infrastructure, and audit logs to specific endpoints within and outside your cluster by configuring a custom resource with the endpoints to forward the logs. The Log Forwarding API now supports forwarding to Kafka brokers and supports syslog RFC 3164 and RFC 5424 including TLS. You can also forward application logs from a specific projects to an endpoint.

With the GA, the Log Forwarding API has a number of changes, including changes to parameter names in the Log Forwarding custom resource (CR). If you used the Log Forwarding Technology Preview, you need to manually make the needed changes to your existing Log Forwarding CR.

Expand All @@ -522,7 +563,7 @@ Two new dashboards have been added to the {product-title} web console that displ

The *OpenShift Logging* dashboard contains charts that show details about your Elasticsearch instance at a cluster-level, including cluster resources, garbage collection, shards in the cluster, and Fluentd statistics.

The *Logging/Elasticsearch Nodes* dashboard contains charts that show details about your Elasticsearch instance, many at node-level, including details on indexing, shards, resources, and so forth.
The *Logging/Elasticsearch Nodes* dashboard contains charts that show details about your Elasticsearch instance, many at node-level, including details on indexing, shards, resources, and so forth.

[discrete]
[id="ocp-4-6-fluentd-parameters"]
Expand All @@ -534,13 +575,42 @@ New Fluentd parameters allow you to performance-tune your Fluentd log collector.
* the Fluentd chunk flushing behavior
* the Fluentd chunk forwarding retry behavior

These parameters can help you determine the trade-offs between latency and throughput in your cluster logging instance.
These parameters can help you determine the trade-offs between latency and throughput in your cluster logging instance.

[id="ocp-4-6-notable-technical-changes"]
== Notable technical changes

{product-title} 4.6 introduces the following notable technical changes.

[discrete]
[id="ocp-4-6-operator-catalogs-per-version"]
==== Default Operator catalogs now shipped per cluster version

Starting in {product-title} 4.6, the Red Hat-provided default catalogs used by Operator Lifecycle Manager (OLM) and OperatorHub are now shipped as index images specific to the minor version of {product-title}. This allows Operator providers to ship intentional ranges of Operator versions per cluster version.

These index images, based on the Bundle Format, replace the App Registry catalog images, based on the deprecated Package Manifest Format, that are distributed for previous versions of {product-title} 4. {product-title} 4.1 through 4.5 will continue to share a single App Registry catalog.

[NOTE]
====
While App Registry catalog images are not distributed by Red Hat for {product-title} 4.6 and later, custom catalog images based on the Package Manifest Format are still supported.
====

See xref:../operators/understanding/olm-packaging-format.adoc#olm-bundle-format_olm-packaging-format[Operator Framework packaging formats] for more information on the Bundle Format and index images.

[discrete]
[id="ocp-4-6-operator-catalogs-upgrade"]
===== Important Operator upgrade requirements

Cluster administrators must ensure all Operators previously installed through Operator Lifecycle Manager (OLM) are updated to their latest versions in their latest channels before upgrading to {product-title} 4.6. Updating the Operators ensures that they have a valid upgrade path when the default OperatorHub catalogs switch from using the App Registry catalogs in {product-title} 4.5 to the new index image-based catalogs in {product-title} 4.6 during the cluster upgrade.

See xref:../operators/admin/olm-upgrading-operators.adoc#olm-upgrading-operators[Upgrading installed Operators] for more information on ensuring installed Operators are on the latest channels and upgraded either using automatic or manual approval strategies.

.Additional resources

* See the following Red Hat Knowledgebase Article for a list of minimum versions of deployed Red Hat Integration components (including Red Hat Fuse, Red Hat AMQ, and Red Hat 3scale) that are required for {product-title} 4.6:
+
link:https://access.redhat.com/articles/5423161[]

[discrete]
[id="ocp-4-6-ovn-k8s-default-cni-np-uses-ovs-on-cluster-nodes"]
==== OVN-Kubernetes default CNI network provider now uses OVS installed on cluster nodes
Expand All @@ -564,6 +634,31 @@ warnings.go:67] batch/v1beta1 CronJob is deprecated in v1.22+, unavailable in v1

This is new functionality included with Kubernetes 1.19.

[discrete]
[id="ocp-4-6-operator-sdk-v-0-19-4"]
==== Operator SDK v0.19.4

{product-title} supports Operator SDK v0.19.4, which introduces the following
notable technical changes:

* Operator SDK now aligns with the {product-title}-wide switch to using UBI-8
and Python 3. Downstream base images now use UBI-8 and include Python 3.
* The command `run --local` is deprecated in favor of `run local`.
* The commands `run --olm` and `--kubeconfig` are deprecated in favor of `run packagemanifests`.
* The default CRD version changed from `apiextensions.k8s.io/v1beta1` to `apiextensions.k8s.io/v1` for commands that create or generate CRDs.
* The `--kubeconfig` flag is added to the `<run|cleanup> packagemanifests` command.

Ansible-based Operator enhancements include:

* The Ansible Operator is now available as a supported release.
* The Ansible Operator now includes a `healthz` endpoint and `liveness` probe.

Helm-based Operator enhancements include:

* Helm Operators can watch and reconcile when cluster-scoped release resources are changed.
* Helm Operators can now reconcile logic by using three-way strategic merge patches for native Kubernetes objects so that array patch strategies are correctly honored and applied.
* Helm Operators have the default API version changed to `helm.operator-sdk/v1alpha1`.

[id="ocp-4-6-deprecated-removed-features"]
== Deprecated and removed features

Expand Down Expand Up @@ -607,7 +702,12 @@ In the table, features are marked with the following statuses:
|REM
|REM

|Operator Framework's Package Manifest Format
|Package Manifest Format (Operator Framework)
|DEP
|DEP
|DEP

|`oc adm catalog build`
|DEP
|DEP
|DEP
Expand Down Expand Up @@ -792,7 +892,7 @@ In the table below, features are marked with the following statuses:
|Operator API
|-
|TP
|
|GA

|====

Expand Down Expand Up @@ -879,6 +979,8 @@ $ gcloud compute firewall-rules delete <firewall_rule_name>
Once the firewall rule of the machine with the missing infrastructure ID is removed, the cluster can be destroyed.
(link:https://bugzilla.redhat.com/show_bug.cgi?id=1801968[*BZ#1801968*])

* The `opm alpha bundle build` command fails on Windows 10. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1883773[*BZ#1883773*])

[id="ocp-4-6-asynchronous-errata-updates"]
== Asynchronous errata updates

Expand Down