Original: (link:https://bugzilla.redhat.com/show_bug.cgi?id=2099991[*BZ#2099991*])
* Previously, instances were not set to respect the GCP infrastructure default option for automated restarts. As a result, instances could be created without using the infrastructure default for automatic restarts. This sometimes meant that instances were terminated in GCP but their associated machines were still listed in the `Running` state because they did not automatically restart. With this release, the code for passing the automatic restart option has been improved to better detect and pass on the default option selection from users. Instances now use the infrastructure default properly and are automatically restarted when the user requests the default functionality. (link:https://issues.redhat.com/browse/OCPBUGS-4504[*OCPBUGS-4504*])
* The `v1beta1` version of the `PodDisruptionBudget` object is now deprecated in Kubernetes. With this release, internal references to `v1beta1` are replaced with `v1`. This change is internal to the cluster autoscaler and does not require user action beyond the advice in the link:https://access.redhat.com/articles/6955381[Preparing to upgrade to OpenShift Container Platform 4.12] Red Hat Knowledgebase Article. (link:https://issues.redhat.com/browse/OCPBUGS-1484[*OCPBUGS-1484*])
* Previously, the GCP machine controller reconciled the state of machines every 10 hours. Other providers set this value to 10 minutes so that changes that happen outside of the Machine API system are detected within a short period. The longer reconciliation period for GCP could cause unexpected issues such as missing certificate signing requests (CSR) approvals due to an external IP address being added but not detected for an extended period. With this release, the GCP machine controller is updated to reconcile every 10 minutes to be consistent with other platforms and so that external changes are picked up sooner. (link:https://issues.redhat.com/browse/OCPBUGS-4499[*OCPBUGS-4499*])
* Previously, due to a deployment misconfiguration for the Cluster Machine Approver Operator, enabling the `TechPreviewNoUpgrade` feature set caused errors and sporadic Operator degradation. Because clusters with the `TechPreviewNoUpgrade` feature set enabled use two instances of the Cluster Machine Approver Operator and both deployments used the same set of ports, there was a conflict that lead to errors for single-node topology. With this release, the Cluster Machine Approver Operator deployment is updated to use a different set of ports for different deployments. (link:https://issues.redhat.com/browse/OCPBUGS-2621[*OCPBUGS-2621*])
* Previously, the scale from zero functionality in Azure relied on a statically compiled list of instance types mapping the name of the instance type to the number of CPUs and the amount of memory allocated to the instance type. This list grew stale over time. With this release, information about instance type sizes is dynamically gathered from the Azure API directly to prevent the list from becoming stale. (link:https://issues.redhat.com/browse/OCPBUGS-2558[*OCPBUGS-2558*])
(link:https://issues.redhat.com/browse/OCPBUGS-1274[*OCPBUGS-1274*])
* Previously, error messages for Azure clusters did not explain that it is not possible to create new machines with public IP addresses for a disconnected install that uses only the internal publish strategy. With this release, the error message is updated for improved clarity. (link:https://issues.redhat.com/browse/OCPBUGS-519[*OCPBUGS-519*])
* Previously, the Cloud Controller Manager Operator did not check the `cloud-config` configuration file for AWS clusters. As a result, it was not possible to pass additional settings to the AWS cloud controller manager component by using the configuration file. With this release, the Cloud Controller Manager Operator checks the infrastructure resource and parses references to the `cloud-config` configuration file so that users can configure additional settings. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2104373[*BZ#2104373*])
* Previously, when Azure added new instance types and enabled accelerated networking support on instance types that previously did not have it, the list of Azure instances in the machine controller became outdated. As a result, the machine controller could not create machines with instance types that did not previously support accelerated networking, even if they support this feature on Azure. With this release, the required instance type information is retrieved from Azure API before the machine is created to keep it up to date so the machine controller is able to create machines with new and updated instance types. This fix also applies to any instance types that are added in the future. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2108647[*BZ#2108647*])
* Previously, the cluster autoscaler did not respect the AWS, IBM Cloud, and Alibaba Cloud topology labels for the CSI drivers when using the Cluster API provider. As a result, nodes with the topology label were not processed properly by the autoscaler when attempting to balance nodes during a scale-out event. With this release, the autoscaler's custom processors are updated so that it respects this label. The autoscaler can now balance similar node groups that are labeled by the AWS, IBM Cloud, or Alibaba CSI labels. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2001027[*BZ#2001027*])
* Previously, Power VS cloud providers were not capable of fetching the machine IP address from a DHCP server. Changing the IP address did not update the node, which caused some inconsistencies, such as pending certificate signing requests. With this release, the Power VS cloud provider is updated to fetch the machine IP address from the DHCP server so that the IP addresses for the nodes are consistent with the machine IP address. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2111474[*BZ#2111474*])
* Previously, machines created in early versions of {product-title} with invalid configurations could not be deleted. With this release, the webhooks that prevent the creation of machines with invalid configurations no longer prevent the deletion of existing invalid machines. Users can now successfully remove these machines from their cluster by manually removing the finalizers on these machines. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2101736[*BZ#2101736*])
* Previously, short DHCP lease times, caused by `NetworkManager` not being run as a daemon or in continuous mode, caused machines to become stuck during initial provisioning and never become nodes in the cluster. With this release, extra checks are added so that if a machine becomes stuck in this state it is deleted and recreated automatically. Machines that are affected by this network condition can become nodes after a reboot from the Machine API controller. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2115090[*BZ#2115090*])
* Previously, when creating a new `Machine` resource using a machine profile that does not exist in IBM Cloud, the machines became stuck in the `Provisioning` phase. With this release, validation is added to the IBM Cloud Machine API provider to ensure that a machine profile exists, and machines with an invalid machine profile are rejected by the Machine API. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2062579[*BZ#2062579*])
* Previously, the Machine API provider for AWS did not verify that the security group defined in the machine specification exists. Instead of returning an error in this case, it used a default security group, which should not be used for {product-title} machines, and successfully created a machine without informing the user that the default group was used. With this release, the Machine API returns an error when users set either incorrect or empty security group names in the machine specification. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2060068[*BZ#2060068*])
* Previously, the Machine API provider Azure did not treated user-provided values for instance types as case sensitive. This led to false-positive errors when instance types were correct but did not match the case. With this release, instance types are converted to the lowercase characters so that users get correct results without false-positive errors for mismatched case. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2085390[*BZ#2085390*])
* Previously, there was no check for nil values in the annotations of a machine object before attempting to access the object. This situation was rare, but caused the machine controller to panic when reconciling the machine. With this release, nil values are checked and the machine controller is able to reconcile machines without annotations. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2106733[*BZ#2106733*])
* Previously, the cluster autoscaler metrics for cluster CPU and memory usage would never reach, or exceed, the limits set by the `ClusterAutoscaler` resource. As a result, no alerts were fired when the cluster autoscaler could not scale due to resource limitations. With this release, a new metric called `cluster_autoscaler_skipped_scale_events_count` is added to the cluster autoscaler to more accurately detect when resource limits are reached or exceeded. Alerts will now fire when the cluster autoscaler is unable to scale the cluster up because it has reached the cluster resource limits. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1997396[*BZ#1997396*])
* Previously, when the Machine API provider failed to fetch the machine IP address, it would not set the internal DNS name and the machine certificate signing requests were not automatically approved. With this release, the Power VS machine provider is updated to set the server name as the internal DNS name even when it fails to fetch the IP address. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2111467[*BZ#2111467*])
* Previously, the Machine API vSphere machine controller set the `PowerOn` flag when cloning a VM. This created a `PowerOn` task that the machine controller was not aware of. If that `PowerOn` task failed, machines were stuck in the `Provisioned` phase but never powered on. With this release, the cloning sequence is altered to avoid the issue. Additionally, the machine controller now retries powering on the VM in case of failure and reports failures properly. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2087981[*BZ#2087981*], link:https://issues.redhat.com/browse/OCPBUGS-954[*OCPBUGS-954*])
* With this release, AWS security groups are tagged immediately instead of after creation. This means that fewer requests are sent to AWS and the required user privileges are lowered. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2098054[*BZ#2098054*], link:https://issues.redhat.com/browse/OCPBUGS-3094[*OCPBUGS-3094*])
* Previously, a bug in the {rh-openstack} legacy cloud provider resulted in a crash if certain {rh-openstack} operations were attempted after authentication had failed. For example, shutting down a server causes the Kubernetes controller manager to fetch server information from {rh-openstack}, which triggered this bug. As a result, if initial cloud authentication failed or was configured incorrectly, shutting down a server caused the Kubernetes controller manager to crash. With this release, the {rh-openstack} legacy cloud provider is updated to not attempt any {rh-openstack} API calls if it has not previously authenticated successfully. Now, shutting down a server with invalid cloud credentials no longer causes Kubernetes controller manager to crash. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2102383[*BZ#2102383*])
* Previously, the `openshift-config` namespace was hard coded for the `HelmChartRepository` custom resource, which was the same namespace for the `ProjectHelmChartRepository` custom resource. This prevented users from adding private `ProjectHelmChartRepository` custom resources in their desired namespace. Consequently, users were unable to access secrets and configmaps in the `openshift-config` namespace. This update fixes the `ProjectHelmChartRepository` custom resource definition with a `namespace` field that can read the secret and configmaps from a namespace of choice by a user with the correct permissions. Additionally, the user can add secrets and configmaps to the accessible namespace, and they can add private Helm chart repositories in the namespace used the creation resources. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2071792[*BZ#2071792*])
* Previously, the image trigger controller did not have permissions to change objects. Consequently, image trigger annotations did not work on some resources. This update creates a cluster role binding that provides the controller the required permissions to update objects according to annotations. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2055620[*BZ#2055620*])
* Previously, the Image Registry Operator did not have a `progressing` condition for the `node-ca` daemon set and used `generation` from an incorrect object. Consequently, the `node-ca` daemon set could be marked as `degraded` while the Operator was still running. This update adds the `progressing` condition, which indicates that the installation is not complete. As a result, the Image Registry Operator successfully installs the `node-ca` daemon set, and the installer waits until it is fully deployed. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2093440[[*BZ#2093440*])
* Previously, the number of supported user-defined tags was 8, and reserved {product-title} tags were 2 for AWS resources. With this release, the number of supported user-defined tags is now 25 and reserved {product-title} tags are 25 for AWS resources. You can now add up to 25 user tags during installation. (link:https://issues.redhat.com/browse/CFE-592[*CFE#592*])
* Previously, installing a cluster on Amazon Web Services started and then failed when the IAM administrative user was not assigned the `s3:GetBucketPolicy` permission. This update adds this policy to checklist that the installation program uses to ensure that all of the required permissions are assigned. As a result, the installation program now stops the installation with a warning that the IAM administrative user is missing the `s3:GetBucketPolicy` permission. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2109388[*BZ#2109388*])
* Previously, installing a cluster on Microsoft Azure failed when the Azure DCasv5-series or DCadsv5-series of confidential VMs were specified as control plane nodes. With this update, the installation program now stops the installation with an error, which states that confidential VMs are not yet supported. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2055247[*BZ#2055247*])
* Previously, gathering bootstrap logs was not possible until the control plane machines were running. With this update, gathering bootstrap logs now only requires that the bootstrap machine be available. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2105341[*BZ#2105341*])
* Previously, if a cluster failed to install on Google Cloud Platform because the service account had insufficient permissions, the resulting error message did not mention this as the cause of the failure. This update improves the error message, which now instructs users to check the permissions that are assigned to the service account. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2103236[*BZ#2103236*])
* Previously, when an installation on Google Cloud provider (GCP) failed because an invalid GCP region was specified, the resulting error message did not mention this as the cause of the failure. This update improves the error message, which now states the region is not valid. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2102324[*BZ#2102324*])
* Previously, cluster installations using Hive could fail if Hive used an older version of the install-config.yaml file. This update allows the installation program to accept older versions of the `install-config.yaml` file provided by Hive. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2098299[*BZ#2098299*])
* Previously, the installation program would incorrectly allow the `apiVIP` and `ingressVIP` parameters to use the same IPv6 address if they represented the address differently, such as listing the address in an abbreviated format. In this update, the installer correctly validates these two parameters regardless of their formatting, requiring separate IP addresses for each parameter. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2103144[*BZ#2103144*])
* Previously, uninstalling a cluster using the installation program failed to delete all resources in clusters installed on GCP if the cluster name was more than 22 characters long. In this update, uninstalling a cluster using the installation program correctly locates and deletes all GCP cluster resources in cases of long cluster names. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2076646[*BZ#2076646*])
* Previously, when installing a cluster on {rh-openstack-first} with multiple networks defined in the `machineNetwork` parameter, the installation program only created security group rules for the first network. With this update, the installation program creates security group rules for all networks defined in the `machineNetwork` so that users no longer need to manually edit security group rules after installation. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2095323[*BZ#2095323*])
* Previously, users could manually set the API and Ingress virtual IP addresses to values that conflicted with the allocation pool of the DHCP server when installing a cluster on OpenStack. This could cause the DHCP server to assign one of the VIP addresses to a new machine, which would fail to start. In this update, the installation program validates the user-provided VIP addresses to ensure that they do not conflict with any DHCP pools. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1944365[*BZ#1944365*])
* Previously, when installing a cluster on vSphere using a datacenter that is embedded inside a folder, the installation program could not locate the datacenter object, causing the installation to fail. In this update, the installation program can traverse the directory that contains the datacenter object, allowing the installation to succeed. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2097691[*BZ#2097691*])
* Previously, when installing a cluster on Azure using arm64 architecture with installer-provisioned infrastructure, the image definition resource for `hyperVGeneration` V1 incorrectly had an architecture value of `x64`. With this update, the image definition resource for `hyperVGeneration` V1 has the correct architecture value of `Arm64`. (link:https://issues.redhat.com/browse/OCPBUGS-3639[*OCPBUGS-3639*])
* Previously, when installing a cluster on VMware vSphere, the installation could fail if the user specified a user-defined folder in the `failureDomain` section of the `install-config.yaml` file. With this update, the installation program correctly validates user-defined folders in the `failureDomain` section of the `install-config.yaml` file. (link:https://issues.redhat.com/browse/OCPBUGS-3343[*OCPBUGS-3343*])
* Previously, when destroying a partially deployed cluster after an installation failed on VMware vSphere, some virtual machine folders were not destroyed. This error could occur in clusters configured with multiple vSphere datacenters or multiple vSphere clusters. With this update, all installer-provisioned infrastructure is correctly deleted when destroying a partially deployed cluster after an installation failure. (link:https://issues.redhat.com/browse/OCPBUGS-1489[*OCPBUGS-1489*])
* Previously, when installing a cluster on VMware vSphere, the installation failed if the user specified the `platform.vsphere.vcenters` parameter but did not specify the `platform.vsphere.failureDomains.topology.networks` parameter in the `install-config.yaml` file. With this update, the installation program alerts the user that the `platform.vsphere.failureDomains.topology.networks` field is required when specifying `platform.vsphere.vcenters`. (link:https://issues.redhat.com/browse/OCPBUGS-1698[*OCPBUGS-1698*])
* Previously, when installing a cluster on VMware vSphere, the installation failed if the user defined the `platform.vsphere.vcenters` and `platform.vsphere.failureDomains` parameters but did not define `platform.vsphere.defaultMachinePlatform.zones`, or `compute.platform.vsphere.zones` and `controlPlane.platform.vsphere.zones`. With this update, the installation program validates that the user has defined the `zones` parameter in multi-region or multi-zone deployments prior to installation. (link:https://issues.redhat.com/browse/OCPBUGS-1490[*OCPBUGS-1490*])
* Previously, the Kubernetes Controller Manager Operator reported `degraded` on environments without a monitoring stack presence. With this update, the Kubernetes Controller Manager Operator skips checking the monitoring for cues about degradation when the monitoring stack is not present. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2118286[*BZ#2118286*])
* With this update, Kubernetes Controller Manager alerts (`KubeControllerManagerDown`, `PodDisruptionBudgetAtLimit`, `PodDisruptionBudgetLimit`, and `GarbageCollectorSyncFailed`) have links to Github  runbooks. The runbooks help users to understand debug these alerts. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2001409[*BZ#2001409*])
* Previously, the secondary scheduler deployment was not deleted after a secondary scheduler custom resource was deleted. Consequently, the Secondary Schedule Operator and Operand were not fully uninstalled. With this update, the correct owner reference is set in the secondary scheduler custom resource so that it points to the secondary scheduler deployment. As a result, secondary scheduler deployments are deleted when the secondary scheduler custom resource is deleted. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2100923[*BZ#2100923*])
* For the {product-title} {product-version} release, the descheduler can now publish events to an API group because the release adds additional role-based access controls (RBAC) rules to the descheduler's profile.(link:https://issues.redhat.com/browse/OCPBUGS-2330[*OCPBUGS-2330*])
* Previously, the Machine Config Operator (MCO) `ControllerConfig` resource, which contains important certificates, was only synced if the Operator's daemon sync succeeded. By design, unready nodes during a daemon sync prevent that daemon sync from succeeding, so unready nodes were indirectly preventing the `ControllerConfig` resource, and therefore those certificates, from syncing. This resulted in eventual cluster degradation when there were unready nodes due to inability to rotate the certificates contained in the `ControllerConfig` resource. With this release, the sync of the `ControllerConfig` resource is no longer dependent on the daemon sync succeeding, so the `ControllerConfig` resource now continues to sync if the daemon sync fails. This means that unready nodes no longer prevent the `ControllerConfig` resource from syncing, so certificates continue to be updated even when there are unready nodes. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2034883[*BZ#2034883*])
* Previously, the *Operator details* page attempted to display multiple error messages, but the error message component can only display a single error message at a time. As a result, relevant error messages were not displayed. With this update, the *Operator details* page displays only the first error message so the user sees a relevant error. (link:https://issues.redhat.com/browse/OCPBUGS-3927[*OCPBUGS-3927*])
* Previously, the product name for Azure Red Hat OpenShift was incorrect in Customer Case Management (CCM). As a result, the console had to use the same incorrect product name to correctly populate the fields in CCM. Once the product name in CCM was updated, the console needed to be updated as well. With this update, the same, correct product name as CCM is correctly populated with the correct Azure product name when following the link from the console. (link:https://issues.redhat.com/browse/OCPBUGS-869[*OCPBUGS-869*])
* Previously, when a plugin page resulted in an error, the error did not reset when navigating away from the error page, and the error persisted after navigating to a page that was not the cause of the error. With this update, the error state is reset to its default when a user navigates to a new page, and the error no longer persists after navigating to a new page. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2117738[*BZ#2117738*], link:https://issues.redhat.com/browse/OCPBUGS-523[*OCPBUGS-523*])
* Previously, the *_View it here_* link in the *Operator details* pane for installed Operators was incorrectly built when *_All Namespaces_* was selected. As a result, the link attempted to navigate to the *Operator details* page for a cluster service version (CSV) in *All Projects*, which is an invalid route. With this update, the *_View it here_* link to use the namespace where the CSV is installed now builds correctly and the link works as expected. (link:https://issues.redhat.com/browse/OCPBUGS-184[*OCPBUGS-184*])
* Previously, line numbers with more than five digits resulted in a cosmetic issue where the line number overlaid the vertical divider between the line number and the line contents making it harder to read. With this update, the amount of space available for line numbers was increased to account for longer line numbers, and the line number no longer overlays the vertical divider. (link:https://issues.redhat.com/browse/OCPBUGS-183[*OCPBUGS-183*])
* Previously, in the administrator perspective of the web console, the link to *_Learn more about the OpenShift local update services_* on the *Default update server* pop-up window in the *Cluster Settings* page produced a 404 error. With this update, the link works as expected. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2098234[*BZ#2098234*])
* Previously, the `MatchExpression` component did not account for array-type values. As a result,  only single values could be entered through forms using this component. With this update, the `MatchExpression` component accepts comma-separated values as an array. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2079690[*BZ#207690*])
* Previously, there were redundant checks for the model resulting in tab reloading which occasionally resulted in a flickering of the tab contents where they rerendered. With this update, the redundant model check was removed, and the model is only checked once. As a result, the tab contents do not flicker and no longer rerender. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2037329[*BZ#2037329*])
* Previously, when selecting the `edit` label from the action list on the OpenShift Dedicated node page, no response was elicited and a web hook error was returned. This issue has been fixed so that the error message is only returned when editing fails. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2102098[*BZ#2102098*])
* Previously, if issues were pending, clicking on the *Insights* link would crash the page. As a workaround, you can wait for the variable to become `initialized` before clicking the *Insights* link. As a result, the Insights page will open as expected. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2052662[*BZ#2052662*])
* Previously, when the `MachineConfigPool` resource was paused, the option to unpause said *Resume rollouts*. The wording has been updated so that it now says *Resume updates*. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2094240[*BZ#2094240*])
* Previously, the wrong calculating method was used when counting master and worker nodes. With this update, the correct worker nodes are calculated when nodes have both the `master` and `worker` role. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1951901[*BZ#1951901*])
* Previously, conflicting `react-router` routes for `ImageManifestVuln` resulted in attempts to render a details page for `ImageManifestVuln` with a `~new` name. Now, the container security plugin has been updated to remove conflicting routes and to ensure dynamic lists and details page extensions are used on the Operator details page. As a result, the console renders the correct create, list, and details pages for `ImageManifestVuln`. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2080260[*BZ#2080260*])
* Previously, incomplete YAML was not synced was occasionally displayed to users. With this update, synced YAML always displays. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2084453[*BZ#2084453*])
* Previously, when installing an Operator that required a custom resource (CR) to be created for use, the *Create resource* button could fail to install the CR because it was pointing to the incorrect namespace. With this update, the *Create resource* button works as expected. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2094502[*BZ#2094502*])
* Previously, the *Cluster update* modal was not displaying errors properly. As a result, the *Cluster update* modal did not display or explain errors when they occurred. With this update, the *Cluster update* modal correctly display errors. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2096350[*BZ#2096350*])
* Before this update, cluster administrators could not distinguish between a pod being not ready because of a scheduling issue and a pod being not ready because it could not be started by the kubelet. In both cases, the `KubePodNotReady` alert would fire. With this update, the `KubePodNotScheduled` alert now fires when a pod is not ready because of a scheduling issue, and the `KubePodNotReady` alert fires when a pod is not ready because it could not be started by the kubelet. (link:https://issues.redhat.com/browse/OCPBUGS-4431[*OCPBUGS-4431*])
* Before this update, `node_exporter` would report metrics about virtual network interfaces such as `tun` interfaces, `br` interfaces, and `ovn-k8s-mp` interfaces. With this update, metrics for these virtual interfaces are no longer collected, which decreases monitoring resource consumption. (link:https://issues.redhat.com/browse/OCPBUGS-1321[*OCPBUGS-1321*])
* Before this update, Alertmanager pod startup might time out because of slow DNS resolution, and the Alertmanager pods would not start. With this release, the timeout value has been increased to seven minutes, which prevents pod startup from timing out. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2083226[*BZ#2083226*])
* Before this update, if Prometheus Operator failed to run or schedule Prometheus pods, the system provided no underlying reason for the failure. With this update, if Prometheus pods are not run or scheduled, the {cmo-full} updates the `clusterOperator` monitoring status with a reason for the failure, which can be used to troubleshoot the underlying issue. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2043518[*BZ#2043518*])
* Before this update, if you created an alert silence from the *Developer* perspective in the {product-title} web console, external labels were included that did not match the alert. Therefore, the alert would not be silenced. With this update, external labels are now excluded when you create a silence in the *Developer* perspective so that newly created silences function as expected. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2084504[*BZ#2084504*])
* Previously, if you enabled an instance of Alertmanager dedicated to user-defined projects, a misconfiguration could occur in certain circumstances, and you would not be informed that the user-defined project Alertmanager config map settings did not load for either the main instance of Alertmanager or the instance dedicated to user-defined projects. With this release, if this misconfiguration occurs, the {cmo-full} now displays a message that informs you of the issue and provides resolution steps. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2099939[*BZ#2099939*])
* Before this update, if the {cmo-first} failed to update Prometheus, the {cmo-short} did not verify whether a previous deployment was running and would report that cluster monitoring was unavailable even if one of the Prometheus pods was still running. With this update, the {cmo-short} now checks for running Prometheus pods in this situation and reports that cluster monitoring is unavailable only if no Prometheus pods are running. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2039411[*BZ#2039411*])
* Before this update, if you configured OpsGenie as an alert receiver, a warning would appear in the log that `api_key` and `api_key_file` are mutually exclusive and that `api_key` takes precedence. This warning appeared even if you had not defined `api_key_file`. With this update, this warning only appears in the log if you have defined both `api_key` and `api_key_file`. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2093892[*BZ#2093892*])
* Before this update the Telemeter Client (TC) only loaded new pull secrets when it was manually restarted. Therefore, if a pull secret had been changed or updated and the TC had not been restarted, the TC would fail to authenticate with the server. This update addresses the issue so that when the secret is rotated, the deployment is automatically restarted and uses the updated token to authenticate. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2114721[*BZ#2114721*])
* Previously, routers that were in the terminating state delayed the `oc cp` command which would delay the `oc adm must-gather` command until the pod was terminated. With this update, a timeout for each issued `oc cp` command is set to prevent delaying the `must-gather` command from running. As a result, terminating pods no longer delay `must-gather` commands. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2103283[*BZ#2103283*])
* Previously, an Ingress Controller could not be configured with both the `Private` endpoint publishing strategy type and PROXY protocol. With this update, users can now configure an Ingress Controller with both the `Private` endpoint publishing strategy type and PROXY protocol. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2104481[*BZ#2104481*])
* Previously, the `routeSelector` parameter cleared the route status of the Ingress Controller prior to the router deployment. Because of this, the route status repopulated incorrectly. To avoid using stale data, route status detection has been updated to no longer rely on the Kubernetes object cache. Additionally, this update includes a fix to check the generation ID on route deployment to determine the route status. As a result, the route status is consistently cleared with a `routeSelector` update. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2101878[*BZ#2101878*])
* Previously, a cluster that was upgraded from a version of {product-title} earlier than 4.8 could have orphaned `Route` objects. This was caused by earlier versions of {product-title} translating `Ingress` objects into `Route` objects irrespective of a given `Ingress` object's indicated `IngressClass`. With this update, an alert is sent to the cluster administrator about any orphaned Route objects still present in the cluster after Ingress-to-Route translation. This update also adds another alert that notifies the cluster administrator about any Ingress objects that do not specify an `IngressClass`. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1962502[*BZ#1962502*])
* Previously, if a `configmap` that the router deployment depends on is not created, then the router deployment does not progress. With this update, the cluster Operator reports `ingress progressing=true` if the default ingress controller deployment is progressing. This results in users debugging issues with the ingress controller by using the command `oc get co`. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2066560[*BZ#2066560*])
* Previously, when an incorrectly created network policy was added to the OVN-Kubernetes cache, it would cause the OVN-Kubernetes leader to enter `crashloopbackoff` status. With this update, OVN-Kubernetes leader does not enter `crashloopbackoff` status by skipping deleting nil policies. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2091238[*BZ#2091238*])
* Previously, recreating an EgressIP pod with the same namespace or name within 60 seconds of deleting an older one with the same namespace or name causes the wrong SNAT to be configured. As a result, packets could go out with nodeIP instead of EgressIP SNAT. With this update, traffic leaves the pod with EgressIP instead of nodeIP. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2097243[*BZ#2097243*]).
* Previously, older Access Control Lists (ACL)s with `arp` produced  `unexpectedly found multiple equivalent ACLs (arp v/s arp||nd)` errors due to a change in the ACL from `arp` to `arp II nd`. This prevented network policies from being created properly. With this update, older ACLs with just the `arp` match have been removed so that only ACLs with the new `arp II nd` match exist so that network policies can be created correctly and no errors will be observed on `ovnkube-master`. NOTE: This effects customers upgrading into 4.8.14, 4.9.32, 4.10.13 or higher from older versions. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2095852[*BZ#2095852*]).
* With this update, CoreDNS has been updated to version 1.10.0, which is based on Kubernetes 1.25. This keeps both the CoreDNS version and {product-title} {product-version}, which is also based on Kubernetes 1.25, in alignment with one another. (link:https://issues.redhat.com/browse/OCPBUGS-1731[*OCPBUGS-1731*])
* With this update, the {product-title} router now uses `k8s.io/client-go` version 1.25.2, which supports Kubernetes 1.25. This keeps both the `openshift-router` and {product-title} {product-version}, which is also based on Kubernetes 1.25, in alignment with one another. (link:https://issues.redhat.com/browse/OCPBUGS-1730[*OCPBUGS-1730*])
* With this update, the Ingress Operator now uses `k8s.io/client-go` version 1.25.2, which supports Kubernetes 1.25. This keeps both the Ingress Operator and {product-title} {product-version}, which is also based on Kubernetes 1.25, in alignment with one another. (link:https://issues.redhat.com/browse/OCPBUGS-1554[*OCPBUGS-1554*])
* Previously, the DNS Operator did not reconcile the `openshift-dns` namespace. Because {product-title} {product-version} requires the `openshift-dns` namespace to have pod-security labels, this caused the namespace to be missing those labels upon cluster update. Without the pod-security labels, the pods failed to start. With this update, the DNS Operator now reconciles the `openshift-dns` namespace, and the pod-security labels are now present. As a result, pods start as expected. (link:https://issues.redhat.com/browse/OCPBUGS-1549[*OCPBUGS-1549*])
* Previously, the `ingresscontroller.spec.tuniningOptions.reloadInterval` did not support decimal numerals as valid parameter values because the Ingress Operator internally converts the specified value into milliseconds, which was not a supported time unit. This prevented an Ingress Controller from being deleted. With this update, `ingresscontroller.spec.tuningOptions.reloadInterval` now supports decimal numerals and users can delete Ingress Controllers with `reloadInterval` parameter values which were previously unsupported. (link:https://issues.redhat.com/browse/OCPBUGS-236[*OCPBUGS-236*])
* Previously, the Cluster DNS Operator used GO Kubernetes libraries that were based on Kubernetes 1.24 while {product-title} 4.12 is based on Kubernetes 1.25. With this update, GO Kubernetes API is v1.25.2, which aligns the Cluster DNS Operator with {product-title} 4.12 that uses Kubernetes 1.25 APIs. (link: https://issues.redhat.com/browse/OCPBUGS-1558[*OCPBUGS-1558*])
* Previously, setting the `disableNetworkDiagnostics` configuration to `true` did not persist when the `network-operator` pod was re-created. With this update, the `disableNetworkDiagnostics` configuration property of network `operator.openshift.io/cluster` no longer resets to its default value after network operator restart. (link:https://issues.redhat.com/browse/OCPBUGS-392[*OCPBUGS-392*])
* Previously, `ovn-kubernetes` did not configure the correct MAC address of bonded interfaces in `br-ex` bridge. As a result, a node that uses bonding for the primary Kubernetes interface fails to join the cluster. With this update, `ovn-kubernetes` configures the correct MAC address of bonded interfaces in `br-ex` bridge, and nodes that use bonding for the primary Kubernetes interface successfully join the cluster. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2096413[*BZ2096413*])
* Previously, when the Ingress Operator was configured to enable the use of mTLS, the Operator would not check if CRLs needed updating until some other event caused it to reconcile. As a result, CRLs used for mTLS could become out of date. With this update, the Ingress Operator now automatically reconciles when any CRL expires, and CRLs will be updated at the time specified by their `nextUpdate` field. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2117524[*BZ#2117524*])
* Previously, a symlinks error message was printed out as raw data instead of formatted as an error, making it difficult to understand. This fix formats the error message properly, so that it is easily understood. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1977660[*BZ#1977660*])
* Previously, kubelet hard eviction thresholds were different from Kubernetes defaults when a performance profile was applied to a node. With this release, the defaults have been updated to match the expected Kubernetes defaults. (link:https://issues.redhat.com/browse/OCPBUGS-4362[*OCPBUGS-4362*]).
* Previously, on macOS arm64 architecture, the `oc` binary needed to be signed manually. As a result, the `oc` binary did not work as expected. This update implements a self-signing binary for `oc` mimicking. As a result, the `oc` binary on macOS arm64 architectures works properly. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2059125[*BZ#2059125*])
* Previously, `must-gather` was trying to collect resources that were not present on the server. Consequently, `must-gather` would print error messages. Now, before collecting resources, `must-gather` checks whether the resource exists. As a result, `must-gather` no longer prints an error when it fails to collect non-existing resources on the server. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2095708[*BZ#2095708*])
* The {product-title} {product-version} release updates the `oc-mirror` library, so that the library supports multi-arch platform images. This means that you can choose from a wider selection of architectures, such as `arm64`, when mirroring a platform release payload. (link:https://issues.redhat.com/browse/OCPBUGS-617[*OCPBUGS-617*])
* Before the {product-title} {product-version} release, the `package-server-manager` controller would not revert any changes made to a `package-server` cluster service version (CSV), because of an issue with the `on-cluster` function. These persistent changes might impact how an Operator starts in a cluster. For {product-title} {product-version}, the `package-server-manager` controller always rebuilds a `package-server` CSV to its original state, so that no modifications to the CSV persist after a cluster upgrade operation. The `on-cluster` function no longer controls the state of a `package-server` CSV. (link:https://issues.redhat.com/browse/OCPBUGS-867[*OCPBUGS-867*])
* Previously, Operator Lifecycle Manager (OLM) would attempt to update namespaces to apply a label, even if the label was present on the namespace. Consequently, the update requests increased the workload in API and etcd services. With this update, OLM compares existing labels against the expected labels on a namespace before issuing an update. As a result, OLM no longer attempts to make unnecessary update requests on namespaces. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2105045[*BZ#2105045*])
* Previously, Operator Lifecycle Manager (OLM) would prevent minor cluster upgrades that should not be blocked based on a miscalculation of the `ClusterVersion` custom resources's `spec.DesiredVersion` field. With this update, OLM no longer prevents cluster upgrades when the upgrade should be supported. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2097557[*BZ#2097557*])
* Previously, the reconciler would update a resource's annotation without making a copy of the resource. This caused an error that would terminate the reconciler process. With this update, the reconciler no longer stops due the error. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2105045[*BZ#2105045*])
* The `package-server-manifest` (PSM) is a controller that ensures that the correct `package-server` Cluster Service Version (CSV) is installed on a cluster. Previously, changes to the `package-server` CSV were not being reverted because of a logical error in the reconcile function in which an on-cluster object could influence the expected object. Users could modify the `package-server` CSV and the changes would not be reverted. Additionally, cluster upgrades would not update the YAML for the `package-server` CSV. With this update, the expected version of the CSV is now always built from scratch, which removes the ability for an on-cluster object to influence the expected values. As a result, the PSM now reverts any attempts to modify the `package-server` CSV, and cluster upgrades now deploy the expected `package-server` CSV. (link:https://issues.redhat.com/browse/OCPBUGS-858[*OCPBUGS-858*])
* Previously, OLM would upgrade an Operator according to the Operator's CRD status. A CRD lists component references in an order defined by the group/version/kind (GVK) identifier. Operators that share the same components might cause the GVK to change the component listings for an Operator, and this can cause the OLM to require more system resources to continuously update the status of a CRD. With this update, the Operator Lifecycle Manager (OLM) now upgrades an Operator according to the Operator's component references. A change to the custom resource definition (CRD) status of an Operator does not impact the OLM Operator upgrade process.(link:https://issues.redhat.com/browse/OCPBUGS-3795[*OCPBUGS-3795*])
* With this update, you can now set the security context for the registry pod by including the `securityContext` configuration field in the pod specification. This will apply the security context for all containers in the pod. The `securityContext` field also defines the pod's privileges. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2091864[*BZ#2091864*])
* Previously, the File Integrity Operator deployed templates using the `openshift-file-integrity` namespace in the permissions for the Operator. When the Operator attempted to create objects in the namespace, it would fail due to permission issues. With this release, the deployment resources used by OLM are updated to use the correct namespace, fixing the permission issues so that users can install and use the operator in non-default namespaces. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2104897[*BZ#2104897*])
* Previously, underlying dependencies of the File Integrity Operator changed how alerts and notifications were handled, and the Operator didn't send metrics as a result. With this release the Operator ensures that the metrics endpoint is correct and reachable on startup. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2115821[*BZ#2115821*])
* Previously, alerts issued by the File Integrity Operator did not set a namespace. This made it difficult to understand where the alert was coming from, or what component was responsible for issuing it. With this release, the Operator includes the namespace it was installed into in the alert, making it easier to narrow down what component needs attention. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2101393[*BZ#2101393*])
* Previously, the File Integrity Operator did not properly handle modifying alerts during an upgrade. As a result, alerts did not include the namespace in which the Operator was installed. With this release, the Operator includes the namespace it was installed into in the alert, making it easier to narrow down what component needs attention. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2112394[*BZ#2112394*])
* Previously, service account ownership for the File Integrity Operator regressed due to underlying OLM updates, and updates from 0.1.24 to 0.1.29 were broken. With this update, the Operator defaults to upgrading to 0.1.30. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2109153[*BZ#2109153*])
* Previously, the File Integrity Operator daemon used the `ClusterRoles` parameter instead of the `Roles` parameter for a recent permission change. As a result, OLM could not update the Operator. With this release, the Operator daemon reverts to using the `Roles` parameter and updates from older versions to version 0.1.29 are successful. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2108475[*BZ#2108475*])
* Previously, the Compliance Operator used an old version of the Operator SDK, which is a dependency for building Operators. This caused alerts about deprecated Kubernetes functionality used by the Operator SDK. With this release, the Compliance Operator is updated to version 0.1.55, which includes an updated version of the Operator SDK. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2098581[*BZ#2098581*])
* Previously, applying automatic remediation for the `rhcos4-high-master-sysctl-kernel-yama-ptrace-scope` and `rhcos4-sysctl-kernel-core-pattern` rules resulted in subsequent failures of those rules in scan results, even though they were remediated. The issue is fixed in this release. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2094382[*BZ#2094382*])
* Previously, the Compliance Operator hard coded notifications to the default namespace. As a result, notifications from the Operator would not appear if the Operator was installed in a different namespace. This issue is fixed in this release. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2060726[*BZ#2060726*])
* Previously, the Compliance Operator failed to fetch API resources when parsing machine configurations without Ignition specifications. This caused the `api-check-pods` check to crash loop. With this release, the Compliance Operator is updated to gracefully handle machine configuration pools without Ignition specifications. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2117268[*BZ#2117268*])
* Previously, the Compliance Operator held machine configurations in a stuck state because it could not determine the relationship between machine configurations and kubelet configurations. This was due to incorrect assumptions about machine configuration names. With this release, the Compliance Operator is able to determine if a kubelet configuration is a subset of a machine configuration. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2102511[*BZ#2102511*])
* Previously, adding a member could remove previous members from a group. As a result, the user lost group privileges. With this release, the dependencies were bumped and users no longer lose group privledges. (link:https://issues.redhat.com/browse/OCPBUGS-533[*OCPBUGS-533*])
* Previously, updating to Podman 4.0 prevented users from using custom images with toolbox containers on {op-system}. This fix updates the toolbox library code to account for the new Podman behavior, so users can now use custom images with toolbox on {op-system} as expected. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2048789[*BZ#2048789*])
* Previously, the `podman exec` command did not work well with nested containers. Users encountered this issue when accessing a node using the `oc debug` command and then running a container with the `toolbox` command. Because of this, users were unable to reuse toolboxes on {op-system}. This fix updates the toolbox library code to account for this behavior, so users can now reuse toolboxes on {op-system}. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1915537[*BZ#1915537*])
* With this update, running the `toolbox` command now checks for updates to the default image before launching the container. This improves security and provides users with the latest bug fixes. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2049591[*BZ#2049591*])
* Previously, updating to Podman 4.0 prevented users from running the `toolbox` command on {op-system}. This fix updates the toolbox library code to account for the new Podman behavior, so users can now run `toolbox` on {op-system} as expected. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2093040[*BZ#2093040*])
* Previously, custom SELinux policy modules were not properly supported by `rpm-ostree`, so they were not updated along with the rest of the system upon update. This would surface as failures in unrelated components. Pending SELinux userspace improvements landing in a future {product-title} release, this update provides a workaround to {op-system} that will rebuild and reload the SELinux policy during boot as needed. (link:https://issues.redhat.com/browse/OCPBUGS-595[*OCPBUGS-595*])
* The tuned profile has been modified to assign the same priority as `ksoftirqd` and `rcuc` to the newly introduced per-CPU kthreads (`ktimers`) added in a recent Red Hat Enterprise Linux (RHEL) kernel patch. For more information, see link:https://issues.redhat.com/browse/OCPBUGS-3475[*OCPBUGS-3475*], link:https://bugzilla.redhat.com/show_bug.cgi?id=2117780[*BZ#2117780*] and link:https://bugzilla.redhat.com/show_bug.cgi?id=2122220[*BZ#2122220*].
Revised: * The tuned profile has been modified to assign the same priority as `ksoftirqd` and `rcuc` to the newly introduced per-CPU kthreads (`ktimers`) added in a recent Red Hat Enterprise Linux (RHEL) kernel patch. For more information, see link:https://issues.redhat.com/browse/OCPBUGS-3475[OCPBUGS-3475], link:https://bugzilla.redhat.com/show_bug.cgi?id=2117780[BZ#2117780], and link:https://bugzilla.redhat.com/show_bug.cgi?id=2122220[BZ#2122220].