OpenShift Container Platform 4.10 release notes

GA: General Availability

DEP: Deprecated

REM: Removed

Previously, using a MAC address to configure a provisioning network interface was unsupported when switching the provisioning network from Disabled to Managed. With this update, a provisioningMacAddresses field is added to the provisioning.metal3.io CRD. Use this field to identify the provisioning network interface using its MAC address rather than its name. (BZ#2000081)

Previously, Ironic failed to attach virtual media images for provisioning SuperMicro X11/X12 servers because these models expect a non-standard device string, for example UsbCd, for CD-based virtual media. With this update, provisioning now overrides UsbCd on SuperMicro machines provisioned with CD-based virtual media. (BZ#2009555)

Previously, Ironic failed to attach virtual media images on SuperMicro X11/X12 servers due to overly restrictive URl validations on the BMCs of these machines. With this update, the filename parameter has now been removed from the URL if the virtual media image is backed by a local file. As a result, the parameter still passes if the image is backed by an object store. (BZ#2011626)

Previously, the curl utility, used by the machine downloader image, did not support classless inter-domain routing (CIDR) with no_proxy. A a result, any CIDR in`noProxy` was ignored when downloading the Red Hat Enterprise Linux CoreOS (RHCOS) image. With this update, proxies are now removed from the environment before calling curl when appropriate. As a result, when downloading the machine image, any CIDR in no_proxy is no longer ignored. (BZ#1990556)

Previously, virtual media based deployments of OpenShift Container Platform have been observed to intermittently fail on iDRAC hardware types. This occurred when outstanding Lifecycle Controller jobs clashed with virtual media configuration requests. With this update, virtual media deployment failure has been fixed by purging any Lifecycle Controller job while registering iDRAC hardware prior to deployment. (BZ#1988879)

Previously, users had to enter a long form of an IPv6 address in the installation configuration file, for example 2001:0db8:85a3:0000:0000:8a2e:0370:7334. Ironic could not find an interface matching this IP address causing the installation to fail. With this update, the IPv6 address supplied by the user is converted to a short form address, for example, 2001:db8:85a3::8a2e:370:7334. As a result, installation is now successful. (BZ#2010698)

Before this update, when a Redfish system features a Settings URI, the Ironic provisioning service always attempts to use this URI to make changes to boot-related BIOS settings. However, bare-metal provisioning fails if the Baseboard Management Controller (BMC) features a Settings URI but does not support changing a particular BIOS setting by using this Settings URI. In OpenShift Container Platform 4.10 and later, if a system features a Settings URI, Ironic verifies that it can change a particular BIOS setting by using the Settings URI before proceeding. Otherwise, Ironic implements the change by using the System URI. This additional logic ensures that Ironic can apply boot-related BIOS setting changes and bare-metal provisioning can succeed. (OCPBUGS-6886)

Before this update, if you created a build configuration containing an image change trigger in OpenShift Container Platform 4.7.x or earlier, the image change trigger might trigger builds continuously.

Before this update, image references in Builds needed to specify the Red Hat registry name explicitly. With this update, if an image reference does not contain the registry, the Build searches the Red Hat registries and other well-known registries to locate the image. (BZ#2011293)

Before this update, version 1.0.48 of the OpenShift Jenkins Sync Plugin introduced a NullPointerException error when Jenkins notified the plugin of new jobs that were not associated with an OpenShift Jenkins Pipeline Build Strategy Build Config. Ultimately, this error was benign because there was no BuildConfig object to associate with the incoming Jenkins Job. Core Jenkins ignored the exception in our plugin and moved on to the next listener. However, a long stack trace showed up in the Jenkins log that distracted users. With this update, the plugin resolves the issue by making the proper checks to avoid this error and the subsequent stack trace. (BZ#2030692)

Before this update, performance improvements in version 1.0.48 of the OpenShift Sync Jenkins plugin incorrectly specified the labels accepted for ConfigMap and ImageStream objects intended to map into the Jenkins Kubernetes plugin pod templates. As a result, the plugin no longer imported pod templates from ConfigMap and ImageStream objects with a jenkins-agent label.

Previously, editing a machine specification on Red Hat OpenStack Platform (RHOSP) would cause OpenShift Container Platform to attempt to delete and recreate the machine. As a result, this caused an unrecoverable loss of the node it was hosting. With this fix, any edits made to the machine specification after creation are ignored. (BZ#1962066)

Previously, on clusters that run on Red Hat OpenStack Platform (RHOSP), floating IP addresses were not reported for machine objects. As a result, certificate signing requests (CSRs) that the kubelet created were not accepted, preventing nodes from joining the cluster. All IP addresses are now reported for machine objects. (BZ#2022627)

Previously, the check to ensure that the AWS machine was not updated before requeueing was removed. Consequently, problems arose when the AWS machine’s virtual machine had been removed, but its object was still available. If this happens, the AWS machine would requeue in an infinite loop and could not be deleted or updated. This update restores the check that was used to ensure that the AWS machine was not updated before requeueing. As a result, machines no longer requeue if they have been updated. (BZ#2007802)

Previously, modifying a selector changed the list of machines that a machine set observed. As a result, leaks could occur because the machine set lost track of machines it had already created. This update ensures that the selector is immutable once created. As a result, machine sets now lists the correct machines. (BZ#2005052)

Previously, if a virtual machine template had snapshots, an incorrect disk size was picked due to an incorrect usage of the linkedClone operation. With this update, the default clone operation is changed to fullClone for all situations. linkedClone must now be specified by the user. (BZ#2001008)

Previously, the custom resource definition (CRD) schema requirements did not allow numeric values. Consequently, marshaling errors occurred during upgrades. This update corrects the schema requirements to allow both string and numeric values. As a result, marshaling errors are no longer reported by the API server conversion. (BZ#1999425)

Previously, if the Machine API Operator was moved, or the pods were deployed as a result of a name change, the MachineNotYetDeleted metric would reset for each monitored machine. This update changes the metric query to ignore the source pod label. As a result, the MachineNotYetDeleted metric now properly alerts in scenarios where the Machine API Operator pod has been renamed. (BZ#1986237)

Previously, egress IPs on vSphere were picked up by the vSphere cloud provider within the kubelet. These were unexpected by the certificate signing requests (CSR) approver. Consequently, nodes with egress IPs would not have their CSR renewals approved. This update allows the CSR approver to account for egress IPs. As a result, nodes with egress IPs on vSphere SDN clusters now continue to function and have valid CSR renewals. (BZ#1860774)

Previously, worker nodes failed to start, and the installation program failed to generate URL images due to the broken path defaulting for the disk image and incompatible changes in the Google Cloud Platform (GCP) SDK. As a result, the machine controller was unable to create machines. This fix repairs the URL images by changing the base path in the GCP SDK. (BZ#2009111)

Previously, the machine would freeze during the deletion process due to a lag in the vCenter’s powerOff task. VMware showed the machine to be powered off, but OpenShift Container Platform reported it to be powered on, which resulted in the machine freezing during the deletion process. This update improves the powerOff task handling on vSphere to be checked before the task to delete from the database is created, which prevents the machine from freezing during the deletion process. (BZ#2011668)

After installing or updating OpenShift Container Platform, the value of the metrics showed one pending CSR after the last CSR was reconciled. This resulted in the metrics reporting one pending CSR when there should be no pending CSRs. This fix ensures the pending CSR count is always valid post-approval by updating the metrics at the end of each reconcile loop. (BZ#2013528)

Previously, AWS checked for credentials when the cloud-provider flag was set to empty string. The credentials were checked by making calls to the metadata service, even on non-AWS platforms. This caused latency in the ECR provider startup and AWS credential errors logged in all platforms, including non-AWS. This fix prevents the credentials check from making any requests to the metadata service to ensure that credential errors are no longer being logged. (BZ#2015515)

Previously, the Machine API sometimes reconciled a machine before AWS had communicated VM creation across its API. As a result, AWS reported the VM does not exist and the Machine API considered it failed. With this release, the Machine API waits until the AWS API has synched before trying to mark the machine as provisioned. (BZ#2025767)

Previously, a large volume of nodes created simultaneously on UPI clusters could lead to a large number of CSRs being generated. As a result, certificate renewals were not automated because the approver stops approving certificates when there are over 100 pending certificate requests. With this release, existing nodes are accounted for when calculating the approval cut-off and UPI clusters can now benefit from automated certificate renewal even with large scale refresh requests. (BZ#2028019)

Previously, the generated list of instance types embedded in Machine API controllers was out of date. Some of these instance types were unknown and could not be annotated for scale-from-zero requirements. With this release, the generated list is updated to include support for newer instance types. (BZ#2040376)

Previously, AWS Machine API controllers did not set the IOPS value for block devices other than the IO1 type, causing IOPS fields for GP3 block devices to be ignored. With this release, the IOPS is set on all supported block device types and users can set IOPS for block devices that are attached to the machine. (BZ#2040504)

Previously, when using the Cloud Credential Operator in manual mode on an Azure cluster, the Upgradeable status was not set to False. This behavior was different for other platforms. With this release, Azure clusters using the Cloud Credential Operator in manual mode have the Upgradeable status set to False. (BZ#1976674)

Previously, the now unnecessary controller-manager-service service resource that was created by the Cloud Credential Operator was still present. With this release, the Cluster Version Operator cleans it up. (BZ#1977319)

Previously, changes to the log level setting for the Cloud Credential Operator in the CredentialsRequest custom resource were ignored. With this release, logging verbosity can be controlled by editing the CredentialsRequest custom resource. (BZ#1991770)

Previously, the Cloud Credential Operator (CCO) pod restarted with a continuous error when AWS was the default secret annotator for Red Hat OpenStack Platform (RHOSP). This update fixes the default setting for the CCO pod and prevents the CCO pod from failing. (BZ#1996624)

Previously, a pod might fail to start due to an invalid mount request that was not a part of the manifest. With this update, the Cluster Version Operator (CVO) removes any volumes and volume mounts from in-cluster resources that are not included in the manifest. This allows pods to start successfully. (BZ#2002834)

Previously, when monitoring certificates were rotated, the Cluster Version Operator (CVO) would log errors and monitoring would be unable to query metrics until the CVO pod was manually restarted. With this update, the CVO monitors the certificate files and automatically recreates the metrics connection whenever the certificate files change. (BZ#2027342)

Previously, a loading prompt was not present while the persistent volumes (PVs) were being provisioned and the capacity was 0 TiB which created a confusing scenario. With this update, a loader is added for the loading state which provides details to the user if the PVs are still being provisioned or capacity is to be determined. It will also inform the user of any errors in the process. (BZ#1928285)

Previously, the grammar was not correct in certain places and there were instances where translators were unable to interpret the context. This had a negative impact on readability. With this update, the grammar in various places is corrected, the storage classes for translators is itemized, and the overall readability is improved. (BZ#1961391)

Previously, when pressing a pool inside the block pools page, the final Ready phase persisted after deletion. Consequently, the pool was in the Ready state even after deletion. This update redirects users to the Pools page and refreshes the pools after detention. (BZ#1981396)

Previously, the DNS Operator did not cache responses from upstream resolvers that were configured using spec.servers. With this update, the DNS Operator now caches responses from all upstream servers. (BZ#2006803)

Previously, the DNS Operator did not enable the prometheus pug-in in the server blocks for custom upstream resolvers. Consequently, CoreDNS did not report metrics for upstream resolvers and only reported metrics for the default server block. With this update, the DNS Operator was changed to enable the prometheus plugin in all server blocks. CoreDNS now reports Prometheus metrics for custom upstream resolvers. (BZ#2020489)

Previously, an upstream DNS that provided a response greater than 512 characters caused an application to fail. This occurred because it could not clone the repository from GitHub because to DNS could not be resolved. With this update, the bufsize for KNI CoreDNS is set to 521 to avoid name resolutions from GitHub. (BZ#1991067)

When the DNS Operator reconciles its operands, the Operator gets the cluster DNS service object from the API to determine whether the Operator needs to create or update the service. If the service already exists, the Operator compares it with what the Operator expects to get to determine whether an update is needed. Kubernetes 1.22, on which OpenShift Container Platform 4.9 is based, introduced a new spec.internalTrafficPolicy API field for services. The Operator leaves this field empty when it creates the service, but the API sets a default value for this field. The Operator was observing this default value and trying to update the field back to the empty value. This caused the Operator’s update logic to continuously try to revert the default value that the API set for the service’s internal traffic policy. With this fix, when comparing services to determine whether an update is required, the Operator now treats the empty value and default value for spec.internalTrafficPolicy as equal. As a result, the Operator no longer spuriously tries to update the cluster DNS service when the API sets a default value for the service’s spec.internalTrafficPolicy field. (BZ#2002461)

Previously, the DNS Operator did not enable the cache plugin for server blocks in the CoreDNS Corefile configuration map corresponding to entries in the spec.servers field of the dnses.operator.openshift.io/default object. As a result, CoreDNS did not cache responses from upstream resolvers that were configured using spec.servers. With this bug fix, the DNS Operator is changed to enable the cache plugin for all server blocks, using the same parameters that the Operator already configured for the default server block. CoreDNS now caches responses from all upstream resolvers. (BZ#2006803)

Previously, the registry internally resolved \docker.io references into \registry-1.docker.io and used it to store credentials. As a result, credentials for \docker.io images could not be located. With this update, the \registry-1.docker.io hostname has been changed back to \docker.io when searching for credentials. As a result, the registry can correctly find credentials for \docker.io images. (BZ#2024859)

Previously, the image pruner job did not retry upon failure. As a result, a single failure could degrade the Image Registry Operator until the next time it ran. With this fix, the temporary problems with the pruner do not degrade the Image Registry Operator. (BZ#2051692)

Previously, the Image Registry Operator was modifying objects from the informer. As a result, these objects could be concurrently modified by the informer and cause race conditions. With this fix, controllers and informers have different copies of the object and do not have race conditions. (BZ#2028030)

Previously, TestAWSFinalizerDeleteS3Bucket would fail because of an issue with the location of the configuration object in the Image Registry Operator. This update ensures that the configuration object is stored in the correct location. As a result, the Image Registry Operator no longer panics when running TestAWSFinalizerDeleteS3Bucket. (BZ#2048443)

Previously, error handling caused the access denied error to be output as authentication required. This bug resulted in incorrect error logs. Through Docker distribution error handling, the error output was changed from authentication required to access denied. Now the access denied error provides more precise error logs. (BZ#1902456)

Previously, the registry was immediately exiting on a shut down request. As a result, the router did not have time to discover that the registry pod was gone and could send requests to it. With this fix, when the pod is deleted it stays active for a few extra seconds to give other components time to discover its deletion. Now, the router does not send requests to non-existent pods during upgrades, which no longer leads to disruptions. (BZ#1972827)

Previously, the registry proxied response from the first available mirrored registry. When a mirror registry was available but did not have the requested data, pull-through did not try to use other mirrors even if they contained the required data. With this fix, pull-through tries other mirror registries if the first mirror replied with Not Found. Now, pull-through can discover data if it exists on any mirror registry. (BZ#2008539)

Previously, the image policy admission plugin did not recognize deployment configurations, notably that stateful sets could be updated. As a result, image stream references stayed unresolved in deployment configurations when the resolve-names annotation was used. Now, the plugin is updated so that it resolves annotations in deployment configurations and stateful sets. As a result, image stream tags get resolved in created and edited deployment configurations. (BZ#2000216)

Previously, when global pull secrets were updated, existing API server pod pull secrets were not updated. Now, the mount point for the pull secret is changed from the /var/lib/kubelet/config.json file to the /var/lib/kubelet directory. As a result, the updated pull secret now appears in existing API server pods. (BZ#1984592)

Previously, the image admission plugin did not check annotations inside deployment configuration templates. As a result, annotations inside deployment configuration templates could not be handled in replica controllers, and they were ignored. Now, the image admission plugin analyzes the template of deployment configurations. With this fix, the image admission plugin recognizes the annotations on the deployment configurations and on their templates. (BZ#2032589)

The OpenShift Container Platform Baremetal IPI installer previously used the first nodes defined under hosts in install-config as control plane nodes rather than filtering for the hosts with the master role. The role of master and worker nodes is now recognized when defined. (BZ#2003113)

Before this update, it was possible to set host bits in the provisioning network CIDR. This could cause the provisioning IP to differ from what was expected leading to conflict with other IP addresses on the provisioning network. With this update, validation ensures that the provisioning network CIDR cannot contain host bits. If a provisioning Network CIDR includes host bits, the installation program stops and logs an error message. (BZ#2006291)

Previously, pre-flight checks did not account for Red Hat OpenStack Platform (RHOSP) resource utilization. As a result, those checks failed with an incorrect error message when utilization, rather than quota, impeded installation. Pre-flight checks now process both RHOSP quota and utilization. The checks fail with correct error messages if the quota is sufficient but resources are not. (BZ#2001317)

Before this update, the oVirt Driver could specify ReadOnlyMany (ROX) and ReadWriteMany (RWX) access modes when creating a PVC from a configuration file. This caused an error because the driver does not support shared disks and, as a result, could not support these access modes. With this update, the access mode has been limited to single node access. The system prevents any attempt to specify ROX or RWX when creating PVC and logs an error message. (BZ#1882983)

Previously, disk uploads in the Terraform provider were not handled properly. As a result, the OpenShift Container Platform installation program failed. With this update, disk upload handling has been fixed, and disk uploads succeed. (BZ#1917893)

Previously, when installing a Microsoft Azure cluster with a special size, the installation program would check if the total number of virtual CPUs (vCPU) met the minimum resource requirement to deploy the cluster. Consequently, this could cause an install error. This update changes the check the installation program makes from the total number of vCPUs to the number of vCPUs available. As a result, a concise error message is given that lets the Operator know that the virtual machine size does not meet the minimum resource requirements. (BZ#2025788)

Previously, RAM validation for Red Hat OpenStack Platform (RHOSP) checked for values using a wrong unit, and as a result the validation accepted flavors that did not meet minimum RAM requirements. With this fix, RAM validation now rejects flavors with insufficient RAM. (BZ#2009699)

Previously, OpenShift Container Platform control plane nodes were missing Ingress security group rules when they were schedulable and deployed on Red Hat OpenStack Platform (RHOSP). As a result, OpenShift Container Platform deployments on RHOSP failed for compact clusters with no dedicated workers. This fix adds Ingress security group rules on Red Hat OpenStack Platform (RHOSP) when control plane nodes are schedulable. Now, you can deploy compact three-node clusters on RHOSP. (BZ#1955544)

Previously, if you specified an invalid AWS region, the installation program continued to try and validate availability zones. This caused the installation program to become unresponsive for 60 minutes before timing out. The installation program now verifies the AWS region and service endpoints before availability zones, which reduces the amount of time the installation program takes to report the error. (BZ#2019977)

Previously, you could not install a cluster to VMware vSphere if the vCenter hostname began with a number. The installation program has been updated and no longer treats this type of hostname as invalid. Now, a cluster deploys successfully when the vCenter hostname begins with a number. (BZ#2021607)

Previously, if you specified a custom disk instance type when deploying a cluster on Microsoft Azure, the cluster might not deploy. This occurred because the installation program incorrectly determined that the minimum resource requirements had been met. The installation program has been updated, and now reports an error when the number of vcpus available for the instance type in the selected region does not meet the minimum resource requirements. (BZ#2025788)

Previously, if you defined custom IAM roles when deploying an AWS cluster, you might have to manually remove bootstrap instance profiles after uninstalling the cluster. Intermittently, the installation program did not remove bootstrap instance profiles. The installation program has been updated, and all machine instance profiles are removed when the cluster is uninstalled. (BZ#2028695)

Previously, the default provisioningIP value was different when the host bits were set in the provisioning network CIDR. This resulted in a different value for the provisioningIP than expected. This difference caused a conflict with the other IP addresses on the provisioning network. This fix adds a validation to ensure that the ProvisioningNetworkCIDR does not have host bits set. As a result, if the ProvisioningNetworkCIDR has the host bits set, the installation program will stop and report the validation error. (BZ#2006291)

Previously, the BMC driver IPMI was not supported for a secure UEFI boot. This resulted in an unsuccessful boot. This fix adds a validation check to ensure that UEFISecureBoot mode is not used with bare-metal drivers. As a result, a secure UEFI boot is successful. (BZ#2011893)

With this update, the 4.8 UPI template is updated from version 3.1.0 to 3.2.0 to match the Ignition version. (BZ#1949672)

Previously, when asked to mirror the contents of the base registry, the OpenShift Container Platform installation program would exit with a validation error, citing incorrect install-config file values for imageContentSources. With this update, the installation program now allows imageContentSources values to specify base registry names and the installation program no longer exits when specifying a base registry name. (BZ#1960378)

Previously, the UPI ARM templates were attaching an SSH key to the virtual machine (VM) instances created. As a result, the creation of the VMs fails when the SSH key provided by the user is the ed25519 type. With this update, the creation of the VMs succeeds regardless of the type of the SSH key provided by the user. (BZ#1968364)

After successfully creating a aws_vpc_dhcp_options_association resource, AWS might still report that the resource does not exist. Consequently, the AWS Terraform provider fails the installation. With this update, you can retry the query of the aws_vpc_dhcp_options_association resource for a period of time after creation until AWS reports that the resource exists. As a result, installations succeed despite AWS reporting that the aws_vpc_dhcp_options_association resource does not exist. (BZ#2032521)

Previously, when installing OpenShift Container Platform on AWS with local zones enabled, the installation program could create some resources on a local zone rather than an availability zone. This caused the installation program to fail because load balancers cannot run on local zones. With this fix, the installation program ignores local zones and only considers availability zones when installing cluster components. (BZ#1997059)

Previously, terraform could attempt to upload the bootstrap ignition configuration file to Azure before it had finished creating the configuration file. If the upload started before the local file was created, the installation would fail. With this fix, terraform uploads the ignition configuration file directly to Azure rather than creating a local copy first. (BZ#2004313)

Previously, a race condition could occur if the cluster-bootstrap and Cluster Version Operator components attempted to write a manifest for the same resource to the Kubernetes API at the same time. This could result in the Authentication resource being overwritten by a default copy, which removed any customizations made to that resource. With this fix, the Cluster Version Operator has been blocked from overwriting the manifests that come from the installation program. This prevents any user-specified customizations to the Authentication resource from being overwritten. (BZ#2008119)

Previously, when installing OpenShift Container Platform on AWS, the installation program created the bootstrap machine using the m5.large instance type. This caused the installation to fail in regions where that instance type is not available. With this fix, the bootstrap machine uses the same instance type as the control plane machines. (BZ#2016955)

Previously, when installing OpenShift Container Platform on AWS, the installation program did not recognize EC2 G and Intel Virtualization Technology (VT) instances and defaulted them to X instances. This caused incorrect instance quotas to be applied to these instances. With this fix, the installation program recognizes EC2 G and VT instances and applies the correct instance quotas. (BZ#2017874)

Before this update, upgrading to the current release did not set the correct weights for the TaintandToleration, NodeAffinity, and InterPodAffinity parameters. This update resolves the issue so that upgrading correctly sets the weights for TaintandToleration to 3, NodeAffinity to 2, and InterPodAffinity to 2. (BZ#2039414)

In OpenShift Container Platform 4.10, code for serving insecure metrics is removed from the kube-scheduler code base. Now, metrics are served only through a secure server. Bug fixes and support are provided through the end of a future life cycle. After which, no new feature enhancements are made. (BZ#1889488)

Previously, the Machine Config Operator (MCO) stored pending configuration changes to the disk before operating system (OS) changes were applied. As a result, in situations such as power loss, the MCO assumed OS changes had already been applied on restart, and validation skipped over changes such as kargs and kernel-rt. With this update, configuration changes to disk are stored after OS changes are applied. Now, if power is lost during the configuration application, the MCO knows it must reattempt the configuration application on restart. (BZ#1916169)

Previously, an old version of the Kubernetes client library in the baremetal-runtimecfg project prevented the timely closing of client connections following a VIP failover. This could result in long delays for monitor containers that rely on the API. This update allows the timely closing of client connections following a VIP failover. (BZ#1995021)

Previously, when updating SSH keys, the Machine Config Operator (MCO) changed the owner and group of the authorized_keys file to root. This update ensures that the MCO preserves core as the owner and group when it updates the authorized_keys file. (BZ#1956739)

Previously, a warning message sent by the clone_slave_connection function was incorrectly stored in a new_uuid variable, which is intended to store only the connection’s UUID. As a result, nmcli commands that include the new_uuid variable were failing due to the incorrect value being stored in the new_uuid variable. With this fix, the clone_slave_connection function warning message is redirected to stderr. Now, nmcli commands that reference the new_uuid variable do not fail. (BZ#2022646)

Previously, an old version of the Kubernetes client library was present in the baremetal-runtimecfg project. When a Virtual IP (VIP) failed, the client connections might not be closed in a timely manner. This could result in long delays for monitor containers that rely on talking to the API. This fix updates the client library. Now, connections are closed as expected on VIP failovers and the monitor containers do not hang for an excessive period of time. (BZ#1995021)

Before this update, the Machine Config Operator (MCO) stored pending configuration changes to disk before it applied them to Red Hat Enterprise Linux CoreOS (RHCOS). If a power loss interrupted the MCO from applying the configuration, it treated the configuration as applied and did not validate the changes. If this configuration contained invalid changes, applying them failed. With this update, the MCO saves a configuration to disk only after being applied. This way, if the power is lost while the MCO is applying the configuration, it reapplies the configuration after it restarts. (BZ#1916169)

Before this update, when you used the Machine Config Operator (MCO) to create or update an SSH key, it set the owner and group of the authorized_keys file to root. This update resolves the issue. When the MCO creates or updates the authorized_keys file, it correctly sets or preserves core as the owner and group of the file. (BZ#1956739)

Previously, in clusters that use Stateless Address AutoConfiguration (SLAAC), the Ironic addr-gen-mode parameter was not being persisted to the OVNKubernetes bridge. As a result, the IPv6 addresses could change when the bridge was created. This broke the cluster because node IP changes are unsupported. This fix persists the addr-gen-mode parameter when creating the bridge. The IP address is now consistent throughout the deployment process. (BZ#1990625)

Previously, if a machine config included a compressed file with the spec.config.storage.files.contents.compression parameter set to gzip, the Machine Config Daemon (MCD) incorrectly wrote the compressed file to disk without extracting it. With this fix, the MCD now extracts a compressed file when the compression parameter is set to gzip. (BZ#1970218)

Previously, systemd units were cleaned up only when completely removed. As a result, systemd units could not be unmasked by using a machine config because the masks were not being removed unless the systemd unit was completely removed. With this fix, when you configure a systemd unit as mask: true in a machine config, any existing masks are removed. As a result, systemd units can now be unmasked. (BZ#1966445)

Previously, the OperatorHub category and card links did not include valid href attributes. Consequently, the OperatorHub category and card links could not be opened in a new tab. This update adds valid href attributes to the OperatorHub category and card links. As a result, the OperatorHub and its card links can be opened in new tabs. (BZ#2013127)

Previously, on the Operand Details page, a special case was created where the conditions table for the status.conditions property always rendered before all other tables. Consequently, the status.conditions table did not follow the ordering rules of descriptors, which caused unexpected behavior when users tried to change the order of the tables. This update removes the special case for status.conditions and only defaults to rendering it first if no descriptor is defined for that property. As a result, the table for status.condition is rendered according to descriptor ordering rules when a descriptor is defined on that property. (BZ#2014488)

Previously, the Resource Details page metrics tab was exceeding the cluster-scoped Thanos endpoint. Consequently, users without authorization for this endpoint would receive a 401 response for all queries. With this update, the Thanos tenancy endpoints are updated, and redundant namespace query arguments are removed. As a result, users with the correct role-based access control (RBAC) permissions can now see data in the metrics tab of the Resource Details page. (BZ#2015806)

Previously, when an Operator added an API to an existing API group, it did not trigger API discovery. Consequently, new APIs were not seen by the front end until the page was refreshed. This update makes APIs added by Operators viewable by the front end without a page refresh. (BZ#1815189)

Previously, in the Red Hat OpenShift Cluster Manager for Red Hat OpenStack Platform (RHOSP), the control plane was not translated into simplified Chinese. As a result, naming differed from OpenShift Container Platform documentation. This update fixes the translation issue in the Red Hat OpenShift Cluster Manager. (BZ#1982063)

Previously, filtering of virtual tables in the Red Hat OpenShift Cluster Manager was broken. Consequently, all of the available nodes would not appear following a search. This update includes new virtual table logic that fixes the filtering issue in the Red Hat OpenShift Cluster Manager. (BZ#1990255)

Previously, during OpenShift Container Platform upgrades, the Prometheus service could become unavailable because either two Prometheus pods were located on the same node or the two nodes running the pods rebooted during the same interval. This situation was possible because the Prometheus pods had soft anti-affinity rules regarding node placement and no PodDisruptionBudget resources provisioned. Consequently, metrics were not collected and rules were not evaluated over a period of time.

Previously, the Thanos Ruler service would become unavailable when the node that contains the two Thanos Ruler pods experienced an outage. This situation occurred because the Thanos Ruler pods had only soft anti-affinity rules regarding node placement. Consequently, user-defined rules would not be evaluated until the node came back online.

Previously, the Prometheus service would become unavailable when the two Prometheus pods were located on the same node and that node experienced an outage. This situation occurred because the Prometheus pods had only soft anti-affinity rules regarding node placement. Consequently, metrics would not be collected, and rules would not be evaluated until the node came back online.

Previously, during OpenShift Container Platform patch upgrades, the Alertmanager service might become unavailable because either the three Alertmanager pods were located on the same node or the nodes running the Alertmanager pods happened to reboot at the same time. This situation was possible because the Alertmanager pods had soft anti-affinity rules regarding node placement and no PodDisruptionBudget provisioned. This release enables hard anti-affinity rules and PodDisruptionBudget resources to ensure no downtime during patch upgrades for the Alertmanager and other monitoring components. (BZ#1955489)

Previously, a false positive NodeFilesystemSpaceFillingUp alert was triggered when the file system space was occupied by many Docker images. For this release, the threshold to fire the NodeFilesystemSpaceFillingUp warning alert is now reduced to 20% space available, rather than 40%, which stops the false positive alert from firing. (BZ#1987263)

Previously, alerts for the Prometheus Operator component did not apply to the Prometheus Operator that runs the openshift-user-workload-monitoring namespace when user-defined monitoring is enabled. Consequently, no alerts fired when the Prometheus Operator that manages the openshift-user-workload-monitoring namespace encountered issues.

Previously, if the number of DaemonSet pods for the node-exporter agent was not equal to the number of nodes in the cluster, the Cluster Monitoring Operator (CMO) would report a condition of degraded. This issue would occur when one of the nodes was not in the ready condition.

This release fixes an issue in which some pods in the monitoring stack would start before TLS certificate-related resources were present, which resulted in failures and restarts. (BZ#2016352)

Previously, if reporting metrics failed due to reaching the configured sample limit, the metrics target would still appear with a status of Up in the web console UI even though the metrics were missing. With this release, Prometheus bypasses the sample limit setting for reporting metrics, and the metrics now appear regardless of the sample limit setting. (BZ#2034192)

When using the OVN-Kubernetes network provider in OpenShift Container Platform versions prior to 4.8, the node routing table was used for routing decisions. In newer versions of OpenShift Container Platform, the host routing table is bypassed. In this release, you can now specify whether you want to use or bypass the host kernel networking stack for traffic routing decisions. (BZ#1996108)

Previously, when Kuryr was used in a restricted installation with proxy, the Cluster Network Operator was not enforcing usage of the proxy to allow communication with the Red Hat OpenStack Platform (RHOSP) API. Consequently, cluster installation did not progress. With this update, the Cluster Network Operator can communicate with the RHOSP API through the proxy. As a result, installation now succeeds. (BZ#1985486)

Before this update, the SRIOV webhook blocked the creation of network policies on OpenShift Container Platform on Red Hat OpenStack Platform (RHOSP) environments. With this update, the SRIOV webhook reads and validates the RHOSP metadata and can now be used to create network policies. (BZ#2016334)

Previously, the MachineConfig object could not be updated because the SRIOV Operator did not pause the MachineConfig pool object. With this update, the SRIOV Operator pauses the relevant machine config pool before running any configuration requiring reboot. (BZ#2021151)

Previously, there were timing issues with keepalived that resulted in its termination when it should have been running. This update prevents multiple keepalived commands from being sent in a short period of time. As a result, timing issues are no longer a problem and keepalive continuously runs. (BZ#2022050)

Previously, when Kuryr was used in a restricted installation with proxy, the Cluster Networking Operator was not enforcing usage of the proxy to allow communication with the Red Hat OpenStack Platform (RHOSP) API. Consequently, cluster installation did not progress. With this update, the Cluster Network Operator can communicate with the RHOSP API through the proxy. As a result, installation now succeeds. (BZ#1985486)

Previously, pods that used secondary interfaces with IP addresses provided by the Whereabouts Container Network Interface (CNI) plugin might get stuck in the ContainerCreating state because of IP address exhaustion. Now, Whereabouts properly accounts for released IP addresses from cluster events, such as reboots, that previously were not tracked. (BZ#1914053)

Previously, when using the OpenShift SDN cluster network provider, idled services used an increasing amount of CPU to un-idle services. In this release, the idling code for kube-proxy is optimized to reduce CPU utilizing for service idling. (BZ#1966521)

Previously, when using the OVN-Kubernetes cluster network provider, the presence of any unknown field in an internal configuration map could cause the OVN-Kubernetes pods to fail to start during a cluster upgrade. Now the presence of unknown fields causes a warning, rather than a failure. As a result, the OVN-Kubernetes pods now successfully start during a cluster upgrade. (BZ#1988440)

Previously, a webhook for the SR-IOV Network Operator blocked network policies for OpenShift installations on OpenStack. Users were not able to create SR-IOV network policies. This update fixes the webhook. Users can now create SR-IOV network policies for installations on OpenStack. (BZ#2016334)

Previously, the CRI-O runtime engine passed pod UIDs by using the K8S_POD_UID variable. But when pods were deleted and recreated at the same time that Multus was setting up networking for the deleted pod’s sandbox, this method resulted in additional metadata and unnecessary processing. In this update, Multus handles pod UIDs, and unnecessary metadata processing is avoided. (BZ#2017882)

Previously, in deployments of OpenShift on a single node, default settings for the SR-IOV Network Operator prevented users from making certain modifications to nodes. By default, after configuration changes are applied, affected nodes are drained and then restarted with the new configuration. This behavior does not work when there is only one node. In this update, when you install the SR-IOV Network Operator in a single-node deployment, the Operator changes its configuration so the .spec.disableDrain field is set to true. Users can now apply configuration changes successfully in single-node deployments. (BZ#2021151)

Client-go versions 1.20 and earlier did not have sufficient technique for retrying requests to the Kubernetes API. As a result, retries to the Kubernetes API were not sufficient. This update fixes the problem by introducing client-go 1.22. (BZ#2052062)

Previously, network, IPC, and UTS namespace resources managed by CRI-O were only freed when the Kubelet removed stopped pods. With this update, the Kubelet frees these resources when the pods are stopped. (BZ#2003193)

Previously, when logging into a worker node, messages might appear indicating a systemd-coredump services failure. This was due to the unnecessary inclusion of the system-systemd namespace for containers. A filter now prevents this namespace from impacting the workflow. (BZ#1978528)

Previously, when clusters were restarted, the status of terminated pods might have been reset to Running, which would result in an error. This has been corrected and now all terminated pods remain terminated and active pods reflect their correct status. (BZ#1997478)

Previously, certain stop signals were ignored in OpenShift Container Platform, causing services in the container to continue running. With an update to the signal parsing library, all stop signals are now respected. (BZ#2000877)

Previously, pod namespaces managed by CRI-O, for example network, IPC, and UTS, were not unmounted when the pod was removed. This resulted in leakage, driving the Open vSwitch CPU to 100%, which caused pod latency and other performance impacts. This has been resolved and pod namespaces are unmounted when removed. (BZ#2003193)

Previously, due to the increasing number of custom resource definitions (CRD) installed in the cluster, the requests reaching for API discovery were limited by client code restrictions. Now, both the limit number and QPS have been boosted, and client-side throttling should appear less frequently. (BZ#2042059)

Previously, some minor requests did not have the user agent string set correctly, so the default Go user agent string was used instead for oc. The user agent string is now set correctly for all mirror requests, and the expected oc user agent string is now sent to registries. (BZ#1987257)

Previously, oc debug assumed that it was always targeting Linux-based containers by trying to run a Bash shell, and if Bash was not present in the container, it attempted to debug as a Windows container. The oc debug command now uses pod selectors to determine the operating system of the containers and now works properly on both Linux and Windows-based containers. (BZ#1990014)

Previously, the --dry-run flag was not working properly for several oc set subcommands, so --dry-run=server was performing updates to resources rather than performing a dry run. The --dry-run flags are now working properly to perform dry runs on the oc set subcommands. (BZ#2035393)

Previously, a container using SELinux could not read /var/log/containers log files due to a missing policy. This update makes all log files in /var/log accessible including those accessed through symlink. (BZ#2005997)

Previously, the openshift_apps_deploymentconfigs_last_failed_rollout_time metric improperly set the namespace label as the value of the exported_namespace label. The openshift_apps_deploymentconfigs_last_failed_rollout_time metric now has the correct namespace label set. (BZ#2012770)

Before this update, default catalog sources for the marketplace-operator did not tolerate tainted nodes and the CatalogSource pod would only have the default settings for tolerations, nodeSelector, and priorityClassName. With this update, the CatalogSource specification now includes the optional spec.grpcPodConfig field that can override tolerations, nodeSelector, and priorityClassName for the pod. (BZ#1927478)

Before this update, the csv_suceeded metric would be lost when the OLM Operator was restarted. With this update, the csv_succeeded metric is emitted at the beginning of the OLM Operator’s startup logic. (BZ#1927478)

Before this update, the oc adm catalog mirror command did not set minimum and maximum values for the --max-icsp-size flag. As a result, the field accepted values that were less than zero or were too large. With this update, values are limited to sizes greater than zero and less than 250001. Values outside of this range fail validation. (BZ#1972962)

Before this update, bundled images did not contain the related images needed for Operator deployment in file-based catalogs. As a result, images were not mirrored to disconnected clusters unless specified in the relatedImages field of the ClusterServiceVersion (CSV). With this update, the opm render command adds the CSV Operator images to the relatedImages file when the file-based catalog bundle image is rendered. The images necessary for Operator deployment are now mirrored to disconnected clusters even if they are not listed in the relatedImages field of the CSV. (BZ#2002075)

Before this update, it could take up to 15 minutes for Operators to perform skipRange updates. This was a known issue that could be resolved if cluster administrators deleted the catalog-operator pod in the openshift-operator-lifecycle-manager namespace. This caused the pod to be automatically recreated and triggered the skipRange upgrade. With this update, obsolete API calls have been fixed in Operator Lifecycle Manager (OLM), and skipRange updates trigger immediately. (BZ#2002276)

Occasionally, update events on clusters would happen at the same time that Operator Lifecycle Manager (OLM) modified an object from the lister cache. This caused concurrent map writes. This fix updates OLM so it no longer modifies objects retrieved from the lister cache. Instead, OLM modifies a copy of the object where applicable. As a result, OLM no longer experiences concurrent map writes. (BZ#2003164)

Previously, Operator Lifecycle Manager (OLM) could not establish gRPC connections to catalog source pods that were only reachable through a proxy. If a catalog source pod was behind a proxy, OLM could not connect to the proxy and the hosted Operator content was unavailable for installation. This bug fix introduces a GRPC_PROXY environment variable that defines a proxy that OLM uses to establish connections to gRPC catalog sources. As a result, OLM can now be configured to use a proxy when connecting to gRPC catalog sources. (BZ#2011927)

Previously, skipped bundles were not verified to be members of the same package. Bundles could skip across packages, which broke upgrade chains. This bug fix adds validation to ensure skipped bundles are in the same package. As a result, no bundle can skip bundles in another package, and upgrade graphs no longer break across packages. (BZ#2017327)

In the CatalogSource object, the RegistryServiceStatus field stores service information that is used to generate an address that Operator Lifecycle Manager (OLM) relies on to establish a connection with the associated pod. If the RegistryServiceStatus field is not nil and is missing the namespace, name, and port information for its service, OLM is unable to recover until the associated pod has an invalid image or spec. With this bug fix, when reconciling a catalog source, OLM now ensures that the RegistryServiceStatus field of the CatalogSource object is valid and updates its status to reflect the change. Additionally, this address is stored within the status of the catalog source in the status.GRPCConnectionState.Address field. If the address changes, OLM updates this field to reflect the new address. As a result, the .status.connectionState.address field of a catalog source should no longer be nil. (BZ#2026343)

Previously, when the RHCOS live ISO added a UEFI boot entry for itself, it assumed the existing UEFI boot entry IDs were consecutive, thereby causing the live ISO to fail in the UEFI firmware when booting on systems with non-consecutive boot entry IDS. With this fix, the RHCOS live ISO no longer adds a UEFI boot entry for itself and the ISO boots successfully. (BZ#2006690)

To help you determine whether a user-provided image was already booted, information has been added on the terminal console describing when the machine was provisioned through Ignition and whether a user Ignition configuration was provided. This allows you to verify that Ignition ran when you expected it to. (BZ#2016004)

Previously, when reusing an existing statically keyed LUKS volume during provisioning, the encryption key was not correctly written to disk and Ignition would fail with a "missing persisted keyfile" error. With this fix, Ignition now correctly writes keys for reused LUKS volumes so that existing statically keyed LUKS volumes can be reused during provisioning. (BZ#2043296)

Previously, ostree-finalize-staged.service failed while upgrading a Red Hat Enterprise Linux CoreOS (RHCOS) node to 4.6.17. To fix this, the sysroot code now ignores any irregular or non-symlink files in /etc. (BZ#1945274)

Previously, initramfs files were missing udev rules for by-id symlinks of attached SCSI devices. Because of this, Ignition configuration files that referenced these symlinks would result in a failed boot of the installed system. With this update, the 63-scsi-sg3_symlink.rules for SCSI rules are added in dracut. (BZ#1990506)

Previously, on bare-metal machines, a race condition occurred between system-rfkill.service and ostree-remount.service. Consequently, the ostree-remount service failed and the node operating system froze during the boot process. With this update, the /sysroot/ directory is now read-only. As a result, the issue no longer occurs. (BZ#1992618)

Previously, Red Hat Enterprise Linux CoreOS (RHCOS) live ISO boots added a UEFI boot entry, prompting a reboot on systems with a TPM. With this update, the RHCOS live ISO no longer adds a UEFI boot entry so the ISO does not initiate a reboot after first boot. (BZ#2004449)

The spec.cpu.reserved` flag might not be correctly set by default if spec.cpu.isolated is the only parameter defined in PerformanceProfile. You must set the settings for both spec.cpu.reserved and spec.cpu.isolated in the PerformanceProfile. The sets must not overlap and the sum of all CPUs mentioned must cover all CPUs expected by the workers in the target pool. (BZ#1986681)

Previously, the oc adm must-gather tool failed to collect node data if the gather-sysinfo binary was missing in the image. This was caused by a missing COPY statement in the Dockerfile. To avoid this issue, you must add the necessary COPY statements to the Dockerfile to generate and copy the binaries. (BZ#2021036)

Previously, the Performance Addon Operator downloaded its image from the registry without checking whether it was available on the CRI-O cache. Consequently, the Performance Addon Operator failed to start if it could not reach the registry, or if the download timed out. With this update, the Operator only downloads its image from the registry if it cannot pull the image from the CRI-O cache. (BZ#2021202)

When upgrading OpenShift Container Platform to version 4.10, any comment (#comment) in the tuned profile that does not start at the beginning of the line causes a parsing error. Performance Addon Operator issues can be solved by upgrading it to the same level (4.10) as OpenShift Container Platform. Comment-related errors can be worked around by putting all comments on a single line, with the # character at the start of the line. (BZ#2059934)

Previously, if the cluster administrator provided a default ingress certificate that was missing the newline character for the last line, the OpenShift Container Platform router would write out a corrupt PEM file for HAProxy. Now, it writes out a valid PEM file even if the input is missing a newline character. (BZ#1894431)

Previously, a route created where the combined name and namespace for the DNS segment was greater than 63 characters long would be rejected. This expected behavior could cause problems integrating with upgraded versions of OpenShift Container Platform. Now, an annotation allows non-conformant DNS hostnames. With AllowNonDNSCompliantHostAnnotation set to true, the non-conformant DNS hostname, or one longer than 63 characters, is allowed. (BZ#1964112)

Previously, the Cluster Ingress Operator would not create wildcard DNS records for Ingress Controllers when the cluster’s ControlPlaneTopology was set to External. In Hypershift clusters where the ControlPlaneTopology was set to External and the Platform was AWS, the Cluster Ingress Operator never became available. This updates limits the disabling of DNS updates when the ControlPlaneTopology is External and the platform is IBM Cloud. As a result, wildcard DNS entries are created for Hypershift clusters running on AWS. (BZ#2011972)

Previously, the cluster ingress router was blocked from working because the Ingress Operator failed to configure a wildcard DNS record for the cluster ingress router on Azure Stack Hub IPI. With this fix, the Ingress Operator now uses the configured ARM endpoint to configure DNS on Azure Stack Hub IPI. As a result, the cluster ingress router now works properly. (BZ#2032566)

Previously, the cluster-wide prox configuration could not accept IPv6 addresses for the noProxy setting. Consequently, it was impossible to install a cluster whose configuration was having noProxy with IPv6 addresses. With this update, the Cluster Network Operator is now able to parse IPv6 addresses for the noProxy setting of the cluster-wide proxy resource. As a result, it is now possible to exclude IPv6 addresses for the noProxy setting. (BZ#1939435)

Before OpenShift Container Platform 4.8, the IngressController API did not have any subfields under the status.endpointPublishingStrategy.hostNetwork and status.endpointPublishingStrategy.nodePort fields. These fields could be null even if the spec.endpointPublishingStrategy.type was set to HostNetwork or NodePortService. In OpenShift Container Platform 4.8, the status.endpointPublishingStrategy.hostNetwork.protocol and status.endpointPublishingStrategy.nodePort.protocol subfields were added, and the Ingress Operator set default values for these subfields when the Operator admitted or re-admitted an IngressController that specified the "HostNetwork" or "NodePortService" strategy type. With this bug, however, the Operator ignored updates to these spec fields, and updating spec.endpointPublishingStrategy.hostNetwork.protocol or spec.endpointPublishingStrategy.nodePort.protocol to PROXY to enable proxy protocol on an existing IngressController had no effect. To work around this issue, it was necessary to delete and recreate the IngressController to enable PROXY protocol. With this update, the Ingress Operator is changed so that it correctly updates the status fields when status.endpointPublishingStrategy.hostNetwork and status.endpointPublishingStrategy.nodePort are null and when the IngressController spec fields specify proxy protocol with the HostNetwork or NodePortService endpoint publishing strategy type. As a result, setting spec.endpointPublishingStrategy.hostNetwork.protocol or spec.endpointPublishingStrategy.nodePort.protocol to PROXY now takes proper effect on upgraded clusters. (BZ#1997226)

Before this update, if the Cluster Samples Operator encountered an APIServerConflictError error, it reported sample-operator as having Degraded status until it recovered. Momentary errors of this type were not unusual during upgrades but caused undue concern for administrators monitoring the Operator status. With this update, if the Operator encounters a momentary error, it no longer indicates openshift-samples as having Degraded status and tries again to connect to the API server. Momentary shifts to Degraded status no longer occur. (BZ#1993840)

Before this update, various allowed and blocked registry configuration options in the cluster image configuration might prevent the Cluster Samples Operator from creating image streams. As a result, the samples operator might mark itself as degraded, which impacted the general OpenShift Container Platform install and upgrade status.

Previously, the Local Storage Operator (LSO) took a long time to delete orphaned persistent volumes (PVs) due to the accumulation of a 10-second delay. With this update, the LSO does not use the 10-second delay, PVs are deleted promptly, and local disks are made available for new persistent volume claims sooner. (BZ#2001605)

Previously, Manila error handling would degrade the Manila Operator, and the cluster. Errors are now treated as non-fatal so that the Manila Operator is disabled, rather than degrading the cluster. (BZ#2001620)

In slower cloud environments, such as when using Cinder, the cluster might become degraded. Now, OpenShift Container Platform accommodates slower environments so that the cluster does not become degraded. (BZ#2027685)

If a generated policy has a complianceType of mustonlyhave, Operator Lifecycle Manager (OLM) updates to metadata are then reverted as the policy engine restores the ‘expected’ state of the CR. Consequently, OLM and the policy engine continuously overwrite the metadata of the CR under conflict. This results in high CPU usage. With this update, OLM and the policy engine no longer conflict, which reduces CPU usage. (BZ#2009233)

Previously, user-supplied fields in the PolicyGenTemplate overlay were not copied to generated manifests if the field did not exist in the base source CR. As a result, some user content was lost. The policyGen tool is now updated to support all user supplied fields. (BZ#2028881)

Previously, DNS lookup failures might cause the Cluster Baremetal Operator to continually fail when installed on unsupported platforms. With this update, the Operator remains disabled when installed on an unsupported platform. (BZ#2025458)

Before this update, resources in the Developer perspective of the web console had invalid links to details about that resource. This update resolves the issue. It creates valid links so that users can access resource details. (BZ#2000651)

Before this update, you could only specify a subject in the SinkBinding form by label, not by name. With this update, you can use a drop-down list to select whether to specify a subject by name or label. (BZ#2002266)

Before this update, the web terminal icon was available in the web console’s banner head only if you installed the Web Terminal Operator in the openShift-operators namespace. With this update, the terminal icon is available regardless of the namespace where you install the Web Terminal Operator. (2006329)

Before this update, the service binding connector did not appear in topology if you used a resource property rather than a kind property to define a ServiceBinding custom resource (CR). This update resolves the issue by reading the CR’s resource property to display the connector on the topology. (BZ#2013545)

Before this update, the name input fields used a complex and recursive regular expression to validate user inputs. This regular expression made name detection very slow and often caused errors. This update resolves the issue by optimizing the regular expression and avoiding recursive matching. Now, name detection is fast and does not cause errors. (BZ#2014497)

Before this update, feature flag gating was missing from some extensions contributed by the knative plugin. Although this issue did not affect what was displayed, these extensions ran unnecessarily, even if the serverless operator was not installed. This update resolves the issue by adding feature flag gating to the extensions where it was missing. Now, the extensions do not run unnecessarily. (BZ#2016438)

Before this update, if you repeatedly clicked links to get details for resources such as custom resource definitions or pods and the application encountered multiple code reference errors, it failed and displayed a t is not a function error. This update resolves the issue. When an error occurs, the application resolves a code reference and stores the resolution state so that it can correctly handle additional errors. The application no longer fails when code reference errors occur. (BZ#2017130)

Before this update, users with restricted access could not access their config map in a shared namespace to save their user settings on a cluster and load them in another browser or machine. As a result, user preferences such as pinned navigation items were only saved in the local browser storage and not shared between multiple browsers. This update resolves the issue: The web console Operator automatically creates RBAC rules so that each user can save these settings to a config map in a shared namespace and more easily switch between browsers. (BZ#2018234)

Before this update, trying to create connections between virtual machines (VMs) in the Topology view failed with an "Error creating connection" message. This issue happened because this action relied on a method that did not support custom resource definition (CRDs). This update resolves the issue by adding support for CRDs. Now you can create connections between VMs. (BZ#2020904)

Before this update, the tooltip for tasks in the PipelineRun details showed misleading information. It showed the time elapsed since the task ran, not how long they ran. For example, it showed 122 hours for a task that ran for a couple of seconds 5 days ago. With this update, the tooltip shows the duration of the task. (BZ#2011368)

TP: Technology Preview

GA: General Availability

-: Not Available

DEP: Deprecated