OpenShift Container Platform 4.11 release notes

A service account token secret for authenticating to the internal OpenShift Container Platform registry

A service account token secret for accessing the Kubernetes API

Updating Go-based Operator projects

Updating Ansible-based Operator projects

Updating Helm-based Operator projects

Updating Hybrid Helm-based Operator projects

GA: General Availability

DEP: Deprecated

REM: Removed

Previously, when writing the RHCOS image onto some disks, the qemu-img was allocating space onto the entire disk, including sparse areas. This extended the time of the writing process on some hardware. This update disables the qemu-img sparse in image creation. As a result, the image writing would no longer take a long time on affected hardware. (BZ#2002009)

Previously, if the rotational field was set for RootDeviceHints, the host could fail the provision. With this update, the rotational field in RootDeviceHints is properly copied and checked. As a result, the provisioning will succeed when using the rotational field. (BZ#2053721)

Previously, Ironic was unable to use virtual media to provision Nokia OE 20 servers because the BMC required the TransferProtocolType attribute to be explicitly set in the request despite this being an optional attribute. Additionally, the BMC also required the use of a dedicated RedFish settings resource to override boot orders, whereas most BMCs just use the system resource. This error occurred because Nokia OE 20 strictly requires an optional TransferProtocolType attribute for vMedia attachments and requires the use of the RedFish settings resource for overriding boot sequences. Consequently, virtual media based provisioning would fail on Nokia OE 20. There are two workarounds for this issue:

Previously, the Ironic API inspector image failed to clean disks that were part of passive multipath setups when using OpenShift Container Platform bare-metal IPI deployments. This update fixes the failures when active or passive storage arrays are in use. As a result, it is now possible to use OpenShift Container Platform bare metal IPI when customers want to use multipath setups that are active or passive. (BZ#2089309)

Previously, Ironic failed to match wwn serial numbers to multi-path devices. Consequently, wwn serial numbers for device mapper devices could not be used in the rootDeviceHint parameter in the install-config.yaml configuration file. With this update, Ironic now recognizes wwn serial numbers as unique identifiers for multi-path devices. As a result, it is now possible to use wwn serial numbers for device mapper devices for the install-config.yaml file. (BZ#2098392)

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.11 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-2052)

Previously, using a forward slash (/) in the ImageLabel name of a BuildConfig instance resulted in an error. This fix resolves the issue by changing the utility used for validation. As a result, you can use a forward slash in the ImageLabel name of a BuildConfig instance. (BZ#2105167)

Previously, when using the $ oc new-app --search <image_stream_name> command, you could receive an incorrect message related to docker.io images. This resulted in confusion for the user because OpenShift Container Platform does not use image streams that point to docker.io. This fix adds code checks to prevent the reference to docker.io. As a result, the output from that command does not include the message. (BZ#2049889)

Previously, Shared Resource CSI Driver metrics were not exported to the Telemetry service. As a result, usage metrics for the Shared Resource CSI Driver could not be analyzed. With this fix, Shared Resource CSI Driver metrics are exposed to the Telemetry service. As a result, usage metrics for the Shared Resource CSI Driver can be collected and analyzed. (BZ#2058225)

By default, Buildah prints steps to the log file, including the contents of environment variables, which might include build input secrets. Although you can use the --quiet build argument to suppress printing of those environment variables, this argument isn’t available if you use the source-to-image (S2I) build strategy. The current release fixes this issue. To suppress printing of environment variables, set the BUILDAH_QUIET environment variable in your build configuration:

sourceStrategy:
...
  env:
    - name: "BUILDAH_QUIET"
      value: "true"

Before this update, using the $ oc new-app --search <image_stream_name> command provided a warning that you may not have access to the container image "docker.io/library/<image_name>:<tag>". This caused confusion about OpenShift Container Platform having image streams that pointed to docker.io. This update fixes the issue by adding code checks to prevent that confusing reference to 'docker.io'. Now, the output from that command does not include messages about docker.io (BZ#2049889)

CertificateSigningRequest (CSR) resource renewal is handled by the Kubernetes controller manager and correctly left pending by the Cluster Machine Approver Operator, which increases the value of the mapi_current_pending_csr metric to 1. Previously, when the Kubernetes controller manager approved the CSR, the Operator ignored it and left the metric unchanged. As a result, the mapi_current_pending_csr metric was stuck at 1 until the Operator next reconciled. With this release, CSR approvals from other controllers are always reconciled to update metrics and the value of the mapi_current_pending_csr metric is updated after every reconcile. (BZ#2047702)

Previously, only regions contained in a list of known regions within the AWS SDK were validated, and specifying any other region caused an error. This meant that, as new regions were added, they could not be used until the SDK was updated to contain the new region information. With this release, regions are validated with a less strict setting that warns the user when a region is not recognized. As a result, new regions might cause warning messages but can be used immediately. (BZ#2065510)

Previously, the Cluster Machine Approver Operator appended the "Approved" status condition to its condition list. As a result, the Kubernetes API server logged errors containing the message [SHOULD NOT HAPPEN] failed to update managedFields. With this release, the Operator is updated to check its conditions before appending to the list, and only update the condition when necessary. As a result, the conditions are no longer duplicated in the CertificateSigningRequest resource and the Kubernetes API server no longer logs errors about the duplicate. (BZ#1978303)

Previously, a defect in the Cisco ACI neutron implementation that was present in Red Hat OpenStack Platform (RHOSP) version 16, caused the query for subnets belonging to a given network to return unexpected results. As a result, the RHOSP Cluster API provider might try to provision instances with duplicated ports on the same subnet, leading to a failed provisioning. With this release, additional filtering in the RHOSP Cluster API provider ensures there is no more than one port per subnet, and it is now possible to deploy OpenShift Container Platform on RHOSP version 16 with Cisco ACI. (BZ#2033862)

Previously, the Red Hat OpenStack Platform (RHOSP) Machine API provider did not use the proxy environment variable directives, causing installation behind an HTTP or HTTPS proxy to fail. With this release, the provider obeys proxy directives and functions correctly in a restricted environment in which egress traffic is only allowed through a proxy. (BZ#2046133)

Previously, when upgrading from OpenShift Container Platform 4.9 to 4.10, inconsistencies between multiple controllers resulted in incorrect version numbers. As a result, the version number was not consistent. With this release, consistent reading of version numbers has been enacted and the release version is now stable in the cluster operator status. (BZ#2059716)

Previously, leaks of load balancer targets on AWS Machine API providers may occur. This is because IP-based load balancer attachments may remain within the load balancer registration when replacing control plane machines. With this release, IP-based load balancer attachments are removed from the load balancer before the Amazon EC2 instance is removed from AWS. As a result, the leaks are avoided. (BZ#2065160)

Previously, during an upgrade, a new machine created through the Machine API defaulted to HW-13 which caused the cluster to degrade. With this release, the machine controller checks the virtual machine’s hardware version during machine creation from the template clone. The machine goes into a failed state if the template’s hardware version is less than 15, which is the minimal supported hardware version for OpenShift Container Platform 4.11 and above versions. (BZ#2059338)

Previously, the procedural name generator for Azure availability sets exceeded the 80 character maximum limit. This might cause the Machine API to reuse the same sets during the name truncation, rather than creating multiple availability sets. With this release, the procedural name generator is updated to ensure that the name is no longer than 80 characters and the cluster name is not duplicated in the set name. As a result, Azure availability sets are no longer truncated in unexpected ways by the procedural name generator. (BZ#2093044)

Because the Cluster Autoscaler Operator was deploying the cluster autoscaler without setting any leader election parameters, the cluster autoscaler could unexpectedly fail and restart after a cluster restart. With this fix, the Cluster Autoscaler Operator now deploys the cluster autoscaler with well-defined leader election flags. As a result, the cluster autoscaler operates as expected after restarts. (BZ#2063194)"

Previously, certificate signing request (CSR) renewal was handled by kube-controller-manager and correctly left pending by the machine approver, which increased mapi_current_pending_csr to 1. Afterwards, the kube-controller-manager approved the CSR, but the machine approver would ignore it, which left the metric unchanged. Consequently, the mapi_current_pending_csr was stuck at 1 until another machine approver reconciled it. With this update, CSR approvals are reconciled from other controllers to update metrics properly. As a result, mapi_current_pending_csr is always up-to-date after every reconcile. (BZ#2072195)

Previously, the Machine API Operator did not report as degraded if an insufficient number of worker nodes started upon cluster installation, even though other Operators were reported as degraded. With this release, the Machine API Operator is now reported as degraded and errors are posted in the installation log in this scenario. As a result, with the Machine API Operator appears in the list of failed Operators, and users now know to examine the state of the machines as the reason why there are insufficient worker nodes.(BZ#1994820)

Because the Machine API Operator did not honor the proxy environment variable directives, installation behind an HTTP or HTTPS proxy failed. With this fix, the HTTP transport logic of Machine API Operator now obeys proxy directives. As a result, the Machine API Operator now works in a restricted environment where egress traffic is only allowed through a proxy. (BZ#2082667)

Previously, installations on vSphere for clusters with thousands of tags and heavy API loads were failing. Now, the machine controllers only query tags that are related to a particular OpenShift Container Platform installation. As a result, OpenShift Container Platform installs correctly on vSphere for these clusters. (BZ#2097153)

Because the kubelet needs to contact the vCenter to obtain node zone labels, if the vCenter credentials are stored in a secret, the kubelet could not start because the kube client was not created on time. As a result, if you rebooted the nodes, as happens when you edit the cloud-provider-config config map, the nodes did not come up. With this fix, the kubelet now obtains zone labels after node registration if the credentials are stored in the secret. As a result, the nodes reboot as expected. (BZ#1902307)

Previously, the lack of a timeout option might have led to controller blockage, which could cause vCenter to never, or very slowly, respond. This release adds a timeout option for vCenter clients within the vSphere machine controller. (BZ#2083237)

Previously, the Cluster Version Operator (CVO) when it encountered an error during an upgrade would stop reconciling current release manifests. With this update, release loading is separated from reconciling so the latter does not block the former and a new condition ReleaseAccepted has been added to clarify the status of the release load. (BZ#1822752)

Previously, there was a missing option in the UI to set the bootMode strategy. Consequently, the UI would always use the default (UEFI) boot strategy, which caused problems booting up some types of bare metals deployments. This update exposes a new field in the Add Bare Metal host form to choose the appropriate boot mode strategy. As a result, the bare metal machine properly starts. (BZ#2091030)

Previously, the node maintenance feature was moved to a new project which resulted in API changes. Consequently, node maintenance stopped working. This update fixes the code to work properly with new APIs. As a result, node maintenance works again. (BZ#2090621)

Previously, in some cases, day 2 workers on clusters created by the assisted installer are missing underlying bare metal hosts and machine resources. Consequently, the UI failed when trying to show details of the worker node. With this update, the bare metal hosts and machine resources are handled more gracefully, and the UI shows all available details. (BZ#2090993)

Topology aware hints is a new feature in OpenShift Container Platform 4.11 that allows the EndpointSlice controller to specify hints to the container network interface (CNI) for how it should route traffic to a service’s endpoints. The DNS operator was not enabling topology aware hints for the cluster DNS service. Consequently, the CNI network providers did not keep DNS traffic local to the zone or node. With this fix, the DNS operator was updated to specify topology aware hints on the cluster DNS service. (BZ#2095941)

Previously, the kubelet created a default /etc/resolv.conf for pods based on the /etc/resolv.conf from the node host. Consequently, the malformed resolv.conf file could cause resolvers to fail to parse resolv.conf, therefore breaking DNS resolution in pods. With this update, the kubelet accepts a resolv.conf file and pods get a valid resolv.conf file. (BZ#2063414)

Previously, the DNS Operator did not set the cluster-autoscaler.kubernetes.io/enable-ds-eviction annotation on DNS pods. Consequently, the cluster autoscaler did not remove the DNS pod from a node before removing the node. With this update, the DNS operator was changed to add the cluster-autoscaler.kubernetes.io/enable-ds-eviction annotation to DNS pods. The DNS pod can now be removed from a node before removing the node by the cluster autoscaler. (BZ#2061244)

Previously, the image registry used an ImageContentSourcePolicy (ICSP) as a source only when it was an exact match. The same source file was expected to be pulled through for any subrepositories. The ICSP name and path did not match for subrepositories. As a result, the image was not used. Now, the ICSP is applied successfully to the subrepositories, which can use the mirrored images. (BZ#2014240)

Previously, if the pruner failed, the image registry Operator is reported as degraded until the pruner successfully runs. With this update, the Operator is more resilient to the pruner failures. (BZ#1990125)

Previously, the registry used exact match when applying ImageContentSourcePolicy(ICSP). With this update, ICSP is applied for subrepositories and mirrors now work as expected. (BZ#2014240)

Previously, the Image Registry Operator did not work with AWS S3 on RHOSP. With this update, the Image Registry Operator trusts AWS S3 on all platforms. (BZ#2007611)

Previously, OpenShift Container Platform image registry did not work with Ceph Radosgw. With this update, the image registry works with Ceph Radosgw. (BZ#1976782)

Previously, the Image Registry Operator interpreted 429 error messages from upstream registries as if the data was not available. The Operator returned a 404 Not Found message instead of 429 Too Many Requests. With this update, the proper 429 Too Many Requests message is returned so that administrators know to retry the request. (BZ#1923536)

Previously, the Image Registry Operator could not be used to configure CloudFront. With this update, the Image Registry Operator can configure CloudFront. (BZ#2065224)

Previously, the Image Registry Operator pushed images when KMS encryption was enabled, but not pulled. With this update, images can be pushed and pulled with KMS encryption enabled. (BZ#2048214)

Previously, the Image Registry Operator could not pull public images anonymously due to credentials not being provided. With this update, clients can pull public images anonymously. (BZ#2060605)

Previously, the Image Registry Operator could not use the ap-southeast-3 AWS region. With this update, the registry can be configured to ap-southeast-3. (BZ#2065552)

Previously, if users specified an OpenShift Container Platform cluster name with a period, the installation failed. This update adds a validation check to the installation program, which returns an error if a period is present in the cluster name. (BZ#2084580)

Previously, users could select the AWS us-gov-east-1 region when using the installation program to create the install-config.yaml file. This caused the deployment to fail because the installation program could only be used to create the install-config.yaml file for a public AWS region. This update removes all of the AWS regions from the installation program that are not supported by the public AWS cloud. (BZ#2048222)

Previously, users could not select the ap-north-east-3 region when using the installation program to create the install-config.yaml file. The AWS SDK that caused this problem has been updated, and users can now select the ap-north-east-3 region. (BZ#1996544)

Previously, installing a private (internal) OpenShift Container Platform cluster on Azure Stack Hub failed because the installation program did not create the DNS record for the API virtual IP address. This update removes the invalid check that caused this problem. The installation program now correctly creates DNS records for private cluster. (BZ#2061549)

Previously, uninstalling an IBM Cloud VPC cluster might have caused unexpected results. When a user uninstalled a cluster (cluster 1), the DNS records of another cluster (cluster 2) were removed when either the name of cluster 1 (example) was a subset of the name of cluster 2 (myexample) or both clusters shared a base domain. This update corrects this behavior. Only those resources specific to the cluster that is being uninstalled are now removed. (BZ#2060617)

Previously, Azure Stack Hub did not support any disk types other than Standard_LRS. This update adds the ability to customize disk types, which allows clusters to have a default disk type with no manual customizations. This resulted in making the switch from hard coding the disk type to accepting the inputs from the user and validating it against the Stack Hub APIs. (BZ#2061544)

Previously, when destroying a cluster, the ID of the private route5 hosted zone for the cluster was incorrectly reported when the DNS records were deleted from the hosted zone. This caused incorrect host zone IDs to be reported in the log of the destroyer. This update uses the correct host zone ID in the log. As a result, the log shows the correct hosted zone ID when destroying the DNS record in the base domain’s hosted zone. (BZ#1965969)

Previously, system proxy settings were not considered when requesting an AWS custom service endpoint. This update configures AWS custom service endpoint validation to consider the system proxy settings along with a HEAD request to the AWS custom service endpoint. As a result, the AWS custom service endpoint can be accessed from the user’s machine. (BZ#2048451)

Previously, the installation program used any Terraform provider in the $PATH on the installer host. Therefore, the installation would fail if there were Terraform providers in the $PATH that used an incorrect version or provider rather than the providers embedded in the installation program. With this update, the installation program embeds providers to a known directory and sets Terraform to use the known directory. As a result, installation will be successful because the installation program will always use the providers in the known directory. (BZ#1932812)

Previously, there was an eventual consistency issue in the AWS Terraform provider when updating new load balancers. Therefore, the installation would fail when trying to access the new load balancers. With this fix, the installation program is now updated to an upstream Terraform provider, which ensures eventual consistency. As a result, the installation does not fail. (BZ#1898265)

Previously, the installation program had a list of required APIs that check for quota and permissions, and the list contained some unnecessary APIs that failed if the user did not provide the permissions. With this update, The list of APIs is split into required and optional where the optional APIs are not accessible. A warning message is displayed for the optional APIs. (BZ#2084280)

Previously, the .apps entry did not have the tag kubernetes.io_cluster<infraID> that was used by the installation program to delete code from the database that would isolate all the resources created for a given cluster and delete them. With this update, a tag was added to the cluster Ingress Operator during creation time which makes the entry visible to delete. (BZ#2055601)

Previously, the openshift-install command would fail when using the internal publishing strategy. With this update, the openshift-install command no longer fails. (BZ#2047670)

Previously, there was an eventual consistency issue in the AWS Terraform provider when updating to newly created Virtual Private Clouds (VPCs). Consequently, the installation program would fail when attempting to access VPCs. With this update, the installation program is updated to the upstream Terraform provider and the install does not fail. (BZ#2043080)

Previously, there was an eventual consistency issue in the AWS Terraform provider when updating to newly created network interfaces. Consequently, installs would fail to access the network interfaces. With this update, the Terraform provider is updated to accept eventual consistency and installation does not fail. (BZ#2047741)

Previously, the corespersocket value could be higher than the numCores value when installing a VMware cluster using installer-provisioned infrastructure. This could cause unexpected results during installation. With this update, users receive a warning to correct these values before the cluster is created. (BZ#2034147)

Previously, a rare bug caused inconsistency during AWS cluster installations. The installation program has been updated to avoid this scenario. (BZ#2046277)

Previously, the number of supported user-defined tags was 8, and reserved OpenShift Container Platform tags were 2 for AWS resources. With this release, the number of supported user-defined tags is now 25 and reserved OpenShift Container Platform tags are 25 for AWS resources. You can now add up to 25 user tags during installation. (CFE#592)

Previously, the bootstrap machine used a default size and instance type when installing on Azure using installer-provisioned infrastructure. With this update, the bootstrap machine uses the size and instance type of the control plane machines. You can now control the size and instance type of the bootstrap machine by modifying the control plane settings in your installation configuration. (BZ#2026356)

Previously, the installation program provided Terraform with an ambiguous network name. This could lead to Terraform being unable to determine the correct network to use. With this update, the installation program provides Terraform with a unique network ID so that the installation succeeds. (BZ#1918005)

Previously, control plane machines could be created before the dependent NAT gateway was created when installing a cluster on AWS, causing the installation to fail. With this update, Terraform ensures that the NAT gateway has been created before the control plane machines are created. This ensures that the installation will succeed. (BZ#2049108)

Previously, if you used an OVN network rather than the default OSN network, the scale-up task failed because it took longer than the maximum amount of time required. This update doubles the amount of retries during the scale-up task so that the task can be completed. (BZ#2090151)

Previously, when you tried to delete multiple clusters from the database in parallel, the deletion process failed because of a bug in the vmware and govmomi libraries. The bug caused one of the cluster’s tags to be deleted, which resulted in a 404 error when the deletion process could not find the tag. This update ignores tags that aren’t found and continues the deletion process so that it finishes without error. (BZ#2021041)

With this update, OpenShift Container Platform on Red Hat Virtualization (RHV) supports preallocated disks for control plane and worker nodes for installer-provisioned infrastructure. In high-load environments, preallocated disks benefit performance for etcd and other components. (BZ#2035334)

Previously, when you tried to delete multiple clusters in parallel, the process failed because of a bug in the vmware/govmomi library. The bug caused a cluster tag to be deleted, which resulted in a 404 error when the deletion process could not find the tag. This update ignores tags that are not found and continues to delete so that it finishes without error. (BZ#2021041)

Previously, installation methods for VMware vSphere included validation that checked for network existence during the creation of configuration files. This caused an error for user-provisioned infrastructure and other installation methods where the network can be created as part of provisioning the infrastructure, in which case the network might not exist when the config files are generated. This fix updates the installation program to only perform network validation on installer-provisioned infrastructure installs. As a result, user-provisioned infrastructure and other installation methods can generate configuration files regardless of network existence. (BZ#2050767)

Previously, runc had an inversioned dependency on libseccomp 2.5 or later, which causes issues when the operating system was installed using version 8.3 or later and not fully updated to 8.4 or later. With this update, the RHEL host installs successfully, avoiding issues with early versions of the package. (BZ#2060147)

Previously, the installation program specified network resources to terraform by the relative path. When a network resource was nested in a folder, the terraform provider could not find the resource. With this update, network resources are now specified by ID, and the installation succeeds. (BZ#2063829)

Previously, vSphere RHCOS images had no /etc/resolv.conf file. This caused the default networkmanager settings to display an error for /etc/resolv.conf. With this update, the rc-manager=unmanaged value is set, and the networkmanager settings do not direct to /etc/resolv.conf. (BZ#2029438)

Previously, the installation program did not create a cloud provider configuration because it is not required by Amazon Web Services (AWS). This caused the Kubernetes API server to provide an error without a cloud provider configuration. With this update, an empty cloud provider configuration for AWS is created, and the Kubernetes API server can run successfully. (BZ#1926975)

Previously, long running requests used for streaming were taken into account for the KubeAPIErrorBudgetBurn calculation. Consequently, The alert from KubeAPIErrorBudgetBurn would be triggered and cause false positives. This update excludes long running requests from the KubeAPIErrorBudgetBurn calculation. As a result, false positives are reduced on the KubeAPIErrorBudgetBurn metric. (BZ#1982704)

With OpenShift Container Platform 4.11, the hosted control plane namespace is excluded from eviction when the descheduler is installed on a cluster that has hosted control planes enabled. As a result, pods are no longer evicted from the hosted control plane namespace when the descheduler is installed. (BZ#2000653)

Previously, resources incorrectly specified the API version in the owner reference of the kubedescheduler custom resource (CR). Consequently, the owner reference was invalid, and the affected resources would not be deleted when the kubedescheduler CR ran. This update specifies the correct API version in all owner references. As a result, all resources with an owner reference to the kubedescheduler CR are deleted after the CR is deleted. (BZ#1957012)

Because keyFile is not configured as the default plugin for NetworkManager on RHEL nodes, RHEL nodes might not reach the ready state after a reboot. With this fix, keyFile is set as the default NetworkManager plugin on all cluster nodes. As a result, nodes correctly reach the ready state after a reboot. (BZ#2060133)

Because vSphere UPI clusters do not set the PlatformStatus.VSphere parameter at installation, the parameter was set to nil. This caused the MCO logs to be filled with unnecessary and repetitive messages that this parameter cannot have the value nil. This fix removes the warning, which was added to resolve a separate issue. As a result, the logs no longer list this message for vSphere UPI installations. (BZ#2080267)

Previously, when you attempted to create a cluster with both FIPS and realTimeKernel the Machine Config Operator (MCO) degraded due to a merge logic issue within the code. With this update, the MCO no longer degrades when creating a cluster with both FIPS and realTimeKernel. (BZ#2096496)

Previously, the Compliance Operator held references to machine configuration data, which significantly increased memory usage. Consequently, the Compliance Operator would fail with CrashLoopBackoffs because of out-of-memory exceptions. As a workaround, you should use an updated version of the Compliance Operator, for example. 0.1.53, which includes better handling of large machine configuration data sets in memory. As a result, the Compliance Operator continues to run when dealing with large machine configuration data sets. (BZ#2094854)

Previously, the web console was not properly authenticating permissions when approving InstallPlans. This resulted in a possible unhandled error. With this update, permissions were altered for consistency and error messages are now displayed correctly in the web console. (BZ#2006067)

Before this update, dashboards in the OpenShift Container Platform web console that contained queries using a container label for container_fs* metrics returned no data points because the container labels had been dropped due to high cardinality. This update resolves the issue, and these dashboards now display data as expected. (BZ#2037513)

Before this update, the prometheus-operator component allowed any time value for ScrapeTimeout in the config map. If you set ScrapeTimeout to a value greater than the ScrapeInterval value, Prometheus would stop loading the config map settings and fail to apply all subsequent configuration changes. With this update, if the ScrapeTimeout value specified is greater than the ScrapeInterval value, the system logs the settings as invalid, but continues loading the other config map settings. (BZ#2037762)

Before this update, in the CPU Utilisation panel on the Kubernetes / Compute Resources / Cluster dashboard in the OpenShift Container Platform web console, the formula used to calculate the CPU utilization of a node could incorrectly display invalid negative values. With this update, the formula has been updated, and the CPU Utilisation panel now shows correct values. (BZ#2040635)

Before this update, data from the prometheus-adapter component could not be accessed during the automatic update that occurs every 15 days because the update process removed old pods before the new pods became available. With this release, the automatic update process now only removes old pods after the new pods are able to serve requests so that data from the old pods continues to be available during the update process. (BZ#2048333)

Before this update, the following metrics were incorrectly missing from kube-state-metrics: kube_pod_container_status_terminated_reason, kube_pod_init_container_status_terminated_reason, and kube_pod_status_scheduled_time. With this release, kube-state-metrics correctly displays these metrics so that they are available. (BZ#2050120)

Before this update, if invalid write relabel config map settings existed for the prometheus-operator component, the configuration would still load all subsequent settings. With this release, the component checks for valid write relabel settings when loading the configuration. If invalid settings exist, an error is logged, and the configuration loading process stops. (BZ#2051470)

Before this update, the init-config-reloader container for the Prometheus pods requested 100m of CPU and 50Mi of memory, even though in practice the container needed fewer resources. With this update, the container requests 1m of CPU and 10Mi of memory. These settings are consistent with the settings of the config-reloader container. (BZ#2057025)

Before this update, when an administrator enabled user workload monitoring, the user-workload-monitoring-config config map was not automatically created. Because non-administrator users with the user-workload-monitoring-config-edit role did not have permission to create the config map manually, they required an administrator to create it. With this update, the user-workload-monitoring-config config map is now automatically created when an administrator enables user workload monitoring and is available to edit by users with the appropriate role. (BZ#2065577)

Before this update, after you deleted a deployment, the Cluster Monitoring Operator (CMO) did not wait for the deletion to be completed, which caused reconciliation errors. With this update, the CMO now waits until deployments are deleted before recreating them, which resolves this issue. (BZ#2069068)

Before this update, for user workload monitoring, if you configured external labels for metrics in Prometheus, the CMO did not correctly propagate these labels to Thanos Ruler. If you queried external metrics for user-defined projects, not provided by the user workload monitoring instance of Prometheus, you would sometimes not see external labels for these metrics even though you had configured Prometheus to add them. With this update, the CMO now properly propagates the external labels that you configured in Prometheus to Thanos Ruler, and you can see the labels when you query external metrics. Therefore, for user-defined projects, if you queried external metrics not provided by the user workload monitoring instance of Prometheus, you would sometimes not see external labels for these metrics even though you had configured Prometheus to add them. With this update, the CMO now properly propagates the external labels that you configured in Prometheus to Thanos Ruler, and you can see the labels when you query external metrics. (BZ#2073112)

Before this update, the tunbr interface incorrectly triggered the NodeNetworkInterfaceFlapping alert. With this update, the tunbr interface is now included in the list of interfaces that the alert ignores and no longer causes the alert to trigger incorrectly. (BZ#2090838)

Previously, the Prometheus Operator allowed invalid re-label configurations. With this update, the Prometheus Operator validates re-labeled configurations. (BZ#2051407)

Previously, when using the bond CNI plugin for an additional network attachment, it was not compatible with Multus. When the bond CNI plugin was used in conjunction with the Whereabouts IPAM plugin for a network attachment definition, assigned IP addresses were incorrectly reconciled. Now a network attachment definition that uses the bond CNI plugin works correctly with the Whereabouts IPAM plugin for IP address assignment. (BZ#2082360)

Previously, when using the OVN-Kubernetes cluster network provider with multiple default gateways, the wrong gateway was selected, causing the OVN-Kubernetes pods to stop unexpectedly. Now the correct default gateway is selected such that these pods no longer fails. (BZ#2040933)

For clusters using the OVN-Kubernetes cluster network provider, previously if the NetworkManager service restarted on a node, that node lost network connectivity. Now network connectivity survives a restart of the NetworkManager service. (BZ#2048352)

Previously a goroutine handling cache updates could stall writing to an unbuffered channel while holding a mutex. With this update, these race conditions were solved. (BZ#2052398)

Previously, for ovn-kubernetes, setting up br-ex on boot with a bond or team interface caused a mismatch on media access control (MAC) addresses between the br-ex and the bond interface. Consequently, on bare metal or some virtual platforms all of the traffic was dropped due to network interface controller (NIC) driver dropping traffic due to an unexpected br-ex MAC address. With this update, br-ex and the bond interface use the same MAC address resulting in no dropped traffic. (BZ#2103080)

Previously, users with cluster-reader role could not read custom resources from kubernetes-nmstate, such as NodeNetworkConfigurationPolicy. With this update, users with cluster-reader role can read kubernetes-nmstate custom resources. (BZ#2022745)

Previously, contrack entries for LoadBalancer IPs were not removed when the service endpoints were removed causing connections to fail. With this update, contrack entries do not cause connections to fail. (BZ#2061002)

Previously, a missing jq package caused the scale up of a cluster with RHEL nodes to fail on node deployment. With this update, jq package is installed on deployment and the scale up of a cluster with RHEL nodes succeeds. (BZ#2052393)

Previously, OVN-Kubernetes spent excessive time when a service configuration change was made. This caused a noticeable latency in service configuration changes. With this update, OVN-Kubernetes is optimized to reduce the latency of service configuration changes. (BZ#2070674)

Previously, the IP reconciliation CronJob for Whereabouts IPAM CNI would fail due to API connectivity issues, which caused CronJob to intermittently fail. With this update, CronJob launched on Whereabouts IPAM CNI use the api-internal server address and an extended api timeout to prevent these connectivity issues. (BZ#2048575)

With this update, OpenShift Container Platform clusters with Kubernetes-NMstate installed now include in the must-gathers Kubernetes-NMstate resources. This improves issue handling by including resources from Kubernetes-NMstate in must-gathers. (BZ#2062355)

There is currently a known issue with host routes being ignored when load-balancer services are configured with cluster traffic policy. Consequently, egress traffic of load balancer services is steered to the default gateway and not towards the best matching route that is present on the host routing table. As a workaround, set the load balancer type Services to Local traffic policy. (BZ#2060159)

Previously, PodDisruptionBudget specifications did not fit for single-node OpenShift clusters, which limited upgrade capabilities due to not all pods being able to be evicted. With this update, PodDisruptionBudget specification is adjusted based on cluster topology making Kubernetes-NMState operator capable of upgrading on single-node OpenShift clusters. (BZ#2075491)

Previously, when setting up br-ex bridge on boot, the DHCP client id and IPv6 address generation mode configuration did not work properly causing an unexpected IP address on br-ex. With this update, DHCP client id and IPv6 generation mode configuration are now properly set on br-ex. (BZ#2058030)

Previously, egress-router-cni pods lacked some cluster internal routes due to the reliance on the gateway field of the CNI definition to delete the default route and inject its own. With this update, egress-router-cni pods inject the correct routing information so that pods reach external and internal cluster destinations. (BZ#2075475)

Previously, a pod disruption budget was used to create an OVN raft quorum on single-node OpenShift. This raised an unhelpful PodDisruptionBudgetAtLimit alert on single-node OpenShift clusters. With this update, the PodDisruptionBudgetAtLimit alert is no longer raised on these clusters. (BZ#2037721)

Previously, a race condition in the NetworkManager restart sometimes prevented DHCP resolution to successfully complete setting up the br-ex bridge on node boot when using OVN-Kubernetes. With this update, NetworkManager is no longer restarted when setting up br-ex, eliminating the race condition. (BZ#2055433)

Previously, the PtpConfigSlave source custom resource (CR) was set to the unsupported network transport UDPv4, causing errors on Distributed Unit (DU) nodes. This fix updates the PtpConfigSlave source CR to use network transport L2 rather than UDPv4. As a result, errors are no longer found on the DU nodes. (BZ#2060492)

Previously, all OpenShift Container Platform policies logging configurations were updated when a network policy was updated. This caused a noticeable latency on some concurrent or later network policies. With this update, all network policies are no longer updated when adding a new policy, eliminating latency. (BZ#2089392)

Previously, a systemd service set a default Recieve Packet Steering (RPS) mask according to the reserved CPUs list in the performance profile for all network devices visible from udev excluding virtual devices. A crio hook script set the RPS mask of all network devices visible from /sys/devices for guaranteed pods. This resulted in multiple impacts to network performance. In this update, the systemd service only sets the default RPS mask for virtual interfaces under /sys/devices/virtual. The crio hook script now also excludes physical devices. This configuration mitigates issues such as overloading of processes, lengthy polling intervals, and spikes in latency.(BZ#2081852)

Previously, the pod manager handled the registration and de-registration of pod secrets and config maps. Because of this, pod secrets would sometimes fail to be mounted within a pod. With this fix, the pod ID is included in the key that the kubelet uses to manage registered pods. As a result, secrets are properly mounted as expected. (BZ#1999325)

Because of a memory leak in the garbage collection process, pods might not be able to start on a node due to lack of memory. With this fix memory is no longer leaking in the garbage collection process and nodes should start as expected. (BZ#2065749)

Because of a change in the upstream Kubernetes, the kubelet was not running readiness probes on terminated pods. As a result, a load balancer or controller could react more slowly to a terminating pod, which might have resulted in errors. With this fix, readiness probes are again being performed on pod termination. (BZ#2089933)

Because of a bug, the kubelet could incorrectly reject pods that have OutOfCpu errors, if the pods were rapidly scheduled after other pods were reported as complete in the API. With this fix, the kubelet now waits to report the phase of a pod as terminal in the API until all running containers have stopped and no new containers have been started. Short-lived pods may take slightly longer, approximately 1s, to report either success or failure after this change. (BZ#2022507)

Because recent versions of the prometheus-adapter are sending additional pod metrics, the Vertical Pod Autoscaler (VPA) recommender is producing a large number of unnecessary and repetitive messages. With this fix, the VPA recognizes and ignores the extra metrics. As a result, these messages are no longer being produced. (BZ#2102947)

Previously, oc catalog mirroring failed if an older, deprecated image version was used as the source. Now, the image manifest version is detected automatically and mirroring works successfully. (BZ#2049133)

Previously, it was hard to understand from the logs when fallback inspect occurred. The logs are now improved to make this more explicit. As a result, the output of must-gather run is much more clear. (BZ#2035717)

Previously, if you ran must-gather with invalid arguments, it did not consistently report the error and instead might attempt to collect data even when that is not possible. Now if must-gather is called with invalid options, it provides useful error output. (BZ#1999891)

Previously, if the oc adm catalog mirror command resulted in errors, it still continued and returned a 0 exit code. A --continue-on-error flag is now available that allows users to determine whether the command should continue if there are errors, or exit with a non-zero exit code. (BZ#2088483)

With this update, a --subresource flag was added to the oc adm policy who-can command to check who can perform a specified action on a subresource. (BZ#1905850)

Previously, users were unable to use tab completion for the oc project command. Now, hitting tab after oc project properly lists projects. (BZ#2080416)

Previously, startup probes were not removed from debug pods, which could cause issues with the debug pods if the startup probe failed. The --keep-startup flag has been added, which is false by default, meaning that startup probes are removed by default from debug pods. (BZ#2056122)

Previously, there was no timeout specified after invoking oc debug node, so users were never logged out of the cluster. A TMOUT environment variable has been added, so that after the specified time of inactivity, the session is automatically terminated. (BZ#2043314)

With this update, oc login now shows the URL for the web console even when users are logged out. (BZ#1957668)

Previously, the oc rsync command displayed a wrong error output when the container was not found. With this release, the oc rsync command displays the correct error message when the specific container is not running. (BZ#2057633)

Previously, large images could not be pruned if they were new to the cluster. This caused recent images to be omitted when filtering the over sized images. With this release, you can now prune images that exceed the given size. (BZ#2083999)

Previously, there was a typo in the gather script. As a result, insights data was not collected properly. With this release, the typo is corrected and Insights data is now properly collected through the must-gather. (BZ#2106543)

Previously, you could not apply the EgressNetworkPolicy resource type in your cluster through the oc CLI. With this release, you can now create, update, and delete an EgressNetworkPolicy resource. (BZ#2071614)

Previously, the beta feature for tracking jobs using pod finalizers was enabled by default. In some cases, pods were not always removed because the finalizers on them were not removed. With this update, the feature gate JobTrackingWithFinalizers is disabled by default. As a result, no pods should be left behind during removal. (BZ#2075621)

Previously, a PodDisruptionBudgetAtLimit alert would occur whenever the CR replica count was zero. With this update, the alert will no longer fire if there is no application to disrupt or when the replica count is zero. (BZ#2053622)

Before this update, invalid subscription labels were created when a resource name exceeded 63 characters. Truncating labels that exceed the 63-character limit resolves the issue, and the subscription resource no longer rejects the Kubernetes API. (BZ#2016425)

Before this update, catalog source pods for the Marketplace Operator prevented nodes from draining. As a result, the Cluster Autoscaler could not scale down effectively. With this update, adding the cluster-autoscaler.kubernetes.io/safe-to-evict annotation to the catalog source pods fixes the issue, and the Cluster Autoscaler can scale down effectively. (BZ#2053343)

Before this update, the collect-profiles job could take a long time to complete in certain circumstances, such as when a pod could not be scheduled. As a result, if enough jobs were scheduled but unable to run, the number of scheduled jobs exceeded pod quota limits. With this update, only one collect-profiles pod exists at a time, and the collect-profiles job does not exceed pod quota limits. (BZ#2055861)

Before this update, the package server was not aware of pod topology when defining its leader election duration, renewal deadline, and retry periods. As a result, the package server strained topologies with limited resources, such as single-node environments. This update introduces a leaderElection package that sets reasonable lease duration, renewal deadlines, and retry periods. This fix reduces strain on clusters with limited resources. (BZ#2048563)

Previously, there was a bad catalog source in the openshift-marketplace namespace. Because of this, all subscriptions were blocked. With this update, if there is a bad catalog source in the openshift-marketplace namespace, users can subscribe to an operator from a quality catalog source of their own namespace with the original annotation. As a result, if there is a bad catalog source in the local namespace, the user cannot subscribe to any operator in the namespace. (BZ#2076323)

Previously, info-level logs were generated during operator-marketplace project polling, which caused log spam. This update uses the command line flag to reduce the log line to the debug level, and adds more control of the log levels for the user. As a result, this reduces log spam. (BZ#2057558)

Previously, each component managed by the Cluster Version Operator (CVO) consisted of YAML files defined in the /manifest directory in the root of a repository for a project. When removing a YAML file from the /manifest directory, you needed to add the release.openshift.io/delete: “true” annotation, otherwise the CVO would not delete the resources from the cluster. This update reintroduces any resources that were removed from the /manifest directory and adds the release.openshift.io/delete: “true” annotation so that the CVO cleans up the resources. As a result, resources that are no longer required for the OLM component are removed from the cluster. (BZ#1975543)

Previously, the CheckRegistryServer function used by gRPC catalog sources did not confirm the existence of the service account associated with the catalog source. This caused the existence of an unhealthy catalog source with no service account. With this update, the gRPC CheckRegistryServer function checks if the service account exists and recreates the service if it is not found. As a result, the OLM recreates service accounts owned by gRPC catalog sources if they do not exist. (BZ#2074612)

Previously, in an error message that occurred when users ran opm index prune against a file-based catalog image, imprecise language made it unclear that this command does not support that catalog format. This update clarifies the error message so users understand that the command opm index prune only supports SQLite-based images. (BZ#2039135)

Previously, there was a broken thread safety around the Operator API. Consequently, Operator resources were not properly deleted. With this update, Operator resources are correctly deleted. (BZ#2015023)

Previously, pod failures were artificially extending the validity period of certificates causing them to incorrectly rotate. With this update, the certificate validity period is correctly determined and the certificates are correctly rotated. (BZ#2020484)

In OpenShift Container Platform 4.11 the default cluster-wide pod security admission policy is set to baseline for all namespaces and the default warning level is set to restricted. Before this update, Operator Lifecycle Manager displayed pod security admission warnings in the operator-marketplace namespace. With this fix, reducing the warning level to baseline resolves the issue. (BZ#2088541)

Before this update, the Operator SDK used upstream images rather than downstream supported images to scaffold Hybrid Helm-based Operators. With this update, the Operator SDK uses supported downstream images to scaffold Hybrid Helm-based Operators. (BZ#2039135)

With OpenShift Container Platform 4.11, Operator SDK allows for arm64 Operator images to be built. As a result, Operator SDK now supports building Operator images that target arm64. (BZ#2035899)

Previously, {product-tile} running Hybrid Helm Operators scaffolded with Operator SDK would use upstream images rather than supported downstream images. With this update, scaffolding a Hybrid Helm Operator uses downstream images. (BZ#2066615)

Because multiple Authentication Operator controllers were synchronizing at the same time, the Authentication Operator was taking too long to react to changes to its configuration. This feature adds jitter to the regular synchronization periods so that the Authentication Operator controllers do not compete for resources. As a result, it now takes less time for the Authentication Operator to react to configuration changes. (BZ#1958198)

With OpenShift Container Platform 4.11, authentication attempts from external identity providers are now logged to the audit logs. As a result, you can view successful, failed, and errored login attempts from external identity providers in the audit logs. (BZ#2086465)

Before this update, if a machine was booted through PXE and the BOOTIF argument was on the kernel command line, the machine would boot with DHCP enabled on only a single interface. With this update, the machine boots with DHCP enabled on all interfaces even if the BOOTIF argument is provided. (BZ#2032717)

Previously, nodes that were provisioned from VMware OVA images did not delete the Ignition config after initial provisioning. Consequently, this created security issues when secrets are stored within the Ignition config. With this update, the Ignition config is now deleted from the VMware hypervisor after initial provisioning on new nodes and when upgrading from a previous OpenShift Container Platform release on existing nodes. (BZ#2082274)

Previously, any arguments provided to the toolbox command were ignored when the command was first invoked. This fix updates the toolbox script to initiate the podman container create command followed by the podman start and podman exec commands. It also modifies the script to handle multiple arguments and whitespaces as an array. As a result, the arguments passed to the toolbox command are executed every time as expected. (BZ#2039589)

Previously, the CNF cyclictest runner should have provided the --mainaffinity argument, which told the binary which thread it should run on, however the cyclictest runner was missing the --mainaffinity argument. This update adds the --mainaffinity argument to the cyclictest runner, so that it is properly passed to the cyclitest command. (BZ#2051540)

Previously, the oslat container specs lacked the cpu-quota.crio.io: "disable" annotation, which resulted in high latency. Consequently, the cpu-quay.crio.io:"disable" annotation was missing from the pod definition during creation. With this update, the cpu-quota.crio.io:"disable" annotation is appended during pod creation and, as a result, appears in the oslat pod’s specification field. (BZ#2061676)

Previously, the Ingress Operator did not validate whether a Kubernetes service object in the OpenShift Ingress namespace was created or owned by the Ingress Controller it was trying to reconcile with. Therefore, the Ingress Operator would modify or remove Kubernetes services that had the same name and namespace, regardless of ownership, causing unexpected behavior. With this update, the Ingress Operator can now check the ownership of existing Kubernetes services before attempting to modify or remove services. If ownership does not match, the Ingress Operator shows an error and does not take any action. As a result, the Ingress Operator cannot cannot modify or delete a custom Kubernetes service with the same name as the OpenShift Ingress namespace that it wants to modify or remove. (BZ#2054200)

Previously, OpenShift Container Platform 4.8 added an API for customizing platform routes. This API includes status and spec fields in the cluster ingress configuration for reporting the current host names of customizable routes and the user’s desired host names for these routes, respectively. The API also defined constraints for these values. These constraints were restrictive and excluded some valid potential host names. Consequently, the restrictive validation for the API prevented users from specifying custom host names that should have been permitted and prevented users from being able to install clusters with domains that should have been permitted. With this update, the constraints on host names were relaxed to allow all host names that are valid for routes and OpenShift Container Platform allows users to use cluster domains with TLDs that contain decimal digits. (BZ#2039256)

Previously, the Ingress Operator did not check whether Ingress Controllers configured with cluster spec.domain parameter matched the spec.baseDomain parameter. This caused the Operator to create DNS records and set DNSManaged conditions to false. With this fix, the Ingress Operator now checks whether the spec.domain parameter matches with the cluster spec.baseDomain. As a result, for custom Ingress Controllers, the Ingress Operator does not create DNS records and sets DNSManaged conditions to false. (BZ#2041616)

Previously, in OpenShift Container Platform 4.10, the HAProxy must-gather function could take up to an hour to run. This can happen when routers in the terminating state delay the oc cp command. The delay lasts until the pod is terminated. With the new release, a 10 minute limit on the oc op command prevents longer delays. (BZ#2104701)

Previously, the Ingress Operator did not clear the route status when Ingress Controllers were deleted, showing that the route was still in the operator after its deletion. This fix clears the route status when an Ingress Controller is deleted, resulting in the route being cleared in the operator after its deletion. (BZ#1944851)

Previously, the output for the oc explain router.status.ingress.conditions command explain route status showed Currently only Ready rather than Admitted due to incorrect wording in the Application Programming Interface (API). This fix corrects the wording in the API. As a result, the command output is correct. (BZ#2041133)

Previously, the Ingress Operator detected that the user modified an annotation that the Operator manages on the LoadBalancer-type service. Consequently, the Operator set the Ingress Cluster Operator’s Upgradeable status condition to False to block upgrades, and the Ingress Operator erroneously set the Upgradeable status condition to False, blocking upgrades, if the service had no annotations. Now, the logic that checks the service’s annotations correctly handles empty annotations, and the Ingress Operator no longer erroneously blocks upgrades. (BZ#2097555)

Previously, the Ingress Operator removed a finalizer that the Operator added to LoadBalancer-type services from previous versions of OpenShift Container Platform. With this update, the Ingress Operator no longer removes finalizers. (BZ#2069457)

The Ingress Operator performs health checks against the ingress canary route. Before this update, keepalive daemons are enabled on the connection, which caused the Ingress Operator not to close the TCP Connection to the load balancer (LB) after the health check was completed. A new connection was created for the next health check instead of using the existing connection. Consequently, the connection built on the load balancer and creating too many connections on the load balancer. With this update, keepalive daemons are disabled when connecting to the canary route, and a new connection is made and closed each time the canary probe is run. (BZ#2037447)

Previously, the Ingress Controller did not set the allowPrivilegeEscalation value to false in the router deployment, which caused the router pods to be selected into the incorrect Security Context Constraint (SCC) and created conflicts with custom SCCs. This fix sets the allowPrivilegeEscalation value to true, ensuring that router pods are selected into the correct SCC and avoid conflicts with custom SCCs. (BZ#2007246)

Previously, when the canary route was not admitted to an Ingress Controller, the Ingress Operator status condition did not show as degraded. Consequently, the canary route could have shown as valid when its status condition should show as not admitted. With this update, the Ingress Operator status more accurately reflects the status of the canary controller. (BZ#2021446)

Previously, the openshift-router process briefly ignored the SIGTERM shutdown signal. This caused containers to ignore a Kubernetes shutdown request, resulting in one hour shutdown times. With this update, the router now responds to SIGTERM signals. (BZ#2076297)

Previously, when an Ingress Controller for an admitted route was deleted or a sharding configuration was added, a false status of admitted was given. With this update, the Ingress Controller clears the status of an unadmitted route, avoiding the false status scenario. (BZ#1944851)

Previously, OpenShift Container Platform clusters installed using version 4.7 or earlier maintained a service.beta.kubernetes.io/aws-load-balancer-internal annotation value of 0.0.0.0/0. Clusters that were installed using 4.8 or later have the annotation value true. AWS cloud-provider implementations that check for the annotation value true would return the wrong result if the value was 0.0.0.0/0. As a result, cluster upgrades to 4.10 would not complete. With this update, the annotation value is normalized to true so that the cluster upgrades can complete. (BZ#2055470)

Before this update, SRO installed Node Feature Discovery (NFD) by default, regardless of whether NFD had already been installed. If NFD had been installed, this would cause the SRO deployment to fail. SRO no longer deploys NFD by default.

Previously, the Alibaba Container Storage Interface (CS) driver that shipped with OpenShift Container Platform returned errors when a user created a persistent volume claim (PVC) smaller than 20 GiB. This was due to Alibaba Cloud only supporting volumes larger than 20 GiB. With this update, Alibaba CSI driver automatically increases all volume sizes to at least 20 GiB and smaller PVCs are now dynamically provisioned. This can result in increased costs. Administrators can use quota on PVC count for each namespace in restricted environments to limit costs. (BZ#2057495)

In earlier versions, the Local Storage Operator (LSO) added an owner reference to the persistent volumes (PVs) it created, such that deletion of the node would also issue a delete request for the PV. This could result in the PV remaining in the Terminating state while still attached to a pod. LSO no longer creates that OwnerReference, which means cluster administrators must delete any unused PVs after a node is removed from the cluster. (BZ#2061447) For more information, see Persistent storage using local volumes.

This fix ensures that read-only-many volumes are provisioned appropriately by GCP CSI Driver as read-only. (BZ#1968253)

OpenShift Container Platform allows installation of vSphere CSI drivers shipped by either the upstream community or VMware. Although Red Hat does not support this driver, cluster administrators can still install and use it because it has more features than the vSphere CSI driver shipped by Red Hat. OpenShift Container Platform can be upgraded to 4.11 with the upstream and VMware vSphere CSI driver, however, you will be warned about the presence of a third party CSI driver. For more information, see (BZ#2089419) and (BZ#2052071).

With this update, the default credentials request for Amazon Web Services (AWS) is modified to allow mounting of encrypted volumes using customer managed keys from Key Managment Service (KMS). Administrators who created credentials requests in manual mode with the Cloud Creditial Operator (CCO) will need to apply those changes manually if they intend to mount encrypted volumes using customer managed keys on AWS. Other administrators should not be impacted by this change. (BZ#2049872)

Previously, after deleting an OpenShift Container Platform cluster deployed on IBM Cloud, the back-end storage volumes were not deleted. This prevented the cluster resources from being completely removed. This fix adds support in the installation program and the Container Storage Interface (CSI) driver, resulting in back-end volume deletion after a cluster is removed. (BZ#2047732)

Before this update, the Git Import form displayed an error message when an invalid devfile repository (older than devfile v2.2) is entered. With this update, the error message states that devfiles older than v2.2 are not supported. (BZ#2046435)

Before this update, if the ConsoleLink CR (openshift-blog) was not available in the cluster, the blog link was undefined. Clicking on the blog link did not redirect to the OpenShift blog. With this update, a fall back link to https://developers.redhat.com/products/openshift/whats-new is added even if the ConsoleLink CR (openshift-blog) is not present in the cluster. (BZ#2050637)

Before this update, the API version for the kafka CR was updated. This version did not support the old version, so an empty Bootstrap server was displayed on Create Event Source - KafkaSource even if it was created. With this update, the updated APIs for the Kafka CR support the old versions and renders the Bootstrap server list in Create Event Source - KafkaSource form. (BZ#2058623)

Before this update, when you used the Import from Git form to import a private Git repository, the correct import type and a builder image were not identified because the secret to fetch the private repository details was not decoded. With this update, the Import from Git form decodes the secret to fetch the private repository details. (BZ#2053501)

Before this update, from the developer perspective, the Observe dashboard opened for the most recently viewed workload rather than the one you selected in the Topology view. This issue happens because the session prefers the redux store instead of the query parameters in the URL. With this update, the Observe dashboard renders components based on the query parameters in the URL. (BZ#2052953)

Before this update, the Pipeline used to start with the hardcoded value gp2 as the default storage class even if it did not exist on the cluster. With this update, you can use the default specified storage class name instead of a hardcoded value. (BZ#2084635)

Before this update, while running high-volume pipeline logs, the auto-scroll functionality does not work and logs display older messages. Running high-volume pipeline logs generates a large number of calls to the scrollIntoView method. With this update, high-volume pipeline logs do not generate any calls to the scrollIntoView method and gives a smooth auto-scroll functionality. (BZ#2014161)

Before this update, when creating a RoleBinding using the Create RoleBinding form, the subject name was mandatory. A missing subject name fails to load the Project Access tab. With this update, the RoleBinding without the Subject Name property is not listed in the Project Access tab. (BZ#2051558)

Before this update, the sink and trigger for event sources showed all the resources, even though those are standalone or part of backing the k-native service, Broker, or KameletBinding. The addressed resources used to show in the sink dropdown list. With this update, a filter has been added to show only standalone resources as sink. (BZ#2054285)

Before this update, the empty tabs in the sidebar of the topology view were not filtered out before rendering. This displayed invalid tabs for Workloads in the topology view. With this update, the empty tabs are filtered properly before rendering. (BZ#2049483)

Before this update, when a pipeline is started using the Start Last Run button, the started-by annotation of the created PipelineRun was not updated to the correct username so the triggered by section did not show the correct username. With this update, the started-by annotation value is updated to the correct username and the triggered by section shows the username of the correct user that started the pipeline. (BZ#2046618)

Before this update, the ProjectHelmChartRepository CR does not show up in the cluster. Consequently, the API schema for this CR has not been initialized in the cluster yet. With this update the ProjectHelmChartRepository shows up in the cluster. (BZ#2054197)

Before this update, when you navigate using a keyboard in the topology, the selected items were not highlighted. With this update, navigation using a keyboard highlights and updates styles to the selected items. (BZ#2039277)

Before this update, the layout of the web terminal opened outside of the default view and could not be resized. With this update, the web terminal opens inside the default view and resizes properly. (BZ#2022253)

Before this update, some of the sidebar items did not contain namespace context. Consequently, when links were opened from another browser, or opening links from a different active namespace, the web console does not switch to the correct namespace. With this update, the correct namespace is selected when opening the URL. (BZ#2039647)

Previously, when using the console to instantiate a template, its parameters were stored as a secret resource. When the template was removed, the secret remained. This consequently created an unnecessary build up of secrets in a cluster. With this update, an ownership reference is added to the secret that maps to the template instance. Now, when the template instance is removed, the secret is also removed. (BZ#2015042)

With this update, the jsonData property has been deprecated and replaced with data in the ping source. (BZ#2084438)

Previously, the topology view in the OpenShift Container Platform web console would fail or lag for clusters with more than 100 nodes. With this update, the topology view shows a LimitExceeded state for clusters with more than 100 nodes. An option is provided to view the resources by using the Search page instead. Alternatively, you can click Show topology anyway to continue to load the topology view. (BZ#2060329)

Previously, if a service exposed multiple service ports and the route target port was 8080, attempts to change the target port would result in another service port being updated instead of the port 8080 service port. With this update, the service port corresponding to the active target port is replaced when a new target port is set. (BZ#2077943)

Previously, the git detection used to manage instance APIs to get repository information did not work for repositories from self hosted GitHub and Bitbucket. With this update, detection for self hosted GitHub and Bitbucket instance repositories works. (BZ#2038244)

Previously, apiVersion was not passed in the correct format to the Resource drop-down menu in the EventSource creation form. This caused InContext to not be selected under EventSource creation, which excluded it from the Resource drop-down menu. With this update, the Resource drop-down menu includes Resource from InContext. (BZ#2070020)

Previously, the Pipeline metrics page displayed all API calls for the metrics query and failed with a 404 error. With this update, the prometheus-tenancy API is used to get the metrics data for the pipeline. Now, the pipeline metrics page displays all data and graphs to the non-admin user with at least view access to the namespace. (BZ#2041769)

Previously, you could access a quick search and add modal with the Crtl+space keyboard shortcut, but you could not close them by using the same keyboard shortcut. With this update, you can close the quick search and add modal using the Ctrl+space keyboard shortcut. (BZ#2093586)

Previously, the resources created for user settings were not removed if the user was deleted. Consequently, the created resources in the openshift-console-user-settings namespace was never removed. With this update, an ownerReference is added to your metadata at creation. This allows automatic removal of the resources when the user no longer exists. (BZ#2019564)

TP: Technology Preview

GA: General Availability

-: Not Available

DEP: Deprecated

In OpenShift Container Platform 4.1, anonymous users could access discovery endpoints. Later releases revoked this access to reduce the possible attack surface for security exploits because some discovery endpoints are forwarded to aggregated API servers. However, unauthenticated access is preserved in upgraded clusters so that existing use cases are not broken.

## Snippet to remove unauthenticated group from all the cluster role bindings
$ for clusterrolebinding in cluster-status-binding discovery system:basic-user system:discovery system:openshift:discovery ;
do
### Find the index of unauthenticated group in list of subjects
index=$(oc get clusterrolebinding ${clusterrolebinding} -o json | jq 'select(.subjects!=null) | .subjects | map(.name=="system:unauthenticated") | index(true)');
### Remove the element at index from subjects array
oc patch clusterrolebinding ${clusterrolebinding} --type=json --patch "[{'op': 'remove','path': '/subjects/$index'}]";
done

The oc annotate command does not work for LDAP group names that contain an equal sign (=), because the command uses the equal sign as a delimiter between the annotation name and value. As a workaround, use oc patch or oc edit to add the annotation. (BZ#1917280)

In the monitoring stack, if you have enabled and deployed a dedicated Alertmanager instance for user-defined alerts, you cannot silence alerts in the Developer perspective in the OpenShift Container Platform web console. This issue has been fixed in 4.11.8. (BZ#2100860)

On a newly installed OpenShift Container Platform 4.11 cluster, platform monitoring alerts do not have the openshift_io_alert_source="platform" label. This issue does not affect clusters upgraded from a previous minor version. There is currently no workaround exists for this issue. (BZ#2103127)

In the Red Hat OpenStack Platform (RHOSP), a potential issue can affect Kuryr when the ports pools are populated with a variety of bulk port creation requests made at the same time. During these bulk requests, if the IP allocation for one of the IP addresses fails, the Neutron retries the operation for all ports. This issue was resolved in a previous errata; however, you can set a small value for the ports pools batch to avoid large bulk port creation requests. (BZ#2024690)

The oc-mirror CLI plugin cannot mirror OpenShift Container Platform catalogs earlier than version 4.9. (BZ#2097210)

The oc-mirror CLI plugin can fail to upload an image set to the target mirror registry if the archiveSize value in the image set configuration is smaller than the container image size, causing the catalog directory to span multiple archives. (BZ#2106461)

In OpenShift Container Platform 4.11, the MetalLB Operator scope has changed from namespace to cluster and this results in upgrading from a prior version failing.

Deleting the bidirectional forwarding detection (BFD) profile and removing the bfdProfile added to the border gateway protocol (BGP) peer resource does not disable the BFD. Instead, the BGP peer starts using the default BFD profile. To disable BFD from a BGP peer resource, delete the BGP peer configuration and recreate it without a BFD profile. (BZ#2050824)

The OpenShift CLI (oc) for OpenShift Container Platform 4.11 does not work properly on macOS due to a change in error handling of untrusted certificates in Go 1.18 libraries. Due to this change, oc login and other oc commands can fail with a certificate is not trusted error without proceeding further when running on macOS. Until the error handling is properly fixed in Go 1.18 (tracked by Go issue #52010), the workaround is to use the OpenShift Container Platform 4.10 oc CLI instead. Note that when using the OpenShift Container Platform 4.10 oc CLI with an OpenShift Container Platform 4.11 cluster, it is no longer possible to get a token by using the oc serviceaccounts get-token <service_account> command. (BZ#2097830) (BZ#2109799)