diff --git a/release_notes/ocp-4-17-release-notes.adoc b/release_notes/ocp-4-17-release-notes.adoc index edb8d413a2..9e2a31fcf6 100644 --- a/release_notes/ocp-4-17-release-notes.adoc +++ b/release_notes/ocp-4-17-release-notes.adoc @@ -584,13 +584,13 @@ The Insights Operator now gathers more data to detect the following scenarios, w // Engineering reference: OSPRH-5904 * Collects custom resource definitions (CRD) from {rh-openstack}. // Engineering reference: CCXDEV-13001 -* Collects the `haproxy_exporter_server_threshold` metric to detect the problem and remediation reported in link:https://issues.redhat.com/browse/OCPBUGS-36687[*OCPBUGS-36687*]. +* Collects the `haproxy_exporter_server_threshold` metric to detect the problem and remediation reported in link:https://issues.redhat.com/browse/OCPBUGS-36687[OCPBUGS-36687]. // Engineering reference: CCXDEV-12758 * Collects data to detect custom Prometheus Alertmanager instances that are not in the `openshift-monitoring` namespace because they could potentially impact the management of corresponding resources. // Engineering reference: CCXDEV-12503 * Detects the upcoming expiry of the default Ingress Controller expiration certificate, which other applications and services can use to generate recommendations to renew the certificate before the expiry date. // Engineering reference: OCPBUGS-35727 - ** Before this update, the Insights Operator gathered information about all Ingress Controller certificates, including their `NotBefore` and `NotAfter` dates. This data is now compiled into a `JSON` file located at `aggregated/ingress_controllers_certs.json` for easier monitoring of certificate validity across the cluster. (link:https://issues.redhat.com/browse/OCPBUGS-35727[*OCPBUGS-35727*]) + ** Before this update, the Insights Operator gathered information about all Ingress Controller certificates, including their `NotBefore` and `NotAfter` dates. This data is now compiled into a `JSON` file located at `aggregated/ingress_controllers_certs.json` for easier monitoring of certificate validity across the cluster. (link:https://issues.redhat.com/browse/OCPBUGS-35727[OCPBUGS-35727]) [id="ocp-4-17-installation-and-update_{context}"] === Installation and update @@ -1094,7 +1094,7 @@ For information about using the {secrets-store-operator} to mount secrets from G [id="ocp-4-17-network-observability-1-6-2-known-issue_{context}"] ==== Known issue -The 1.6.2 version of the Network Observability Operator fixes a compatibility issue with console plugins that would have prevented Network Observability from being installed on {product-title} 4.17 clusters. By upgrading to version 1.6.2 of the Network Observability Operator, this compatibility issue is resolved, and Network Observability can be installed as expected. (link:https://issues.redhat.com/browse/NETOBSERV-1737[*NETOBSERV-1737*]) +The 1.6.2 version of the Network Observability Operator fixes a compatibility issue with console plugins that would have prevented Network Observability from being installed on {product-title} 4.17 clusters. By upgrading to version 1.6.2 of the Network Observability Operator, this compatibility issue is resolved, and Network Observability can be installed as expected. (link:https://issues.redhat.com/browse/NETOBSERV-1737[NETOBSERV-1737]) //// [id="ocp-4-17-scalability-and-performance_{context}"] @@ -1583,17 +1583,17 @@ For more information, see xref:../installing/installing_aws/ipi/installing-aws-o [id="ocp-4-17-preserveBootstrapIgnition-deprecated_{context}"] ==== The preserveBootstrapIgnition parameter for {aws-short} -The `preserveBootstrapIgnition` parameter for {aws-short} in the `install-config.yaml` file has been deprecated. You can use the `bestEffortDeleteIgnition` parameter instead. (link:https://issues.redhat.com/browse/OCPBUGS-33661[*OCPBUGS-33661*]) +The `preserveBootstrapIgnition` parameter for {aws-short} in the `install-config.yaml` file has been deprecated. You can use the `bestEffortDeleteIgnition` parameter instead. (link:https://issues.redhat.com/browse/OCPBUGS-33661[OCPBUGS-33661]) [id="ocp-4-17-kube-apiserver-deprecated_{context}"] ==== kube-apiserver no longer gets a valid cloud configuration object -In {product-title} {product-version}, `kube-apiserver` no longer gets a valid cloud configuration object. As a result, the `PersistentVolumeLabel` admission plugin rejects in-tree Google Compute Engine (GCE) persistent disk persistent volumes (PD PVs), that do not have the correct topology. (link:https://issues.redhat.com/browse/OCPBUGS-34544[*OCPBUGS-34544*]) +In {product-title} {product-version}, `kube-apiserver` no longer gets a valid cloud configuration object. As a result, the `PersistentVolumeLabel` admission plugin rejects in-tree Google Compute Engine (GCE) persistent disk persistent volumes (PD PVs), that do not have the correct topology. (link:https://issues.redhat.com/browse/OCPBUGS-34544[OCPBUGS-34544]) [id="ocp-4-17-web-console-patternfly_{context}"] ==== kube-apiserver no longer gets a valid cloud configuration object -In {product-title} 4.16, Patternfly 4 and React Router 5 were deprecated. The deprecated static remains the same for {product-title} {product-version}. All plugins should migrate to Patternfly 5 and React Router 6 as soon as possible. (link:https://issues.redhat.com/browse/OCPBUGS-34538[*OCPBUGS-34538*]) +In {product-title} 4.16, Patternfly 4 and React Router 5 were deprecated. The deprecated static remains the same for {product-title} {product-version}. All plugins should migrate to Patternfly 5 and React Router 6 as soon as possible. (link:https://issues.redhat.com/browse/OCPBUGS-34538[OCPBUGS-34538]) [id="ocp-4-17-removed-features_{context}"] === Removed features @@ -1652,75 +1652,75 @@ Starting in {product-title} 4.17, RukPak is now removed and relevant functionali [id="ocp-4-17-bare-metal-hardware-bug-fixes_{context}"] ==== Bare Metal Hardware Provisioning -* Previously, attempting to configure RAID on specific hardware models by using Redfish might have resulted in the following error: `The attribute StorageControllers/Name is missing from the resource`. With this update, the validation logic no longer requires the `Name` field, because the field is not mandated by the Redfish standard. (link:https://issues.redhat.com/browse/OCPBUGS-38465[*OCPBUGS-38465*]) +* Previously, attempting to configure RAID on specific hardware models by using Redfish might have resulted in the following error: `The attribute StorageControllers/Name is missing from the resource`. With this update, the validation logic no longer requires the `Name` field, because the field is not mandated by the Redfish standard. (link:https://issues.redhat.com/browse/OCPBUGS-38465[OCPBUGS-38465]) -* Previously, the management interface for the iDRAC9 Redfish management interface in the Redfish Bare Metal Operator (BMO) module was incorrectly set to iPXE. This caused the error `Could not find the following interface in the ironic.hardware.interfaces.management entrypoint: ipxe` and the deployment failed on Dell Remote Access Controller (iDRAC)-based servers. With this release, the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-37261[*OCPBUGS-37261*]) +* Previously, the management interface for the iDRAC9 Redfish management interface in the Redfish Bare Metal Operator (BMO) module was incorrectly set to iPXE. This caused the error `Could not find the following interface in the ironic.hardware.interfaces.management entrypoint: ipxe` and the deployment failed on Dell Remote Access Controller (iDRAC)-based servers. With this release, the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-37261[OCPBUGS-37261]) [discrete] [id="ocp-4-17-builds-bug-fixes_{context}"] ==== Builds -* Previously, builds could not set the `GIT_LFS_SKIP_SMUDGE` environment variable and use its value when cloning the source code. This caused builds to fail for some Git repositories with LFS files. With this release, the build is able to set this environment variable and use it during the `git clone` step of the build, which resolves the issue. (link:https://issues.redhat.com/browse/OCPBUGS-33215[*OCPBUGS-33215*]) +* Previously, builds could not set the `GIT_LFS_SKIP_SMUDGE` environment variable and use its value when cloning the source code. This caused builds to fail for some Git repositories with LFS files. With this release, the build is able to set this environment variable and use it during the `git clone` step of the build, which resolves the issue. (link:https://issues.redhat.com/browse/OCPBUGS-33215[OCPBUGS-33215]) -* Previously, if the developer or cluster admin used lowercase environment variable names for proxy information, these environment variables were carried into the build output container image. At runtime, the proxy settings were active and had to be unset. With this release, lowercase versions of the `_PROXY` environment variables are prevented from leaking into built container images. Now, `buildDefaults` are only kept during the build and settings created for the build process only are removed before pushing the image in the registry. (link:https://issues.redhat.com/browse/OCPBUGS-12699[*OCPBUGS-12699*]) +* Previously, if the developer or cluster admin used lowercase environment variable names for proxy information, these environment variables were carried into the build output container image. At runtime, the proxy settings were active and had to be unset. With this release, lowercase versions of the `_PROXY` environment variables are prevented from leaking into built container images. Now, `buildDefaults` are only kept during the build and settings created for the build process only are removed before pushing the image in the registry. (link:https://issues.redhat.com/browse/OCPBUGS-12699[OCPBUGS-12699]) [discrete] [id="ocp-4-17-cloud-compute-bug-fixes_{context}"] ==== Cloud Compute -* Previously, a machine controller failed to save the {vmw-full} task ID of an instance template clone operation. This caused the machine to go into the `Provisioning` state and to power off. With this release, the {vmw-full} machine controller can detect and recover from this state. (link:https://issues.redhat.com/browse/OCPBUGS-1735[*OCPBUGS-1735*]) +* Previously, a machine controller failed to save the {vmw-full} task ID of an instance template clone operation. This caused the machine to go into the `Provisioning` state and to power off. With this release, the {vmw-full} machine controller can detect and recover from this state. (link:https://issues.redhat.com/browse/OCPBUGS-1735[OCPBUGS-1735]) -* Previously, the `machine-api` Operator reacted when it deleted a server that was in an `ERROR` state. This happened because the server did not pass a port list. With this release, deleting a machine stuck in an `ERROR` state does not cause an Operator reaction. (link:https://issues.redhat.com/browse/OCPBUGS-33806[*OCPBUGS-33806*]) +* Previously, the `machine-api` Operator reacted when it deleted a server that was in an `ERROR` state. This happened because the server did not pass a port list. With this release, deleting a machine stuck in an `ERROR` state does not cause an Operator reaction. (link:https://issues.redhat.com/browse/OCPBUGS-33806[OCPBUGS-33806]) -* Previously, you could not configure capacity reservation on a {azure-first} Workload Identity cluster because of missing permissions. With this release, the `Microsoft.Compute/capacityReservationGroups/deploy/action` permission is added as a default credential request in the `-openshift-machine-api-azure-cloud-credentials` custom role, so that you can now configure capacity reservation as expected. (link:https://issues.redhat.com/browse/OCPBUGS-37154[*OCPBUGS-37154*]) +* Previously, you could not configure capacity reservation on a {azure-first} Workload Identity cluster because of missing permissions. With this release, the `Microsoft.Compute/capacityReservationGroups/deploy/action` permission is added as a default credential request in the `-openshift-machine-api-azure-cloud-credentials` custom role, so that you can now configure capacity reservation as expected. (link:https://issues.redhat.com/browse/OCPBUGS-37154[OCPBUGS-37154]) -* Previously, an optional internal function of the cluster autoscaler caused repeated log entries when it was not implemented. The issue is resolved in this release. (link:https://issues.redhat.com/browse/OCPBUGS-33592[*OCPBUGS-33592*]) +* Previously, an optional internal function of the cluster autoscaler caused repeated log entries when it was not implemented. The issue is resolved in this release. (link:https://issues.redhat.com/browse/OCPBUGS-33592[OCPBUGS-33592]) -* Previously, a node associated with a restarting machine briefly having a status of `Ready=Unknown` triggered the `UnavailableReplicas` condition in the Control Plane Machine Set Operator. This condition caused the Operator to enter the `Available=False` state and trigger alerts because that state indicates a nonfunctional component that requires immediate administrator intervention. This alert should not have been triggered for the brief and expected unavailabilty during a restart. With this release, a grace period for node unreadiness is added to avoid triggering unnecessary alerts. (link:https://issues.redhat.com/browse/OCPBUGS-20061[*OCPBUGS-20061*]) +* Previously, a node associated with a restarting machine briefly having a status of `Ready=Unknown` triggered the `UnavailableReplicas` condition in the Control Plane Machine Set Operator. This condition caused the Operator to enter the `Available=False` state and trigger alerts because that state indicates a nonfunctional component that requires immediate administrator intervention. This alert should not have been triggered for the brief and expected unavailabilty during a restart. With this release, a grace period for node unreadiness is added to avoid triggering unnecessary alerts. (link:https://issues.redhat.com/browse/OCPBUGS-20061[OCPBUGS-20061]) -* Previously, when an {product-title} cluster was installed with no capabilities and later enabled the Build capability, the related Build cluster configuration custom resource definition (CRD) was not created. With this release, the Build cluster configuration CRD and its default instance are created. This allows the Build capability to be fully configured and customized. (link:https://issues.redhat.com/browse/OCPBUGS-34395[*OCPBUGS-34395*]) +* Previously, when an {product-title} cluster was installed with no capabilities and later enabled the Build capability, the related Build cluster configuration custom resource definition (CRD) was not created. With this release, the Build cluster configuration CRD and its default instance are created. This allows the Build capability to be fully configured and customized. (link:https://issues.redhat.com/browse/OCPBUGS-34395[OCPBUGS-34395]) -* Previously, role bindings related to the Image Registry, Build, and `DeploymentConfig` capabilities were created in every namespace, even if the capabilities were disabled. With this release, role bindings is only created if the capability is enabled on the cluster. (link:https://issues.redhat.com/browse/OCPBUGS-34077[*OCPBUGS-34077*]) +* Previously, role bindings related to the Image Registry, Build, and `DeploymentConfig` capabilities were created in every namespace, even if the capabilities were disabled. With this release, role bindings is only created if the capability is enabled on the cluster. (link:https://issues.redhat.com/browse/OCPBUGS-34077[OCPBUGS-34077]) [discrete] [id="ocp-4-17-cloud-cred-operator-bug-fixes_{context}"] ==== Cloud Credential Operator -* Previously, secrets in the cluster were fetched in a single call. When there was a large number of secrets, the API timed out. With this release, the Cloud Credential Operator fetches secrets in batches limited to 100 secrets. This change prevents timeouts when there is a large number of secrets in the cluster. (link:https://issues.redhat.com/browse/OCPBUGS-41233[*OCPBUGS-41233*]) +* Previously, secrets in the cluster were fetched in a single call. When there was a large number of secrets, the API timed out. With this release, the Cloud Credential Operator fetches secrets in batches limited to 100 secrets. This change prevents timeouts when there is a large number of secrets in the cluster. (link:https://issues.redhat.com/browse/OCPBUGS-41233[OCPBUGS-41233]) -* Previously, the Cloud Credential Operator reported an error when the `awsSTSIAMRoleARN` role was not present on a cluster that used manual mode with AWS Security Token Service. With this release, the Cloud Credential Operator no longer reports this as an error. (link:https://issues.redhat.com/browse/OCPBUGS-33566[*OCPBUGS-33566*]) +* Previously, the Cloud Credential Operator reported an error when the `awsSTSIAMRoleARN` role was not present on a cluster that used manual mode with AWS Security Token Service. With this release, the Cloud Credential Operator no longer reports this as an error. (link:https://issues.redhat.com/browse/OCPBUGS-33566[OCPBUGS-33566]) -* Previously, when checking whether passthrough permissions are sufficient, the Cloud Credential Operator sometimes received a response from the {gcp-first} API that a permission is invalid for a project. This response caused the Operator to become degraded and installation to fail. With this release, the Operator is updated to handle this error gracefully. (link:https://issues.redhat.com/browse/OCPBUGS-36140[*OCPBUGS-36140*]) +* Previously, when checking whether passthrough permissions are sufficient, the Cloud Credential Operator sometimes received a response from the {gcp-first} API that a permission is invalid for a project. This response caused the Operator to become degraded and installation to fail. With this release, the Operator is updated to handle this error gracefully. (link:https://issues.redhat.com/browse/OCPBUGS-36140[OCPBUGS-36140]) [discrete] [id="ocp-4-17-cluster-version-operator-bug-fixes_{context}"] ==== Cluster Version Operator -* Previously, a rarely occurring race condition between Go routines caused the Cluster Version Operator (CVO) to panic after the CVO started. With this release, the Go routines synchronization is improved and the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-32678[*OCPBUGS-32678*]) +* Previously, a rarely occurring race condition between Go routines caused the Cluster Version Operator (CVO) to panic after the CVO started. With this release, the Go routines synchronization is improved and the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-32678[OCPBUGS-32678]) [discrete] [id="ocp-4-17-dev-console-bug-fixes_{context}"] ==== Developer Console -* Previously, on some browsers, some icons in the samples catalog were stretched, making it hard to read. With this update, the icons were resized correctly, and now the icons are no longer stretched and easier to read. (link:https://issues.redhat.com/browse/OCPBUGS-34516[*OCPBUGS-34516*]) +* Previously, on some browsers, some icons in the samples catalog were stretched, making it hard to read. With this update, the icons were resized correctly, and now the icons are no longer stretched and easier to read. (link:https://issues.redhat.com/browse/OCPBUGS-34516[OCPBUGS-34516]) -* Previously, s2i build strategy was not explicitly mentioned in the `func.yml`. Therefore you could not create {ServerlessProductName} functions with the repository. Additionally, error messages were not available if s2i is not mentioned or if `func.yml`. As a result, identifying the reason of failures was not apparent. With this update, if the s2i build strategy is not mentioned, users can still create a function. If it is not s2i, users cannot create a function. The error messages are now different for both the cases. (link:https://issues.redhat.com/browse/OCPBUGS-33733[*OCPBUGS-33733*]) +* Previously, s2i build strategy was not explicitly mentioned in the `func.yml`. Therefore you could not create {ServerlessProductName} functions with the repository. Additionally, error messages were not available if s2i is not mentioned or if `func.yml`. As a result, identifying the reason of failures was not apparent. With this update, if the s2i build strategy is not mentioned, users can still create a function. If it is not s2i, users cannot create a function. The error messages are now different for both the cases. (link:https://issues.redhat.com/browse/OCPBUGS-33733[OCPBUGS-33733]) -* Previously, when using a Quick Start guided tour in the {product-title} web console, it took multiple clicks of the *Next* button to skip to the next step if the `check your work` dialog was ignored. With this update, it only takes one click, regardless of the state of the `check your work` box. (link:https://issues.redhat.com/browse/OCPBUGS-25929[*OCPBUGS-25929*]) +* Previously, when using a Quick Start guided tour in the {product-title} web console, it took multiple clicks of the *Next* button to skip to the next step if the `check your work` dialog was ignored. With this update, it only takes one click, regardless of the state of the `check your work` box. (link:https://issues.redhat.com/browse/OCPBUGS-25929[OCPBUGS-25929]) [discrete] [id="ocp-4-17-driver-toolkit-bug-fixes_{context}"] ==== Driver ToolKit (DTK) -* Previously, DTK incorrectly included the same values for `KERNEL_VERSION` and `RT_KERNEL_VERSION` that exist in the `/etc/driver-toolkit-release.json` configuration file. With this update, the `RT_KERNEL_VERSION` is displayed correctly. (link:https://issues.redhat.com/browse/OCPBUGS-33699[*OCPBUGS-33699*]) +* Previously, DTK incorrectly included the same values for `KERNEL_VERSION` and `RT_KERNEL_VERSION` that exist in the `/etc/driver-toolkit-release.json` configuration file. With this update, the `RT_KERNEL_VERSION` is displayed correctly. (link:https://issues.redhat.com/browse/OCPBUGS-33699[OCPBUGS-33699]) [discrete] [id="ocp-4-17-cloud-etcd-operator-bug-fixes_{context}"] ==== etcd Cluster Operator -* Previous versions of the etcd Operator checked the health of etcd members in serial with an all-member timeout that matched the single-member timeout. As a result, one slow member check could consume the entire timeout and cause later member checks to fail, regardless of the health of that later member. In this release, the etcd Operator checks the health of members in parallel, so the health and speed of one member's check does not affect the other members' checks. (link:https://issues.redhat.com/browse/OCPBUGS-36301[*OCPBUGS-36301*]) +* Previous versions of the etcd Operator checked the health of etcd members in serial with an all-member timeout that matched the single-member timeout. As a result, one slow member check could consume the entire timeout and cause later member checks to fail, regardless of the health of that later member. In this release, the etcd Operator checks the health of members in parallel, so the health and speed of one member's check does not affect the other members' checks. (link:https://issues.redhat.com/browse/OCPBUGS-36301[OCPBUGS-36301]) -* Previously, the health checks for the etcd Operator were not ordered. As a consequence, the health check sometimes failed even though all etcd members were healthy. The health-check failure triggered a scale-down event that caused the Operator to prematurely remove a healthy member. With this release, the health checks in the Operator are ordered. As a result, the health checks correctly reflect the health of etcd members and an incorrect scale-down event does not occur. (link:https://issues.redhat.com/browse/OCPBUGS-36462[*OCPBUGS-36462*]) +* Previously, the health checks for the etcd Operator were not ordered. As a consequence, the health check sometimes failed even though all etcd members were healthy. The health-check failure triggered a scale-down event that caused the Operator to prematurely remove a healthy member. With this release, the health checks in the Operator are ordered. As a result, the health checks correctly reflect the health of etcd members and an incorrect scale-down event does not occur. (link:https://issues.redhat.com/browse/OCPBUGS-36462[OCPBUGS-36462]) [discrete] [id="ocp-hosted-control-planes-bug-fixes_{context}"] @@ -1732,11 +1732,11 @@ To view bug fixes for {hcp} on {product-title} 4.17, see xref:../hosted_control_ [id="ocp-4-17-image-registry-bug-fixes_{context}"] ==== Image Registry -* Previously, the internal image registry would not correctly authenticate users on clusters configured with external OpenID Connect (OIDC) users. Consequently, this made it impossible for users to push or pull images to and from the internal image registry. With this update, the internal image registry starts by using the `SelfSubjectReview` API, dropping use of the `openshift specific user` API, which is not available on clusters configured with external OIDC users. As a result, it is now possible to successfully authenticate with the internal image registry again. (link:https://issues.redhat.com/browse/OCPBUGS-35335[*OCPBUGS-35335*]) +* Previously, the internal image registry would not correctly authenticate users on clusters configured with external OpenID Connect (OIDC) users. Consequently, this made it impossible for users to push or pull images to and from the internal image registry. With this update, the internal image registry starts by using the `SelfSubjectReview` API, dropping use of the `openshift specific user` API, which is not available on clusters configured with external OIDC users. As a result, it is now possible to successfully authenticate with the internal image registry again. (link:https://issues.redhat.com/browse/OCPBUGS-35335[OCPBUGS-35335]) -* Previously, the image registry was unable to run due to a permissions error in the certificate directory. This issue has been resolved. (link:https://issues.redhat.com/browse/OCPBUGS-38885[*OCPBUGS-38885*]) +* Previously, the image registry was unable to run due to a permissions error in the certificate directory. This issue has been resolved. (link:https://issues.redhat.com/browse/OCPBUGS-38885[OCPBUGS-38885]) -* Previously, when enabling `virtualHostedStyle` with `regionEndpoint` set in image registry Operator config, the image registry would ignore the virtual hosted style config and would fail to start. This update fixes the issue by using a new upstream distribution configuration, which is force path style, in favor of the downstream only version, which is virtual hosted style. (link:https://issues.redhat.com/browse/OCPBUGS-32710[*OCPBUGS-32710*]) +* Previously, when enabling `virtualHostedStyle` with `regionEndpoint` set in image registry Operator config, the image registry would ignore the virtual hosted style config and would fail to start. This update fixes the issue by using a new upstream distribution configuration, which is force path style, in favor of the downstream only version, which is virtual hosted style. (link:https://issues.redhat.com/browse/OCPBUGS-32710[OCPBUGS-32710]) * Previously, when {product-title} was deployed on Azure clusters with {entra-short}, storage accounts created for the cluster and the image registry had *Storage Account Key Access* enabled by default, which could pose security risks to the deployment. + @@ -1749,95 +1749,95 @@ Shared access keys should only be disabled if the cluster is configured to use { + For existing storage accounts created before this update, shared access keys are not automatically disabled. Administrators must manually disable shared access key support on these storage accounts to prevent the use of shared keys. For more information about disabling shared access keys, see link:https://learn.microsoft.com/en-us/azure/storage/common/shared-key-authorization-prevent?tabs=portal[Prevent Shared Key authorization for an Azure Storage account]. + -link:https://issues.redhat.com/browse/OCPBUGS-39428[(*OCPBUGS-39428*)] +link:https://issues.redhat.com/browse/OCPBUGS-39428[OCPBUGS-39428] [discrete] [id="ocp-4-17-installer-bug-fixes_{context}"] ==== Installer -* Previously, extracting the IP address from the Cluster API Machine object only returned a single address. On {vmw-first}, the returned address would always be an IPv6 address and this caused issues with the `must-gather` implementation if the address was non-routable. With this release, the Cluster API Machine object returns all IP addresses, including IPv4, so that the `must-gather` issue no longer occurs on {vmw-full}. (link:https://issues.redhat.com/browse/OCPBUGS-37427[*OCPBUGS-37427*]) +* Previously, extracting the IP address from the Cluster API Machine object only returned a single address. On {vmw-first}, the returned address would always be an IPv6 address and this caused issues with the `must-gather` implementation if the address was non-routable. With this release, the Cluster API Machine object returns all IP addresses, including IPv4, so that the `must-gather` issue no longer occurs on {vmw-full}. (link:https://issues.redhat.com/browse/OCPBUGS-37427[OCPBUGS-37427]) -* Previously, when installing a cluster on {ibm-cloud-name} into an existing VPC, the installation program retrieved an unsupported VPC region. Attempting to install into a supported VPC region that follows the unsupported VPC region alphabetically caused the installation program to crash. With this release, the installation program is updated to ignore any VPC regions that are not fully available during resource lookups. (link:https://issues.redhat.com/browse/OCPBUGS-14963[*OCPBUGS-14963*]) +* Previously, when installing a cluster on {ibm-cloud-name} into an existing VPC, the installation program retrieved an unsupported VPC region. Attempting to install into a supported VPC region that follows the unsupported VPC region alphabetically caused the installation program to crash. With this release, the installation program is updated to ignore any VPC regions that are not fully available during resource lookups. (link:https://issues.redhat.com/browse/OCPBUGS-14963[OCPBUGS-14963]) -* Previously, the installation program attempted to download the OVA on {vmw-first} whether the template field was defined or not. With this update, the issue is resolved. The installation program verifies if the template field is defined. If the template field is not defined, the OVA is downloaded. If the template field is defined, the OVA is not downloaded. (link:https://issues.redhat.com/browse/OCPBUGS-39240[*OCPBUGS-39240*]) +* Previously, the installation program attempted to download the OVA on {vmw-first} whether the template field was defined or not. With this update, the issue is resolved. The installation program verifies if the template field is defined. If the template field is not defined, the OVA is downloaded. If the template field is defined, the OVA is not downloaded. (link:https://issues.redhat.com/browse/OCPBUGS-39240[OCPBUGS-39240]) -* Previously, enabling custom feature gates sometimes caused installation on an AWS cluster to fail if the feature gate `ClusterAPIInstallAWS=true` was not enabled. With this release, the `ClusterAPIInstallAWS=true` feature gate is not required. (link:https://issues.redhat.com/browse/OCPBUGS-34708[*OCPBUGS-34708*]) +* Previously, enabling custom feature gates sometimes caused installation on an AWS cluster to fail if the feature gate `ClusterAPIInstallAWS=true` was not enabled. With this release, the `ClusterAPIInstallAWS=true` feature gate is not required. (link:https://issues.redhat.com/browse/OCPBUGS-34708[OCPBUGS-34708]) -* Previously, some processes could be left running if the installation program exited due to infrastructure provisioning failures. With this update, all installation-related processes are terminated when the installation program terminates. (link:https://issues.redhat.com/browse/OCPBUGS-36378[*OCPBUGS-36378*]) +* Previously, some processes could be left running if the installation program exited due to infrastructure provisioning failures. With this update, all installation-related processes are terminated when the installation program terminates. (link:https://issues.redhat.com/browse/OCPBUGS-36378[OCPBUGS-36378]) -* Previously, the installation program required permission to create and delete IAM roles when installing a cluster on {aws-short} even when an existing IAM role was provided. With this update, the installation program only requires these permissions when it is creating IAM roles. (link:https://issues.redhat.com/browse/OCPBUGS-36390[*OCPBUGS-36390*]) +* Previously, the installation program required permission to create and delete IAM roles when installing a cluster on {aws-short} even when an existing IAM role was provided. With this update, the installation program only requires these permissions when it is creating IAM roles. (link:https://issues.redhat.com/browse/OCPBUGS-36390[OCPBUGS-36390]) -* Previously, long cluster names were trimmed without warning the user. With this update, the installation program warns the user when trimming long cluster names. (link:https://issues.redhat.com/browse/OCPBUGS-33840[*OCPBUGS-33840*]) +* Previously, long cluster names were trimmed without warning the user. With this update, the installation program warns the user when trimming long cluster names. (link:https://issues.redhat.com/browse/OCPBUGS-33840[OCPBUGS-33840]) -* Previously, the `openshift-install` CLI sometimes failed to connect to the bootstrap node when collecting bootstrap gather logs. The installation program reported an error message such as `The bootstrap machine did not execute the release-image.service systemd unit`. With this release and after the bootstrap gather logs issue occurs, the installation program now reports `Invalid log bundle or the bootstrap machine could not be reached and bootstrap logs were not collected`, which is a more accurate error message. (link:https://issues.redhat.com/browse/OCPBUGS-34953[*OCPBUGS-34953*]) +* Previously, the `openshift-install` CLI sometimes failed to connect to the bootstrap node when collecting bootstrap gather logs. The installation program reported an error message such as `The bootstrap machine did not execute the release-image.service systemd unit`. With this release and after the bootstrap gather logs issue occurs, the installation program now reports `Invalid log bundle or the bootstrap machine could not be reached and bootstrap logs were not collected`, which is a more accurate error message. (link:https://issues.redhat.com/browse/OCPBUGS-34953[OCPBUGS-34953]) -* Previously, when installing a cluster on {aws-short}, subnets that the installation program created were incorrectly tagged with the `kubernetes.io/cluster/: shared` tag. With this update, these subnets are correctly tagged with the `kubernetes.io/cluster/: owned` tag. (link:https://issues.redhat.com/browse/OCPBUGS-36904[*OCPBUGS-36904*]) +* Previously, when installing a cluster on {aws-short}, subnets that the installation program created were incorrectly tagged with the `kubernetes.io/cluster/: shared` tag. With this update, these subnets are correctly tagged with the `kubernetes.io/cluster/: owned` tag. (link:https://issues.redhat.com/browse/OCPBUGS-36904[OCPBUGS-36904]) -* Previously, the local etcd data store that is saved during installation was not deleted if the installation failed, consuming extra space on the installation host. With this update, the data store is deleted if infrastructure provisioning failures prevent a successful installation. (link:https://issues.redhat.com/browse/OCPBUGS-36284[*OCPBUGS-36284*]) +* Previously, the local etcd data store that is saved during installation was not deleted if the installation failed, consuming extra space on the installation host. With this update, the data store is deleted if infrastructure provisioning failures prevent a successful installation. (link:https://issues.redhat.com/browse/OCPBUGS-36284[OCPBUGS-36284]) -* Previously, when a folder was undefined and the data center was located in a data center folder, an wrong folder structure was created starting from the root of the vCenter server. By using the Govmomi `DatacenterFolders.VmFolder`, it used the a wrong path. With this release, the folder structure uses the data center inventory path and joins it with the virtual machine (VM) and cluster ID value, and the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-38616[*OCPBUGS-38616*]) +* Previously, when a folder was undefined and the data center was located in a data center folder, an wrong folder structure was created starting from the root of the vCenter server. By using the Govmomi `DatacenterFolders.VmFolder`, it used the a wrong path. With this release, the folder structure uses the data center inventory path and joins it with the virtual machine (VM) and cluster ID value, and the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-38616[OCPBUGS-38616]) -* Previously, when templates are defined for each failure domain, the installation program required an external connection to download the OVA in {vmw-full}. With this release, the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-39239[*OCPBUGS-39239*]) +* Previously, when templates are defined for each failure domain, the installation program required an external connection to download the OVA in {vmw-full}. With this release, the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-39239[OCPBUGS-39239]) -* Previously, installing a cluster with a Dynamic Host Configuration Protocol (DHCP) network on Nutanix caused a failure. With this release, this issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-38934[*OCPBUGS-38934*]) +* Previously, installing a cluster with a Dynamic Host Configuration Protocol (DHCP) network on Nutanix caused a failure. With this release, this issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-38934[OCPBUGS-38934]) -* Previously, due to an EFI Secure Boot failure in the SCOS, when the FCOS pivoted to the SCOS the virtual machine (VM) failed to boot. With this release, the Secure Boot is disabled only when the Secure Boot is enabled in the `coreos.ovf` configuration file, and the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-37736[*OCPBUGS-37736*]) +* Previously, due to an EFI Secure Boot failure in the SCOS, when the FCOS pivoted to the SCOS the virtual machine (VM) failed to boot. With this release, the Secure Boot is disabled only when the Secure Boot is enabled in the `coreos.ovf` configuration file, and the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-37736[OCPBUGS-37736]) -* Previously, if you specified an unsupported architecture in the `install-config.yaml` file the installation program would fail with a `connection refused` message. With this update, the installation program correctly validates the cluster architecture parameter, leading to successful installations. (link:https://issues.redhat.com/browse/OCPBUGS-38841[*OCPBUGS-38841*]) +* Previously, if you specified an unsupported architecture in the `install-config.yaml` file the installation program would fail with a `connection refused` message. With this update, the installation program correctly validates the cluster architecture parameter, leading to successful installations. (link:https://issues.redhat.com/browse/OCPBUGS-38841[OCPBUGS-38841]) -* Previously, a rare condition om {vmw-full} Cluster API machines caused the vCenter session management to time out unexpectedly. With this release, the Keep Alive support is disabled in the current and later versions of CAPV, and the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-38677[*OCPBUGS-38677*]) +* Previously, a rare condition om {vmw-full} Cluster API machines caused the vCenter session management to time out unexpectedly. With this release, the Keep Alive support is disabled in the current and later versions of CAPV, and the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-38677[OCPBUGS-38677]) -* Previously, the installation program on {aws-first} used multiple IPv4 public IP addresses that Amazon has started charging for. With this release, support is provided for bring your own (BYO) public IPv4 pools in {product-title} so that users have control of IP addresses that are used by their services. Where the BYO public IPv4 pools feature is enabled, two new permissions, `ec2:DescribePublicIpv4Pools` and `ec2:DisassociateAddress`, are required, and the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-35504[*OCPBUGS-35504*]) +* Previously, the installation program on {aws-first} used multiple IPv4 public IP addresses that Amazon has started charging for. With this release, support is provided for bring your own (BYO) public IPv4 pools in {product-title} so that users have control of IP addresses that are used by their services. Where the BYO public IPv4 pools feature is enabled, two new permissions, `ec2:DescribePublicIpv4Pools` and `ec2:DisassociateAddress`, are required, and the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-35504[OCPBUGS-35504]) -* Previously, when users provided public subnets while using existing subnets and creating a private cluster, the installation program occasionally exposed on the public internet the load balancers that were created in public subnets. This invalidated the reason for a private cluster. With this release, the issue is resolved by displaying a warning during a private installation that providing public subnets might break the private clusters and, to prevent this, users must fix their inputs. (link:https://issues.redhat.com/browse/OCPBUGS-38963[*OCPBUGS-38963*]) +* Previously, when users provided public subnets while using existing subnets and creating a private cluster, the installation program occasionally exposed on the public internet the load balancers that were created in public subnets. This invalidated the reason for a private cluster. With this release, the issue is resolved by displaying a warning during a private installation that providing public subnets might break the private clusters and, to prevent this, users must fix their inputs. (link:https://issues.redhat.com/browse/OCPBUGS-38963[OCPBUGS-38963]) -* Previously, during installation the `oc adm node-image create` command used the kube-system/cluster-config-v1 resource to determine the platform type. With this release, the installation program uses the infrastructure resource, which provides more accurate information about the platform type. (link:https://issues.redhat.com/browse/OCPBUGS-39092[*OCPBUGS-39092*]) +* Previously, during installation the `oc adm node-image create` command used the kube-system/cluster-config-v1 resource to determine the platform type. With this release, the installation program uses the infrastructure resource, which provides more accurate information about the platform type. (link:https://issues.redhat.com/browse/OCPBUGS-39092[OCPBUGS-39092]) -* Previously, the `oc adm node-image create` command failed when run against a cluster in a restricted environment with a proxy because the command ignored the cluster-wide proxy setting. With this release, when the command is run it checks the cluster proxy resource settings, where available, to ensure the command is run successfully and the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-39090[*OCPBUGS-39090*]) +* Previously, the `oc adm node-image create` command failed when run against a cluster in a restricted environment with a proxy because the command ignored the cluster-wide proxy setting. With this release, when the command is run it checks the cluster proxy resource settings, where available, to ensure the command is run successfully and the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-39090[OCPBUGS-39090]) -* Previously, when installing a cluster with the Agent-based installer, the assisted-installer process could timeout when attempting to add control plane nodes to the cluster. With this update, the assisted-installer process loads fresh data from the assisted-service process, preventing the timeout. (link:https://issues.redhat.com/browse/OCPBUGS-36779[*OCPBUGS-36779*]) +* Previously, when installing a cluster with the Agent-based installer, the assisted-installer process could timeout when attempting to add control plane nodes to the cluster. With this update, the assisted-installer process loads fresh data from the assisted-service process, preventing the timeout. (link:https://issues.redhat.com/browse/OCPBUGS-36779[OCPBUGS-36779]) -* Previously, when the {vmw-full} vCenter cluster contained an ESXi host that did not have a standard port group defined and the installation program tried to select that host to import the OVA, the import failed and the error `Invalid Configuration for device 0` was reported. With this release, the installation program verifies whether a standard port group for an ESXi host is defined and, if not, continues until it locates an ESXi host with a defined standard port group, or reports an error message if it fails to locate one, resolving the issue. (link:https://issues.redhat.com/browse/OCPBUGS-38560[*OCPBUGS-38560*]) +* Previously, when the {vmw-full} vCenter cluster contained an ESXi host that did not have a standard port group defined and the installation program tried to select that host to import the OVA, the import failed and the error `Invalid Configuration for device 0` was reported. With this release, the installation program verifies whether a standard port group for an ESXi host is defined and, if not, continues until it locates an ESXi host with a defined standard port group, or reports an error message if it fails to locate one, resolving the issue. (link:https://issues.redhat.com/browse/OCPBUGS-38560[OCPBUGS-38560]) -* Previously, extracting the IP address from the Cluster API Machine object only returned a single IP address. On {vmw-first}, the returned address would always be an IPv6 address and this caused issues with the `must-gather` implementation if the address was non-routable. With this release, the Cluster API Machine object returns all IP addresses, including IPv4, so that the `must-gather` issue no longer occurs on {vmw-full}. (link:https://issues.redhat.com/browse/OCPBUGS-37607[*OCPBUGS-37607*]) +* Previously, extracting the IP address from the Cluster API Machine object only returned a single IP address. On {vmw-first}, the returned address would always be an IPv6 address and this caused issues with the `must-gather` implementation if the address was non-routable. With this release, the Cluster API Machine object returns all IP addresses, including IPv4, so that the `must-gather` issue no longer occurs on {vmw-full}. (link:https://issues.redhat.com/browse/OCPBUGS-37607[OCPBUGS-37607]) -* Previously, when installing a cluster on {aws-short}, Elastic Kubernetes Service (EKS) messages could appear in the installation logs even when EKS was meant to be disabled. With this update, EKS log messages have been disabled. (link:https://issues.redhat.com/browse/OCPBUGS-35752[*OCPBUGS-35752*]) +* Previously, when installing a cluster on {aws-short}, Elastic Kubernetes Service (EKS) messages could appear in the installation logs even when EKS was meant to be disabled. With this update, EKS log messages have been disabled. (link:https://issues.redhat.com/browse/OCPBUGS-35752[OCPBUGS-35752]) -* Previously, unexpected output would appear in the terminal when creating an installer-provisioned infrastructure cluster. With this release, the issue has been resolved and the unexpected output no longer shows. (link:https://issues.redhat.com/browse/OCPBUGS-35547[*OCPBUGS-35547*]) +* Previously, unexpected output would appear in the terminal when creating an installer-provisioned infrastructure cluster. With this release, the issue has been resolved and the unexpected output no longer shows. (link:https://issues.redhat.com/browse/OCPBUGS-35547[OCPBUGS-35547]) -* Previously, when installing a cluster on {aws-short} after deleting a cluster with the `./openshift-install destroy cluster` command, the installation would fail with an error stating that there might already be a running cluster. With this update, all leftover artifacts are removed when the cluster is destroyed, resulting in successful installations afterwards. (link:https://issues.redhat.com/browse/OCPBUGS-35542[*OCPBUGS-35542*]) +* Previously, when installing a cluster on {aws-short} after deleting a cluster with the `./openshift-install destroy cluster` command, the installation would fail with an error stating that there might already be a running cluster. With this update, all leftover artifacts are removed when the cluster is destroyed, resulting in successful installations afterwards. (link:https://issues.redhat.com/browse/OCPBUGS-35542[OCPBUGS-35542]) -* Previously, when installing a cluster on {aws-short}, load balancer ingress rules were continuously revoked and re-authorized, causing unnecessary API calls and delays in cluster provisioning. With this update, load balancer ingress rules are no longer revoked during installation, reducing API traffic and installation delays. (link:https://issues.redhat.com/browse/OCPBUGS-35440[*OCPBUGS-35440*]) +* Previously, when installing a cluster on {aws-short}, load balancer ingress rules were continuously revoked and re-authorized, causing unnecessary API calls and delays in cluster provisioning. With this update, load balancer ingress rules are no longer revoked during installation, reducing API traffic and installation delays. (link:https://issues.redhat.com/browse/OCPBUGS-35440[OCPBUGS-35440]) -* Previously, when setting `platform.openstack.controlPlanePort.network` without a `fixedIPs` value, the installation program would output a misleading error message about the network missing subnets. With this release, the installation program validates that the `install-config` field `controlPlanePort` has a valid subnet filter set because it is a required value. (link:https://issues.redhat.com/browse/OCPBUGS-37104[*OCPBUGS-37104*]) +* Previously, when setting `platform.openstack.controlPlanePort.network` without a `fixedIPs` value, the installation program would output a misleading error message about the network missing subnets. With this release, the installation program validates that the `install-config` field `controlPlanePort` has a valid subnet filter set because it is a required value. (link:https://issues.redhat.com/browse/OCPBUGS-37104[OCPBUGS-37104]) -* Previously, adding IPv6 support for user-provisioned installation platforms caused an issue with naming {rh-openstack-first} resources, especially when you run two user-provisioned installation clusters on the same {rh-openstack-first} platform. This happened because the two clusters share the same names for network, subnets, and router resources. With this release, all the resources names for a cluster remain unique for that cluster so no interfere occurs. (link:https://issues.redhat.com/browse/OCPBUGS-33973[*OCPBUGS-33973*]) +* Previously, adding IPv6 support for user-provisioned installation platforms caused an issue with naming {rh-openstack-first} resources, especially when you run two user-provisioned installation clusters on the same {rh-openstack-first} platform. This happened because the two clusters share the same names for network, subnets, and router resources. With this release, all the resources names for a cluster remain unique for that cluster so no interfere occurs. (link:https://issues.redhat.com/browse/OCPBUGS-33973[OCPBUGS-33973]) -* Previously, when installing a cluster on {ibm-power-server-name} with installer-provisioned infrastructure, the installation could fail due to load balancer timeouts. With this update, the installation program waits for the load balancer to be available instead of timing out. (link:https://issues.redhat.com/browse/OCPBUGS-34869[*OCPBUGS-34869*]) +* Previously, when installing a cluster on {ibm-power-server-name} with installer-provisioned infrastructure, the installation could fail due to load balancer timeouts. With this update, the installation program waits for the load balancer to be available instead of timing out. (link:https://issues.redhat.com/browse/OCPBUGS-34869[OCPBUGS-34869]) -* Previously, when using the Assisted Installer, using a password that contained the colon character (`:`) resulted in a failed installation. With this update, pull secrets containing a colon in the password do not cause the Assisted Installer to fail. (link:https://issues.redhat.com/browse/OCPBUGS-31727[*OCPBUGS-31727*]) +* Previously, when using the Assisted Installer, using a password that contained the colon character (`:`) resulted in a failed installation. With this update, pull secrets containing a colon in the password do not cause the Assisted Installer to fail. (link:https://issues.redhat.com/browse/OCPBUGS-31727[OCPBUGS-31727]) -* Previously, solid state drives (SSD) that used SATA hardware were identified as removable. The Assisted Installer for {product-title} reported that no eligible disks were found and the installation stopped. With this release, removable disks are eligible for installation. (link:https://issues.redhat.com/browse/OCPBUGS-33404[*OCPBUGS-33404*]) +* Previously, solid state drives (SSD) that used SATA hardware were identified as removable. The Assisted Installer for {product-title} reported that no eligible disks were found and the installation stopped. With this release, removable disks are eligible for installation. (link:https://issues.redhat.com/browse/OCPBUGS-33404[OCPBUGS-33404]) -* Previously, when installing a cluster on bare metal using installer provisioned infrastructure, the installation could time out if the network to the bootstrap virtual machine is slow. With this update, the timeout duration has been increased to cover a wider range of network performance scenarios. (link:https://issues.redhat.com/browse/OCPBUGS-41500[*OCPBUGS-41500*]) +* Previously, when installing a cluster on bare metal using installer provisioned infrastructure, the installation could time out if the network to the bootstrap virtual machine is slow. With this update, the timeout duration has been increased to cover a wider range of network performance scenarios. (link:https://issues.redhat.com/browse/OCPBUGS-41500[OCPBUGS-41500]) -* Previously, when installing a cluster on {ibm-power-server-name}, the installation program did not list the `e980` system type in the `madrid` region. With this update, the installation program correctly lists this region. (link:https://issues.redhat.com/browse/OCPBUGS-38439[*OCPBUGS-38439*]) +* Previously, when installing a cluster on {ibm-power-server-name}, the installation program did not list the `e980` system type in the `madrid` region. With this update, the installation program correctly lists this region. (link:https://issues.redhat.com/browse/OCPBUGS-38439[OCPBUGS-38439]) -* Previously, after installing a {sno} cluster, the monitoring system could produce an alert that applied to clusters with multiple nodes. With this update, {sno} clusters only produce monitoring alerts that apply to {sno} clusters. (link:https://issues.redhat.com/browse/OCPBUGS-35833[*OCPBUGS-35833*]) +* Previously, after installing a {sno} cluster, the monitoring system could produce an alert that applied to clusters with multiple nodes. With this update, {sno} clusters only produce monitoring alerts that apply to {sno} clusters. (link:https://issues.redhat.com/browse/OCPBUGS-35833[OCPBUGS-35833]) -* Previously, when installing a cluster on {ibm-power-server-name}, the installation could fail due to a DHCP server network collision. With this update, the installation program selects a random number to generate the DHCP network to avoid collision. (link:https://issues.redhat.com/browse/OCPBUGS-33912[*OCPBUGS-33912*]) +* Previously, when installing a cluster on {ibm-power-server-name}, the installation could fail due to a DHCP server network collision. With this update, the installation program selects a random number to generate the DHCP network to avoid collision. (link:https://issues.redhat.com/browse/OCPBUGS-33912[OCPBUGS-33912]) -* Previously, the installation program used the Neutron API endpoint to tag security groups. This API does not support special characters, so some {rh-openstack-first} clusters failed to install on {rh-openstack}. With this release, the installation program uses an alternative endpoint to tag security groups so that the issue no longer persists. (link:https://issues.redhat.com/browse/OCPBUGS-36913[*OCPBUGS-36913*]) +* Previously, the installation program used the Neutron API endpoint to tag security groups. This API does not support special characters, so some {rh-openstack-first} clusters failed to install on {rh-openstack}. With this release, the installation program uses an alternative endpoint to tag security groups so that the issue no longer persists. (link:https://issues.redhat.com/browse/OCPBUGS-36913[OCPBUGS-36913]) -* Previously, setting an invalid Universally Unique Identifier (UUID) for the `additionalNetworkIDs` parameter of a machine pool in your `install-config` configuration file could result in the installation program exiting from installing the cluster. With this release, the installation program checks the validity of the `additionalNetworkIDs` parameter before the program continuing with installing the cluster so that this issue no longer persists. (link:https://issues.redhat.com/browse/OCPBUGS-35420[*OCPBUGS-35420*]) +* Previously, setting an invalid Universally Unique Identifier (UUID) for the `additionalNetworkIDs` parameter of a machine pool in your `install-config` configuration file could result in the installation program exiting from installing the cluster. With this release, the installation program checks the validity of the `additionalNetworkIDs` parameter before the program continuing with installing the cluster so that this issue no longer persists. (link:https://issues.redhat.com/browse/OCPBUGS-35420[OCPBUGS-35420]) -* Previously, for {ibm-power-server-name} installer-provisioned infrastructure clusters, if no network name existed for a Dynamic Host Configuration Protocol (DHCP), the destroy code would skip deleting the DHCP resource. With this release, a test now checks if a DHCP is in an `ERROR` state, so that the DHCP resource is deleted. (link:https://issues.redhat.com/browse/OCPBUGS-35039[*OCPBUGS-35039*]) +* Previously, for {ibm-power-server-name} installer-provisioned infrastructure clusters, if no network name existed for a Dynamic Host Configuration Protocol (DHCP), the destroy code would skip deleting the DHCP resource. With this release, a test now checks if a DHCP is in an `ERROR` state, so that the DHCP resource is deleted. (link:https://issues.redhat.com/browse/OCPBUGS-35039[OCPBUGS-35039]) [discrete] [id="ocp-4-17-insights-operator-bug-fixes_{context}"] ==== Insights Operator -* Previously, in some Hypershift hosted clusters, the IO archive contained the hostname even with network obfuscation enabled. This issue has been resolved, and IO archives no longer contain hostnames when they are obfuscated. (link:https://issues.redhat.com/browse/OCPBUGS-33082[*OCPBUGS-33082*]) +* Previously, in some Hypershift hosted clusters, the IO archive contained the hostname even with network obfuscation enabled. This issue has been resolved, and IO archives no longer contain hostnames when they are obfuscated. (link:https://issues.redhat.com/browse/OCPBUGS-33082[OCPBUGS-33082]) //// [discrete] @@ -1853,63 +1853,63 @@ link:https://issues.redhat.com/browse/OCPBUGS-39428[(*OCPBUGS-39428*)] [id="ocp-4-17-machine-config-operator-bug-fixes_{context}"] ==== Machine Config Operator -* Previously, in a cluster that runs {product-title} 4.16 with the Telco RAN DU reference configuration, long duration `cyclictest` or `timerlat` tests could fail with maximum latencies detected above `20` us. This issue occured because the `psi` kernel command line argument was being set to `1` by default when cgroup v2 is enabled. With this release, the issue is fixed by setting `psi=0` in the kernel arguments when enabling cgroup v2. The `cyclictest` latency issue reported in link:https://issues.redhat.com/browse/OCPBUGS-34022[*OCPBUGS-34022*] is now also fixed. (link:https://issues.redhat.com/browse/OCPBUGS-37271[*OCPBUGS-37271*]) +* Previously, in a cluster that runs {product-title} 4.16 with the Telco RAN DU reference configuration, long duration `cyclictest` or `timerlat` tests could fail with maximum latencies detected above `20` us. This issue occured because the `psi` kernel command line argument was being set to `1` by default when cgroup v2 is enabled. With this release, the issue is fixed by setting `psi=0` in the kernel arguments when enabling cgroup v2. The `cyclictest` latency issue reported in link:https://issues.redhat.com/browse/OCPBUGS-34022[OCPBUGS-34022] is now also fixed. (link:https://issues.redhat.com/browse/OCPBUGS-37271[OCPBUGS-37271]) * Previously, if a cluster admin creates a new `MachineOSConfig` object that references a legacy pull secret, the canonicalized version of this secret that gets created is not updated whenever the original pull secret changes. With this release, the issue is resolved. -(link:https://issues.redhat.com/browse/OCPBUGS-34079[*OCPBUGS-34079*]) +(link:https://issues.redhat.com/browse/OCPBUGS-34079[OCPBUGS-34079]) * Previously, the `/etc/mco/internal-registry-pull-secret.json` secret was being managed by the Machine Config Operator (MCO). Due to a recent change, this secret rotates on an hourly basis. Whenever the MCO detected a change to this secret, it rolled the secret out to each node in the cluster, which resulted in disruptions. With this fix, a different internal mechanism processes changes to the internal registry pull secret to avoid rolling out repeated MachineConfig updates. -(link:https://issues.redhat.com/browse/OCPBUGS-33913[*OCPBUGS-33913*]) +(link:https://issues.redhat.com/browse/OCPBUGS-33913[OCPBUGS-33913]) -* Previously, if you created more than one `MachineOSConfig` object that required a canonicalized secret, only the first object would build. With this fix, the build controller handles multiple `MachineOSBuilds` that use the same canonicalized secret. (link:https://issues.redhat.com/browse/OCPBUGS-33671[*OCPBUGS-33671*]) +* Previously, if you created more than one `MachineOSConfig` object that required a canonicalized secret, only the first object would build. With this fix, the build controller handles multiple `MachineOSBuilds` that use the same canonicalized secret. (link:https://issues.redhat.com/browse/OCPBUGS-33671[OCPBUGS-33671]) -* Previously, if machine config pools (MCP) had a higher `maxUnavailable` value than the cluster's number of unavailable nodes, cordoned nodes were able to be erroneously selected as an update candidate. This fix adds a node readiness check in the node controller so that cordoned nodes are queued for an update. (link:https://issues.redhat.com/browse/OCPBUGS-33397[*OCPBUGS-33397*]) +* Previously, if machine config pools (MCP) had a higher `maxUnavailable` value than the cluster's number of unavailable nodes, cordoned nodes were able to be erroneously selected as an update candidate. This fix adds a node readiness check in the node controller so that cordoned nodes are queued for an update. (link:https://issues.redhat.com/browse/OCPBUGS-33397[OCPBUGS-33397]) -* Previously, nodes could be drained twice if the node was queued multiple times in the drain controller. This behaviour might have been due to increased activity on the node object by on-cluster layering functionality. With this fix, a node queued for drain only drains once. (link:https://issues.redhat.com/browse/OCPBUGS-33134[*OCPBUGS-33134*]) +* Previously, nodes could be drained twice if the node was queued multiple times in the drain controller. This behaviour might have been due to increased activity on the node object by on-cluster layering functionality. With this fix, a node queued for drain only drains once. (link:https://issues.redhat.com/browse/OCPBUGS-33134[OCPBUGS-33134]) -* Previously, a potential panic was seen in Machine Config Controller and Machine Build Controller objects if a de-reference accidentally deleted `MachineOSConfig/MachineOSBuild` to read the build status. The panic is controlled with additional error conditions to warn for allowed MachineOSConfig deletions. (link:https://issues.redhat.com/browse/OCPBUGS-33129[*OCPBUGS-33129*]) +* Previously, a potential panic was seen in Machine Config Controller and Machine Build Controller objects if a de-reference accidentally deleted `MachineOSConfig/MachineOSBuild` to read the build status. The panic is controlled with additional error conditions to warn for allowed MachineOSConfig deletions. (link:https://issues.redhat.com/browse/OCPBUGS-33129[OCPBUGS-33129]) -* Previously, after upgrading from {product-title} 4.1 or 4.2 to version 4.15, some machines could get stuck during provisioning and never became available. This was because the `machine-config-daemon-firstboot` service was failing due to an incompatible `machine-config-daemon` binary on those nodes. With this release, the correct `machine-config-daemon` binary is copied to nodes before booting. (link:https://issues.redhat.com/browse/OCPBUGS-28974[*OCPBUGS-28974*]) +* Previously, after upgrading from {product-title} 4.1 or 4.2 to version 4.15, some machines could get stuck during provisioning and never became available. This was because the `machine-config-daemon-firstboot` service was failing due to an incompatible `machine-config-daemon` binary on those nodes. With this release, the correct `machine-config-daemon` binary is copied to nodes before booting. (link:https://issues.redhat.com/browse/OCPBUGS-28974[OCPBUGS-28974]) -* Previously, if you attempted to configure on-cluster {op-system-first} image layering on a non-{op-system} node, the node became degraded. With this fix, in this situation, an error message is produced in the node logs, but the node is not degraded. (link:https://issues.redhat.com/browse/OCPBUGS-19537[*OCPBUGS-19537*]) +* Previously, if you attempted to configure on-cluster {op-system-first} image layering on a non-{op-system} node, the node became degraded. With this fix, in this situation, an error message is produced in the node logs, but the node is not degraded. (link:https://issues.redhat.com/browse/OCPBUGS-19537[OCPBUGS-19537]) [discrete] [id="ocp-4-17-management-console-bug-fixes_{context}"] ==== Management Console -* Previously, the *Cluster overview* page included a `View all steps in documentation` link that resulted in a 404 error for {product-rosa} and {product-dedicated} clusters. With this update, the link does not appear for {product-rosa} and {product-dedicated} clusters. (link:https://issues.redhat.com/browse/OCPBUGS-37054[*OCPBUGS-37054*]) +* Previously, the *Cluster overview* page included a `View all steps in documentation` link that resulted in a 404 error for {product-rosa} and {product-dedicated} clusters. With this update, the link does not appear for {product-rosa} and {product-dedicated} clusters. (link:https://issues.redhat.com/browse/OCPBUGS-37054[OCPBUGS-37054]) -* Previously, a warning was not provided when you were on a {gcp-first} cluster that supports {gcp-wid-short} and that the Operator supports it. With this release, logic was added to support {gcp-wid-short} and Federated Identity Operator installs, so now you are alerted when you are on a {gcp-short} cluster. (link:https://issues.redhat.com/browse/OCPBUGS-38591[*OCPBUGS-38591*]) +* Previously, a warning was not provided when you were on a {gcp-first} cluster that supports {gcp-wid-short} and that the Operator supports it. With this release, logic was added to support {gcp-wid-short} and Federated Identity Operator installs, so now you are alerted when you are on a {gcp-short} cluster. (link:https://issues.redhat.com/browse/OCPBUGS-38591[OCPBUGS-38591]) -* Previously, the version number text in the *Updates* graph on the *Cluster Settings* page appeared as black text on a dark background when using Firefox in dark mode. With this update, the text appears as white text. (link:https://issues.redhat.com/browse/OCPBUGS-38427[*OCPBUGS-38427*]) +* Previously, the version number text in the *Updates* graph on the *Cluster Settings* page appeared as black text on a dark background when using Firefox in dark mode. With this update, the text appears as white text. (link:https://issues.redhat.com/browse/OCPBUGS-38427[OCPBUGS-38427]) -* Previously, dynamic plugins using PatternFly 4 referenced variables that are not available in {product-title} 4.15 and later. This was causing contrast issues for {rh-rhacm-first} in dark mode. With this update, older chart styles are now available to support PatternFly 4 charts used by dynamic plugins. (link:https://issues.redhat.com/browse/OCPBUGS-36816[*OCPBUGS-36816*]) +* Previously, dynamic plugins using PatternFly 4 referenced variables that are not available in {product-title} 4.15 and later. This was causing contrast issues for {rh-rhacm-first} in dark mode. With this update, older chart styles are now available to support PatternFly 4 charts used by dynamic plugins. (link:https://issues.redhat.com/browse/OCPBUGS-36816[OCPBUGS-36816]) -* Previously, when the `Display Admission Webhook` warning implementation presented issues with some incorrect code. With this update, the unnecessary warning message has been removed. (link:https://issues.redhat.com/browse/OCPBUGS-35940[*OCPBUGS-35940*]) +* Previously, when the `Display Admission Webhook` warning implementation presented issues with some incorrect code. With this update, the unnecessary warning message has been removed. (link:https://issues.redhat.com/browse/OCPBUGS-35940[OCPBUGS-35940]) -* Previously, the global sync lock that applied to all HTTP servers spawned goroutines with a sync lock that is specific to each of the refresh tokens. With this release, the global refresh sync lock on a cluster with an external OIDC environment was replaced with a sync that refreshes for each token. As a result, refresh token performance is improved by 30% to 50%. (link:https://issues.redhat.com/browse/OCPBUGS-35080[*OCPBUGS-35080*]) +* Previously, the global sync lock that applied to all HTTP servers spawned goroutines with a sync lock that is specific to each of the refresh tokens. With this release, the global refresh sync lock on a cluster with an external OIDC environment was replaced with a sync that refreshes for each token. As a result, refresh token performance is improved by 30% to 50%. (link:https://issues.redhat.com/browse/OCPBUGS-35080[OCPBUGS-35080]) -* Previously, a warning was not displayed for the `minAvailable` warning in `PodDisruptionBudget` create and edit form. With this update, code logic for displaying the `minAvailable` warning was added, and the `minAvailable` warning is displayed if violated. (link:https://issues.redhat.com/browse/OCPBUGS-34937[*OCPBUGS-34937*]) +* Previously, a warning was not displayed for the `minAvailable` warning in `PodDisruptionBudget` create and edit form. With this update, code logic for displaying the `minAvailable` warning was added, and the `minAvailable` warning is displayed if violated. (link:https://issues.redhat.com/browse/OCPBUGS-34937[OCPBUGS-34937]) -* Previously, the *OperandDetails* page displayed information for the first CRD that matched by name. After this fix, the *OperandDetails* page displays information for the CRD that matches by name and the version of the operand. (link:https://issues.redhat.com/browse/OCPBUGS-34901[*OCPBUGS-34901*]) +* Previously, the *OperandDetails* page displayed information for the first CRD that matched by name. After this fix, the *OperandDetails* page displays information for the CRD that matches by name and the version of the operand. (link:https://issues.redhat.com/browse/OCPBUGS-34901[OCPBUGS-34901]) -* Previously, one inactive or idle browser tab caused session expiration for all other tabs. With this change, activity in any tab will prevent session expiration even if there is one inactive or idle browser tab. (link:https://issues.redhat.com/browse/OCPBUGS-34387[*OCPBUGS-34387*]) +* Previously, one inactive or idle browser tab caused session expiration for all other tabs. With this change, activity in any tab will prevent session expiration even if there is one inactive or idle browser tab. (link:https://issues.redhat.com/browse/OCPBUGS-34387[OCPBUGS-34387]) -* Previously, text areas were not resizable. With this update, you are now able to resize text areas. (link:https://issues.redhat.com/browse/OCPBUGS-34200[*OCPBUGS-34200*]) +* Previously, text areas were not resizable. With this update, you are now able to resize text areas. (link:https://issues.redhat.com/browse/OCPBUGS-34200[OCPBUGS-34200]) -* Previously, the *Debug container* link was not displayed for pods with a `Completed` status. With this change, the link now appears. (link:https://issues.redhat.com/browse/OCPBUGS-33631[*OCPBUGS-33631*]) +* Previously, the *Debug container* link was not displayed for pods with a `Completed` status. With this change, the link now appears. (link:https://issues.redhat.com/browse/OCPBUGS-33631[OCPBUGS-33631]) -* Previously, the {product-title} web console did not show `filesystem` metrics on the *Nodes list* page due to incorrect Prometheus query. With this update, `filesystem` metrics are correctly displayed. (link:https://issues.redhat.com/browse/OCPBUGS-33136[*OCPBUGS-33136*]) +* Previously, the {product-title} web console did not show `filesystem` metrics on the *Nodes list* page due to incorrect Prometheus query. With this update, `filesystem` metrics are correctly displayed. (link:https://issues.redhat.com/browse/OCPBUGS-33136[OCPBUGS-33136]) -* Previously, pseudolocalization was not working due to a configuration issue. After this fix, pseudolocalization works again. (link:https://issues.redhat.com/browse/OCPBUGS-30218[*OCPBUGS-30218*]) +* Previously, pseudolocalization was not working due to a configuration issue. After this fix, pseudolocalization works again. (link:https://issues.redhat.com/browse/OCPBUGS-30218[OCPBUGS-30218]) -* Previously, console pods would crash loop if the `--user-auth` flag was set to `disabled`. With this update, the console backend properly handles this value. (link:https://issues.redhat.com/browse/OCPBUGS-29510[*OCPBUGS-29510*]) +* Previously, console pods would crash loop if the `--user-auth` flag was set to `disabled`. With this update, the console backend properly handles this value. (link:https://issues.redhat.com/browse/OCPBUGS-29510[OCPBUGS-29510]) -* Previously, utilization cards displayed a `limit` that incorrectly implied a relationship between capacity and limits. With this update, the position of `limit` was changed and the wording updated. (link:https://issues.redhat.com/browse/OCPBUGS-23332[*OCPBUGS-23332*]) +* Previously, utilization cards displayed a `limit` that incorrectly implied a relationship between capacity and limits. With this update, the position of `limit` was changed and the wording updated. (link:https://issues.redhat.com/browse/OCPBUGS-23332[OCPBUGS-23332]) -* Previously, in some edge cases, the wrong resource could be fetched when using websockets to watch a namespaced resource without providing a namespace. With this update, a validation to the resource watch logic was added to prevent the websocket request and log an error under this condition. (link:https://issues.redhat.com/browse/OCPBUGS-19855[*OCPBUGS-19855*]) +* Previously, in some edge cases, the wrong resource could be fetched when using websockets to watch a namespaced resource without providing a namespace. With this update, a validation to the resource watch logic was added to prevent the websocket request and log an error under this condition. (link:https://issues.redhat.com/browse/OCPBUGS-19855[OCPBUGS-19855]) -* Previously, perspective switching was not properly handled. With this update, perspectives that are passed with URL search parameters or plugin route page extensions now correctly switch the perspective and retain the correct URL path. (link:https://issues.redhat.com/browse/OCPBUGS-19048[*OCPBUGS-19048*]) +* Previously, perspective switching was not properly handled. With this update, perspectives that are passed with URL search parameters or plugin route page extensions now correctly switch the perspective and retain the correct URL path. (link:https://issues.redhat.com/browse/OCPBUGS-19048[OCPBUGS-19048]) //// [discrete] @@ -1921,33 +1921,33 @@ link:https://issues.redhat.com/browse/OCPBUGS-39428[(*OCPBUGS-39428*)] [id="ocp-4-17-networking-bug-fixes_{context}"] ==== Networking -* Previously, the SR-IOV Network Operator was listing the `SriovNetworkNodePolicies` resources in random order. This caused the `sriov-device-plugin` pod to enter a continuous restart loop. With this release, the SR-IOV Network Operator lists policies in a deterministic order so that the `sriov-device-plugin` pod does not enter a continuous restart loop. (link:https://issues.redhat.com/browse/OCPBUGS-36243[*OCPBUGS-36243*]) +* Previously, the SR-IOV Network Operator was listing the `SriovNetworkNodePolicies` resources in random order. This caused the `sriov-device-plugin` pod to enter a continuous restart loop. With this release, the SR-IOV Network Operator lists policies in a deterministic order so that the `sriov-device-plugin` pod does not enter a continuous restart loop. (link:https://issues.redhat.com/browse/OCPBUGS-36243[OCPBUGS-36243]) -* Previously, an interface created inside a new pod would remain inactive and the Gratuitous Address Resolution Protocol (GARP) notification would be generated. The notification did not reach the cluster and this prevented ARP tables of other pods inside the cluster from updating the MAC address of the new pod. This situation caused cluster traffic to stall until ARP table entries expired. With this release, a GARP notification is now sent after the interface inside a pod is active so that the GARP notification reaches the cluster. As a result, surrounding pods can identify the new pod earlier than they could with the previous behavior. (link:https://issues.redhat.com/browse/OCPBUGS-30549[*OCPBUGS-30549*]) +* Previously, an interface created inside a new pod would remain inactive and the Gratuitous Address Resolution Protocol (GARP) notification would be generated. The notification did not reach the cluster and this prevented ARP tables of other pods inside the cluster from updating the MAC address of the new pod. This situation caused cluster traffic to stall until ARP table entries expired. With this release, a GARP notification is now sent after the interface inside a pod is active so that the GARP notification reaches the cluster. As a result, surrounding pods can identify the new pod earlier than they could with the previous behavior. (link:https://issues.redhat.com/browse/OCPBUGS-30549[OCPBUGS-30549]) -* Previously, enabling FIPS for a cluster caused SR-IOV device plugin pods to fail. With this release, SR-IOV device plugin pods have FIPS enabled so that when you enable FIPS for the cluster, the pods do not fail. (link:https://issues.redhat.com/browse/OCPBUGS-41131[*OCPBUGS-41131*]) +* Previously, enabling FIPS for a cluster caused SR-IOV device plugin pods to fail. With this release, SR-IOV device plugin pods have FIPS enabled so that when you enable FIPS for the cluster, the pods do not fail. (link:https://issues.redhat.com/browse/OCPBUGS-41131[OCPBUGS-41131]) -* Previously, a race condition was generated after rebooting an {product-title} node that used a performance profile with a small number of reserved CPUs. This occurred because Single Root I/O Virtualization (SR-IOV) virtual functions (VFs) shared the same MAC address and any pods that used the VFs would experience communication issues. With this release, an update to the SR-IOV Network Operator config daemon ensures that the Operator checks that no duplicate MAC addresses do not exist on VFs. (link:https://issues.redhat.com/browse/OCPBUGS-33137[*OCPBUGS-33137*]) +* Previously, a race condition was generated after rebooting an {product-title} node that used a performance profile with a small number of reserved CPUs. This occurred because Single Root I/O Virtualization (SR-IOV) virtual functions (VFs) shared the same MAC address and any pods that used the VFs would experience communication issues. With this release, an update to the SR-IOV Network Operator config daemon ensures that the Operator checks that no duplicate MAC addresses do not exist on VFs. (link:https://issues.redhat.com/browse/OCPBUGS-33137[OCPBUGS-33137]) -* Previously, if you deleted the `sriovOperatorConfig` custom resource (CR), you could not create a new `sriovOperatorConfig` CR. With this release, the Single Root I/O Virtualization (SR-IOV) Network Operator removes validating webhooks when you delete the `sriovOperatorConfig` CR, so that you can create a new `sriovOperatorConfig` CR. (link:https://issues.redhat.com/browse/OCPBUGS-37567[*OCPBUGS-37567*]) +* Previously, if you deleted the `sriovOperatorConfig` custom resource (CR), you could not create a new `sriovOperatorConfig` CR. With this release, the Single Root I/O Virtualization (SR-IOV) Network Operator removes validating webhooks when you delete the `sriovOperatorConfig` CR, so that you can create a new `sriovOperatorConfig` CR. (link:https://issues.redhat.com/browse/OCPBUGS-37567[OCPBUGS-37567]) -* Previously, when you switched your cluster to use a different load balancer, the Ingress Operator did not remove the values from the `classicLoadBalancer` and `networkLoadBalancer` parameters in the `IngressController` custom resource (CR) status. This situation caused the status of the CR to report wrong information from the `classicLoadBalancer` and `networkLoadBalancer` parameters. With this release, after you switch your cluster to use a different load balancer, the Ingress Operator removes values from these parameters so that the CR reports a more accurate and less confusing message status. (link:https://issues.redhat.com/browse/OCPBUGS-38646[*OCPBUGS-38646*]) +* Previously, when you switched your cluster to use a different load balancer, the Ingress Operator did not remove the values from the `classicLoadBalancer` and `networkLoadBalancer` parameters in the `IngressController` custom resource (CR) status. This situation caused the status of the CR to report wrong information from the `classicLoadBalancer` and `networkLoadBalancer` parameters. With this release, after you switch your cluster to use a different load balancer, the Ingress Operator removes values from these parameters so that the CR reports a more accurate and less confusing message status. (link:https://issues.redhat.com/browse/OCPBUGS-38646[OCPBUGS-38646]) -* Previously, no multicast packets reached their intended target nodes when a multicast sender and a multicast receiver existed on the same node. This happened because of an OVN-Kubernetes RPM package update. With this release, this regression is fixed in the OVN-Kubernetes RPM package, so that the issue no longer persists. (link:https://issues.redhat.com/browse/OCPBUGS-34778[*OCPBUGS-34778*]) +* Previously, no multicast packets reached their intended target nodes when a multicast sender and a multicast receiver existed on the same node. This happened because of an OVN-Kubernetes RPM package update. With this release, this regression is fixed in the OVN-Kubernetes RPM package, so that the issue no longer persists. (link:https://issues.redhat.com/browse/OCPBUGS-34778[OCPBUGS-34778]) -* Previously, when you created a `LoadBalancer` service for the Ingress Operator, a log message was generated that stated the change was not effective. This log message should only trigger for a change to an `Infra` custom resource. With this release, this log message is no longer generated when you create a `LoadBalancer` service for the Ingress Operator. (link:https://issues.redhat.com/browse/OCPBUGS-34413[*OCPBUGS-34413*]) +* Previously, when you created a `LoadBalancer` service for the Ingress Operator, a log message was generated that stated the change was not effective. This log message should only trigger for a change to an `Infra` custom resource. With this release, this log message is no longer generated when you create a `LoadBalancer` service for the Ingress Operator. (link:https://issues.redhat.com/browse/OCPBUGS-34413[OCPBUGS-34413]) -* Previously, the `DNSNameResolver` controller sent DNS requests to CoreDNS pods for DNS names that had IP addresses with expired time-to-live (TTL) values. This caused a continuous generation of DNS requests and memory leak issues for those pods. With this release, the `DNSNameResolver` controller waits until it receives the updated list of IP addresses and TTL values for a DNS name before sending any more requests to the DNS name. As a result, the controller no longer generates erroneous requests and sends them to pods. CoreDNS pods can now respond to DNS requests in a timely manner and update the `DNSNameResolver` objects with the latest IP addresses and TTLs. (link:https://issues.redhat.com/browse/OCPBUGS-33750[*OCPBUGS-33750*]) +* Previously, the `DNSNameResolver` controller sent DNS requests to CoreDNS pods for DNS names that had IP addresses with expired time-to-live (TTL) values. This caused a continuous generation of DNS requests and memory leak issues for those pods. With this release, the `DNSNameResolver` controller waits until it receives the updated list of IP addresses and TTL values for a DNS name before sending any more requests to the DNS name. As a result, the controller no longer generates erroneous requests and sends them to pods. CoreDNS pods can now respond to DNS requests in a timely manner and update the `DNSNameResolver` objects with the latest IP addresses and TTLs. (link:https://issues.redhat.com/browse/OCPBUGS-33750[OCPBUGS-33750]) -* Previously, when you used the `must-gather` tool, a Multus Container Network Interface (CNI) log file, `multus.log`, was stored in a node's file system. This situation caused the tool to generate unnecessary debug pods in a node. With this release, the Multus CNI no longer creates a `multus.log` file, and instead uses a CNI plugin pattern to inspect any logs for Multus DaemonSet pods in the `openshift-multus` namespace. (link:https://issues.redhat.com/browse/OCPBUGS-33959[*OCPBUGS-33959*]) +* Previously, when you used the `must-gather` tool, a Multus Container Network Interface (CNI) log file, `multus.log`, was stored in a node's file system. This situation caused the tool to generate unnecessary debug pods in a node. With this release, the Multus CNI no longer creates a `multus.log` file, and instead uses a CNI plugin pattern to inspect any logs for Multus DaemonSet pods in the `openshift-multus` namespace. (link:https://issues.redhat.com/browse/OCPBUGS-33959[OCPBUGS-33959]) -* Previously, an alert for `OVNKubernetesNorthdInactive` would not fire in circumstances where it should fire. With this release, the issue is fixed so that the alert for `OVNKubernetesNorthdInactive` fires as expected. (link:https://issues.redhat.com/browse/OCPBUGS-33758[*OCPBUGS-33758*]) +* Previously, an alert for `OVNKubernetesNorthdInactive` would not fire in circumstances where it should fire. With this release, the issue is fixed so that the alert for `OVNKubernetesNorthdInactive` fires as expected. (link:https://issues.redhat.com/browse/OCPBUGS-33758[OCPBUGS-33758]) -* Previously, for all pods where the default route has been customized, a missing route for the Kubernetes-OVN masquerade address caused each pod to be unable to connect to itself through a service for which it acts as a backend. With this release, the missing route for Kubernetes-OVN masquerade address is added to pods so that the issue no longer occurs. (link:https://issues.redhat.com/browse/OCPBUGS-36865[*OCPBUGS-36865*]) +* Previously, for all pods where the default route has been customized, a missing route for the Kubernetes-OVN masquerade address caused each pod to be unable to connect to itself through a service for which it acts as a backend. With this release, the missing route for Kubernetes-OVN masquerade address is added to pods so that the issue no longer occurs. (link:https://issues.redhat.com/browse/OCPBUGS-36865[OCPBUGS-36865]) -* Previously, the `iptables-alerter` pod did not handle errors from the `crictl` command-line interface, which could cause the pod to incorrectly log events from `host-network` pods or cause pod restarts. With this release, the errors are handled correctly so that these issues no longer persist. (link:https://issues.redhat.com/browse/OCPBUGS-37713[*OCPBUGS-37713*]) +* Previously, the `iptables-alerter` pod did not handle errors from the `crictl` command-line interface, which could cause the pod to incorrectly log events from `host-network` pods or cause pod restarts. With this release, the errors are handled correctly so that these issues no longer persist. (link:https://issues.redhat.com/browse/OCPBUGS-37713[OCPBUGS-37713]) -* Previously, if you created a hosted cluster by using a proxy for the purposes of making the cluster reach a control plane from a compute node, the compute node would be unavailable to the cluster. With this release, the proxy settings are updated for the node so that the node can use a proxy to successfully communicate with the control plane. (link:https://issues.redhat.com/browse/OCPBUGS-37786[*OCPBUGS-37786*]) +* Previously, if you created a hosted cluster by using a proxy for the purposes of making the cluster reach a control plane from a compute node, the compute node would be unavailable to the cluster. With this release, the proxy settings are updated for the node so that the node can use a proxy to successfully communicate with the control plane. (link:https://issues.redhat.com/browse/OCPBUGS-37786[OCPBUGS-37786]) * Previously, when a cluster failed to install on an on-premise platform with a configured load balancer, the `LoadBalancer` service's `LoadBalancerReady` condition received the `SyncLoadBalancerFailed` status. The status generated the following message: + @@ -1963,7 +1963,7 @@ This message is wrong because the logs are stored in the `cloud-controller-manag The cloud-controller-manager logs may contain more details. ---- + -(link:https://issues.redhat.com/browse/OCPBUGS-31664[*OCPBUGS-31664*]) +(link:https://issues.redhat.com/browse/OCPBUGS-31664[OCPBUGS-31664]) * Previously, you could not control log levels for the internal component that selects IP addresses for cluster nodes. With this release, you can now enable debug log levels so that you can either increase or decrease log levels on-demand. To adjust log levels, you must create a config map manifest file with a configuration similar to the following: + @@ -1979,39 +1979,39 @@ metadata: # ... ---- + -(link:https://issues.redhat.com/browse/OCPBUGS-32348[*OCPBUGS-32348*]) +(link:https://issues.redhat.com/browse/OCPBUGS-32348[OCPBUGS-32348]) -* Previously, the Ingress Operator could not successfully update the canary route because the Operator did not have permission to update `spec.host` or `spec.subdomain` fields on an existing route. With this release, the required permission is added to the cluster role for the Operator’s service account and the Ingress Operator can update the canary route. (link:https://issues.redhat.com/browse/OCPBUGS-36465[*OCPBUGS-36465*]) +* Previously, the Ingress Operator could not successfully update the canary route because the Operator did not have permission to update `spec.host` or `spec.subdomain` fields on an existing route. With this release, the required permission is added to the cluster role for the Operator’s service account and the Ingress Operator can update the canary route. (link:https://issues.redhat.com/browse/OCPBUGS-36465[OCPBUGS-36465]) -* Previously, administrator privileges were required to run some networking containers, such as Keepalived, on supported on-premise platforms. With this release, these containers no longer require administrator privileges to run them on supported on-premise platforms. (link:https://issues.redhat.com/browse/OCPBUGS-36175[*OCPBUGS-36175*]) +* Previously, administrator privileges were required to run some networking containers, such as Keepalived, on supported on-premise platforms. With this release, these containers no longer require administrator privileges to run them on supported on-premise platforms. (link:https://issues.redhat.com/browse/OCPBUGS-36175[OCPBUGS-36175]) -* Previously, if your `NodeNetworkConfigurationPolicy` (NNCP) custom resource (CR) is set to use the default spanning tree protocol (STP) implementation, the CR configuration file would show `stp.enabled: true`, but the {product-title} web console cleared the STP checkbox. With this release, the web console only clears the STEP checkbox after you define `stp.enabled: false` in the NNCP CR YAML file. (link:https://issues.redhat.com/browse/OCPBUGS-36238[*OCPBUGS-36238*]) +* Previously, if your `NodeNetworkConfigurationPolicy` (NNCP) custom resource (CR) is set to use the default spanning tree protocol (STP) implementation, the CR configuration file would show `stp.enabled: true`, but the {product-title} web console cleared the STP checkbox. With this release, the web console only clears the STEP checkbox after you define `stp.enabled: false` in the NNCP CR YAML file. (link:https://issues.redhat.com/browse/OCPBUGS-36238[OCPBUGS-36238]) -* Previously, the Ingress Controller status was incorrectly displayed as `Degraded=False` because of a timing update issue with the `CanaryRepetitiveFailures` condition. With this release, the Ingress Controller status is correctly marked as `Degraded=True` for the appropriate length of time that the `CanaryRepetitiveFailures` condition exists. (link:https://issues.redhat.com/browse/OCPBUGS-39220[*OCPBUGS-39220*]) +* Previously, the Ingress Controller status was incorrectly displayed as `Degraded=False` because of a timing update issue with the `CanaryRepetitiveFailures` condition. With this release, the Ingress Controller status is correctly marked as `Degraded=True` for the appropriate length of time that the `CanaryRepetitiveFailures` condition exists. (link:https://issues.redhat.com/browse/OCPBUGS-39220[OCPBUGS-39220]) [discrete] [id="ocp-4-17-node-bug-fixes_{context}"] ==== Node -* Previously, the Container Runtime Config controller did not detect whether a mirror configuration was in use before adding the scope from a `ClusterImagePolicy` CR to the `/etc/containers/registries.d/sigstore-registries.yaml` file. As a consequence, image verification failed with a `Not looking for sigstore attachments` message. With this fix, images are pulled from the mirror registry as expected. (link:https://issues.redhat.com/browse/OCPBUGS-36344[*OCPBUGS-36344*]) +* Previously, the Container Runtime Config controller did not detect whether a mirror configuration was in use before adding the scope from a `ClusterImagePolicy` CR to the `/etc/containers/registries.d/sigstore-registries.yaml` file. As a consequence, image verification failed with a `Not looking for sigstore attachments` message. With this fix, images are pulled from the mirror registry as expected. (link:https://issues.redhat.com/browse/OCPBUGS-36344[OCPBUGS-36344]) -* Previously, a group ID was not added to the `/etc/group` directory within a container when the `spec.securityContext.runAsGroup` attribute was set in the pod specification. With this release, this issue is fixed. (link:https://issues.redhat.com/browse/OCPBUGS-39478[*OCPBUGS-39478*]) +* Previously, a group ID was not added to the `/etc/group` directory within a container when the `spec.securityContext.runAsGroup` attribute was set in the pod specification. With this release, this issue is fixed. (link:https://issues.redhat.com/browse/OCPBUGS-39478[OCPBUGS-39478]) -* Previously, because of a critical regression on RHEL 9.4 kernels earlier than `5.14.0-427.26.1.el9_4`, the `mglru` feature had memory management disabled. In this release, the regression issue is fixed so that the `mglru` feature is now enabled in {product-title} {product-version}. (link:https://issues.redhat.com/browse/OCPBUGS-35436[*OCPBUGS-35436*]) +* Previously, because of a critical regression on RHEL 9.4 kernels earlier than `5.14.0-427.26.1.el9_4`, the `mglru` feature had memory management disabled. In this release, the regression issue is fixed so that the `mglru` feature is now enabled in {product-title} {product-version}. (link:https://issues.redhat.com/browse/OCPBUGS-35436[OCPBUGS-35436]) [discrete] [id="ocp-4-17-node-tuning-operator-bug-fixes_{context}"] ==== Node Tuning Operator (NTO) -* Previously, due to an internal bug, the Node Tuning Operator incorrectly computed CPU masks for interrupt and network-handling CPU affinity if a machine had more than 256 CPUs. This prevented proper CPU isolation on those machines and resulted in `systemd` unit failures. With this release, the Node Tuning Operator computes the masks correctly. (link:https://issues.redhat.com/browse/OCPBUGS-39164[*OCPBUGS-39164*]) +* Previously, due to an internal bug, the Node Tuning Operator incorrectly computed CPU masks for interrupt and network-handling CPU affinity if a machine had more than 256 CPUs. This prevented proper CPU isolation on those machines and resulted in `systemd` unit failures. With this release, the Node Tuning Operator computes the masks correctly. (link:https://issues.redhat.com/browse/OCPBUGS-39164[OCPBUGS-39164]) -* Previously, the Open vSwitch (OVS) pinning procedure set the CPU affinity of the main thread, but other CPU threads did not pick up this affinity if they had already been created. As a consequence, some OVS threads did not run on the correct CPU set, which might interfere with the performance of pods with a Quality of Service (QoS) class of `Guaranteed`. With this update, the OVS pinning procedure updates the affinity of all the OVS threads, ensuring that all OVS threads run on the correct CPU set. (link:https://issues.redhat.com/browse/OCPBUGS-35347[*OCPBUGS-35347*]) +* Previously, the Open vSwitch (OVS) pinning procedure set the CPU affinity of the main thread, but other CPU threads did not pick up this affinity if they had already been created. As a consequence, some OVS threads did not run on the correct CPU set, which might interfere with the performance of pods with a Quality of Service (QoS) class of `Guaranteed`. With this update, the OVS pinning procedure updates the affinity of all the OVS threads, ensuring that all OVS threads run on the correct CPU set. (link:https://issues.redhat.com/browse/OCPBUGS-35347[OCPBUGS-35347]) [discrete] [id="ocp-4-17-observability-bug-fixes_{context}"] ==== Observability -* Previously, when you log on under the *Administrator* perspective on the {product-title} web console and use the *Observe* -> *Alerting* function, an `S is not a function` displayed on alert metrics graph. This issue happened because of a missing function validation check. With this release, the function validation check is added so the alert metric chart displays collected metrics. (link:https://issues.redhat.com/browse/OCPBUGS-37291[*OCPBUGS-37291*]) +* Previously, when you log on under the *Administrator* perspective on the {product-title} web console and use the *Observe* -> *Alerting* function, an `S is not a function` displayed on alert metrics graph. This issue happened because of a missing function validation check. With this release, the function validation check is added so the alert metric chart displays collected metrics. (link:https://issues.redhat.com/browse/OCPBUGS-37291[OCPBUGS-37291]) [discrete] [id="ocp-4-17-openshift-cli-bug-fixes_{context}"] @@ -2024,7 +2024,7 @@ metadata: 2024/08/02 12:18:03 [ERROR]: [OperatorImageCollector] pinging container registry localhost:55000: Get "https://localhost:55000/v2/": http: server gave HTTP response to HTTPS client. ---- + -This occurred because oc-mirror plugin v2 was querying the local cache using HTTPS instead of HTTP. With this update, the HTTP client is now properly configured before the query, resolving the issue. (link:https://issues.redhat.com/browse/OCPBUGS-41503[*OCPBUGS-41503*]) +This occurred because oc-mirror plugin v2 was querying the local cache using HTTPS instead of HTTP. With this update, the HTTP client is now properly configured before the query, resolving the issue. (link:https://issues.redhat.com/browse/OCPBUGS-41503[OCPBUGS-41503]) * Previously, when using the oc-mirror plugin v2 in mirror-to-disk mode, catalog images and contents were stored in `subfolders` under `working-dir`, based on the image digest. During the disk-to-mirror process in fully disconnected environments, the plugin tried to resolve the catalog image tag through the source registry, which was unavailable, leading to such errors: [source.terminal] @@ -2033,11 +2033,11 @@ This occurred because oc-mirror plugin v2 was querying the local cache using HTT [ERROR] : [OperatorImageCollector] pinging container registry registry.redhat.io: Get "http://registry.redhat.io/v2/": dial tcp 23.217.255.152:80: i/o timeout ---- + -With this update, the plugin checks the local cache during the disk-to-mirror process to determine the digest, avoiding the need to query the registry. (link:https://issues.redhat.com/browse/OCPBUGS-36214[*OCPBUGS-36214*]) +With this update, the plugin checks the local cache during the disk-to-mirror process to determine the digest, avoiding the need to query the registry. (link:https://issues.redhat.com/browse/OCPBUGS-36214[OCPBUGS-36214]) -* Previously, when using oc-mirror plugin v2 in mirror-to-disk mode in disconnected environments, the plugin was unable to access `api.openshift.com` to download `graph.tar.gz`, resulting in mirroring failures. With this update, the plugin now searches the local cache for the graph image in disconnected environments where the `UPDATE_URL_OVERRIDE` environment variable is set. If the graph image is missing, the plugin skips it without failing. (link:https://issues.redhat.com/browse/OCPBUGS-38469[*OCPBUGS-38469*]) +* Previously, when using oc-mirror plugin v2 in mirror-to-disk mode in disconnected environments, the plugin was unable to access `api.openshift.com` to download `graph.tar.gz`, resulting in mirroring failures. With this update, the plugin now searches the local cache for the graph image in disconnected environments where the `UPDATE_URL_OVERRIDE` environment variable is set. If the graph image is missing, the plugin skips it without failing. (link:https://issues.redhat.com/browse/OCPBUGS-38469[OCPBUGS-38469]) -* Previously, oc-mirror plugin v2 failed to mirror Operator catalogs from disk-to-mirror in fully disconnected environments. This issue also affected catalogs that specified a `targetCatalog` in the `ImageSetConfiguration` file. With this update, the plugin can now successfully mirror catalogs in fully disconnected environments, and the `targetCatalog` functionality works as expected. (link:https://issues.redhat.com/browse/OCPBUGS-34521[*OCPBUGS-34521*]) +* Previously, oc-mirror plugin v2 failed to mirror Operator catalogs from disk-to-mirror in fully disconnected environments. This issue also affected catalogs that specified a `targetCatalog` in the `ImageSetConfiguration` file. With this update, the plugin can now successfully mirror catalogs in fully disconnected environments, and the `targetCatalog` functionality works as expected. (link:https://issues.redhat.com/browse/OCPBUGS-34521[OCPBUGS-34521]) * Previously, with the oc-mirror plugin v2, there was no validation for the `-v2` vs `--v2` flags for the `oc-mirror` command. As a result, users who mistakenly used `-v2`, which sets the log level to 2, instead of `--v2`, which switches to oc-mirror plugin v2, received unclear error messages. With this update, flag validation is provided. If the `-v2` flag is used while the `ImageSetConfig` is using the `v2alpha1` API and `--v2` is not specified, an error message is displayed. The following message is now enabled that provides a clear guidance to the user: + @@ -2046,7 +2046,7 @@ With this update, the plugin checks the local cache during the disk-to-mirror pr [ERROR]: Detected a v2 ImageSetConfiguration, please use --v2 instead of -v2. ---- + -(link:https://issues.redhat.com/browse/OCPBUGS-33121[*OCPBUGS-33121*]) +(link:https://issues.redhat.com/browse/OCPBUGS-33121[OCPBUGS-33121]) * Previously, oc-mirror plugin v2 did not automatically perform retries when it encountered errors on registries, such as timeouts, expired authentication tokens, HTTP 500 errors, and so on. With this update, retries for these errors are implemented, and users can configure retry behavior with the following flags: + @@ -2055,43 +2055,43 @@ With this update, the plugin checks the local cache during the disk-to-mirror pr ** `--image-timeout`: Defines the timeout period for mirroring an image. Default is 10 minutes. ** `--max-parallel-downloads`: Controls the maximum number of layers to pull simultaneously during a single copy operation. Default is 6. + -(link:https://issues.redhat.com/browse/OCPBUGS-34021[*OCPBUGS-34021*]) +(link:https://issues.redhat.com/browse/OCPBUGS-34021[OCPBUGS-34021]) -* Previously, when using the oc-mirror plugin v2 with the `--rebuild-catalogs` flag, the catalog cache was regenerated locally, which caused failures either due to compatibility issues with the `opm` binary and the platform or due to cache integrity problems on the cluster. With this update, the `--rebuild-catalogs` flag defaults to true, so catalogs are rebuilt without regenerating the internal cache. Additionally, the image command has been modified to generate the cache during pod startup, which may delay pod initialization. (link:https://issues.redhat.com/browse/OCPBUGS-37667[*OCPBUGS-37667*]) +* Previously, when using the oc-mirror plugin v2 with the `--rebuild-catalogs` flag, the catalog cache was regenerated locally, which caused failures either due to compatibility issues with the `opm` binary and the platform or due to cache integrity problems on the cluster. With this update, the `--rebuild-catalogs` flag defaults to true, so catalogs are rebuilt without regenerating the internal cache. Additionally, the image command has been modified to generate the cache during pod startup, which may delay pod initialization. (link:https://issues.redhat.com/browse/OCPBUGS-37667[OCPBUGS-37667]) -* Previously, the oc-mirror plugin v2 did not use the system proxy configuration to recover signatures for releases when running behind a proxy with system proxy settings. With this release, the system proxy settings are now applied during the signature recovery process. (link:https://issues.redhat.com/browse/OCPBUGS-37055[*OCPBUGS-37055*]) +* Previously, the oc-mirror plugin v2 did not use the system proxy configuration to recover signatures for releases when running behind a proxy with system proxy settings. With this release, the system proxy settings are now applied during the signature recovery process. (link:https://issues.redhat.com/browse/OCPBUGS-37055[OCPBUGS-37055]) -* Previously, oc-mirror plugin v2 would stop the mirroring process when it encountered Operators using bundle versions that were not compliant with semantic versioning, which also prevented the creation of cluster resources like IDMS, ITMS, and `CatalogSource` objects. With this fix, the plugin now skips these problematic images instead of halting the process. If an image uses incorrect semantic versioning, a warning message is displayed in the console with the relevant image details. (link:https://issues.redhat.com/browse/OCPBUGS-33081[*OCPBUGS-33081*]) +* Previously, oc-mirror plugin v2 would stop the mirroring process when it encountered Operators using bundle versions that were not compliant with semantic versioning, which also prevented the creation of cluster resources like IDMS, ITMS, and `CatalogSource` objects. With this fix, the plugin now skips these problematic images instead of halting the process. If an image uses incorrect semantic versioning, a warning message is displayed in the console with the relevant image details. (link:https://issues.redhat.com/browse/OCPBUGS-33081[OCPBUGS-33081]) -* Previously, oc-mirror plugin v2 did not generate `ImageDigestMirrorSet` (IDMS) or `ImageTagMirrorSet` (ITMS) files when mirroring failed due to network issues or invalid Operator catalogs. With this update, the `oc-mirror` continues mirroring other images when Operator or additional images fail, and stops only when release images fail. Cluster resources are generated based on successfully mirrored images, and all errors are collected in a log file for review. (link:https://issues.redhat.com/browse/OCPBUGS-34020[*OCPBUGS-34020*]) +* Previously, oc-mirror plugin v2 did not generate `ImageDigestMirrorSet` (IDMS) or `ImageTagMirrorSet` (ITMS) files when mirroring failed due to network issues or invalid Operator catalogs. With this update, the `oc-mirror` continues mirroring other images when Operator or additional images fail, and stops only when release images fail. Cluster resources are generated based on successfully mirrored images, and all errors are collected in a log file for review. (link:https://issues.redhat.com/browse/OCPBUGS-34020[OCPBUGS-34020]) -* Previously, {product-title} release images were not visible in certain registries, such as {quay}. This prevented users from installing {product-title} due to the missing release images. With this update, release images are always tagged to ensure they appear in registries like {quay}, enabling proper installation. (link:https://issues.redhat.com/browse/OCPBUGS-36410[*OCPBUGS-36410*]) +* Previously, {product-title} release images were not visible in certain registries, such as {quay}. This prevented users from installing {product-title} due to the missing release images. With this update, release images are always tagged to ensure they appear in registries like {quay}, enabling proper installation. (link:https://issues.redhat.com/browse/OCPBUGS-36410[OCPBUGS-36410]) -* Previously, the `oc adm must-gather` command took a long time to gather CPU-related performance data in large clusters. With this release, the data is gathered in parallel instead of sequentially, which shortens the data collection time. (link:https://issues.redhat.com/browse/OCPBUGS-34360[*OCPBUGS-34360*]) +* Previously, the `oc adm must-gather` command took a long time to gather CPU-related performance data in large clusters. With this release, the data is gathered in parallel instead of sequentially, which shortens the data collection time. (link:https://issues.redhat.com/browse/OCPBUGS-34360[OCPBUGS-34360]) -* Previously, the `oc set env` command incorrectly changed the API version of `Route` and `DeploymentConfig` objects, for example, `apps.openshift.io/v1` became `v1`. This caused the command to exit with `unable to recognize no matches for kind` errors. With this release, the error is fixed so that the `os set env` command keeps the correct API version in `Route` and `DeploymentConfig` objects. (link:https://issues.redhat.com/browse/OCPBUGS-32108[*OCPBUGS-32108*]) +* Previously, the `oc set env` command incorrectly changed the API version of `Route` and `DeploymentConfig` objects, for example, `apps.openshift.io/v1` became `v1`. This caused the command to exit with `unable to recognize no matches for kind` errors. With this release, the error is fixed so that the `os set env` command keeps the correct API version in `Route` and `DeploymentConfig` objects. (link:https://issues.redhat.com/browse/OCPBUGS-32108[OCPBUGS-32108]) -* Previously, when a `must-gather` operation failed for any reason and the user manually deleted the leftover namespace, a cluster role binding created by the `must-gather` command would remain in the cluster. With this release, when the temporary `must-gather` namespace is deleted, the associated cluster role binding is automatically deleted with it. (link:https://issues.redhat.com/browse/OCPBUGS-31848[*OCPBUGS-31848*]) +* Previously, when a `must-gather` operation failed for any reason and the user manually deleted the leftover namespace, a cluster role binding created by the `must-gather` command would remain in the cluster. With this release, when the temporary `must-gather` namespace is deleted, the associated cluster role binding is automatically deleted with it. (link:https://issues.redhat.com/browse/OCPBUGS-31848[OCPBUGS-31848]) -* Previously, when using the `--v2` flag with the oc-mirror plugin v2, if no images were mirrored and some were skipped, empty `imds.yaml` and `itms.yaml` files were generated. With this release, the custom resource generation is only triggered when at least one image is successfully mirrored, preventing the creation of empty files. (link:https://issues.redhat.com/browse/OCPBUGS-33775[*OCPBUGS-33775*]) +* Previously, when using the `--v2` flag with the oc-mirror plugin v2, if no images were mirrored and some were skipped, empty `imds.yaml` and `itms.yaml` files were generated. With this release, the custom resource generation is only triggered when at least one image is successfully mirrored, preventing the creation of empty files. (link:https://issues.redhat.com/browse/OCPBUGS-33775[OCPBUGS-33775]) [discrete] [id="ocp-4-17-olm-bug-fixes_{context}"] ==== Operator Lifecycle Manager (OLM) -* Previously, clusters with many custom resources (CRs) experienced timeouts from the API server and stranded updates where the only workaround was to uninstall and then reinstall the stranded Operators. This occurred because OLM evaluated potential updates by using a dynamic client lister. With this fix, OLM uses a paging lister for custom resource definitions (CRDs) to avoid timeouts and stranded updates. (link:https://issues.redhat.com/browse/OCPBUGS-41549[*OCPBUGS-41549*]) +* Previously, clusters with many custom resources (CRs) experienced timeouts from the API server and stranded updates where the only workaround was to uninstall and then reinstall the stranded Operators. This occurred because OLM evaluated potential updates by using a dynamic client lister. With this fix, OLM uses a paging lister for custom resource definitions (CRDs) to avoid timeouts and stranded updates. (link:https://issues.redhat.com/browse/OCPBUGS-41549[OCPBUGS-41549]) -* Previously, catalog source pods could not recover from a cluster node failure when the `registryPoll` parameter was unset. With this fix, OLM updates its logic for checking for dead pods. As a result, catalog source pods now recover from node failures as expected. (link:https://issues.redhat.com/browse/OCPBUGS-39574[*OCPBUGS-39574*]) +* Previously, catalog source pods could not recover from a cluster node failure when the `registryPoll` parameter was unset. With this fix, OLM updates its logic for checking for dead pods. As a result, catalog source pods now recover from node failures as expected. (link:https://issues.redhat.com/browse/OCPBUGS-39574[OCPBUGS-39574]) -* Previously, if you tried to install a previously-deleted Operator after an {product-title} update, the installation might fail. This occurred because OLM could not find previously created bundle unpack jobs. With this fix, OLM correctly installs previously installed Operators. (link:https://issues.redhat.com/browse/OCPBUGS-32439[*OCPBUGS-32439*]) +* Previously, if you tried to install a previously-deleted Operator after an {product-title} update, the installation might fail. This occurred because OLM could not find previously created bundle unpack jobs. With this fix, OLM correctly installs previously installed Operators. (link:https://issues.redhat.com/browse/OCPBUGS-32439[OCPBUGS-32439]) -* Previously, when a new version of a custom resource definition (CRD) specified a new conversion strategy, this conversion strategy was expected to successfully convert resources. However, OLM cannot run the new conversion strategies for CRD validation without actually performing the update operation. With this release, OLM generates a warning message during the update process when CRD validations fail with the existing conversion strategy, and the new conversion strategy is specified in the new version of the CRD. (link:https://issues.redhat.com/browse/OCPBUGS-31522[*OCPBUGS-31522*]) +* Previously, when a new version of a custom resource definition (CRD) specified a new conversion strategy, this conversion strategy was expected to successfully convert resources. However, OLM cannot run the new conversion strategies for CRD validation without actually performing the update operation. With this release, OLM generates a warning message during the update process when CRD validations fail with the existing conversion strategy, and the new conversion strategy is specified in the new version of the CRD. (link:https://issues.redhat.com/browse/OCPBUGS-31522[OCPBUGS-31522]) -* Previously, if the `spec.grpcPodConfig.securityContextConfig` field in `CatalogSource` objects was unset within namespaces with a `PodSecurityAdmission` (PSA) level value of `restricted`, the catalog pod would not pass PSA validation. With this release, the OLM Catalog Operator now configures the catalog pod with the `securityContexts` necessary to pass PSA validation. (link:https://issues.redhat.com/browse/OCPBUGS-29729[*OCPBUGS-29729*]) +* Previously, if the `spec.grpcPodConfig.securityContextConfig` field in `CatalogSource` objects was unset within namespaces with a `PodSecurityAdmission` (PSA) level value of `restricted`, the catalog pod would not pass PSA validation. With this release, the OLM Catalog Operator now configures the catalog pod with the `securityContexts` necessary to pass PSA validation. (link:https://issues.redhat.com/browse/OCPBUGS-29729[OCPBUGS-29729]) -* Previously, the `catalogd-controller-manager` pod might not have been deployed to a node despite being in the scheduling queue, and the OLM Operator would fail to install. With this fix, CPU requests are reduced for the related resources, and the issue no longer occurs. (link:https://issues.redhat.com/browse/OCPBUGS-29705[*OCPBUGS-29705*]) +* Previously, the `catalogd-controller-manager` pod might not have been deployed to a node despite being in the scheduling queue, and the OLM Operator would fail to install. With this fix, CPU requests are reduced for the related resources, and the issue no longer occurs. (link:https://issues.redhat.com/browse/OCPBUGS-29705[OCPBUGS-29705]) -* Previously, the Catalog Operator sometimes attempted to connect to deleted catalog sources that were stored in the cache. With this fix, the Catalog Operator queries a client to list the catalog sources on a cluster. (link:https://issues.redhat.com/browse/OCPBUGS-8659[*OCPBUGS-8659*]) +* Previously, the Catalog Operator sometimes attempted to connect to deleted catalog sources that were stored in the cache. With this fix, the Catalog Operator queries a client to list the catalog sources on a cluster. (link:https://issues.redhat.com/browse/OCPBUGS-8659[OCPBUGS-8659]) //// [discrete] @@ -2103,11 +2103,11 @@ With this update, the plugin checks the local cache during the disk-to-mirror pr [id="ocp-4-17-rhcos-bug-fixes_{context}"] ==== {op-system-first} -* Previously, LUKS encryption on a system using 512 emulation disks caused provisioning to fail at the `ignition-ostree-growfs` step because of an `sfdisk` alignment issue. With this release, the `ignition-ostree-growfs` script detects this situation and fixes the alignment automatically. As a result, the system no longer fails during provisioning. (link:https://issues.redhat.com/browse/OCPBUGS-35410[*OCPBUGS-35410*]) +* Previously, LUKS encryption on a system using 512 emulation disks caused provisioning to fail at the `ignition-ostree-growfs` step because of an `sfdisk` alignment issue. With this release, the `ignition-ostree-growfs` script detects this situation and fixes the alignment automatically. As a result, the system no longer fails during provisioning. (link:https://issues.redhat.com/browse/OCPBUGS-35410[OCPBUGS-35410]) -* Previously, a bug in the `growpart` utility caused a LUKS device to lock. This caused the system to boot into an emergency mode. With this release, the call to the `growpart` utility is removed and the system successfully boots without issue. (link:https://issues.redhat.com/browse/OCPBUGS-33124[*OCPBUGS-33124*]) +* Previously, a bug in the `growpart` utility caused a LUKS device to lock. This caused the system to boot into an emergency mode. With this release, the call to the `growpart` utility is removed and the system successfully boots without issue. (link:https://issues.redhat.com/browse/OCPBUGS-33124[OCPBUGS-33124]) -* Previously, if a new deployment was done at the OSTree level on the host, which is identical to the current deployment on a different stateroot, OSTree identified them as equal. This behavior prevented the bootloader from updating when the `set-default` command was invoked, because OSTree did not recognize the two stateroots as a differentiating factor for deployments. With this release, OSTree's logic is modified to consider the stateroots. As a result, OSTree properly sets the default deployment to a new deployment that has different stateroots. (link:https://issues.redhat.com/browse/OCPBUGS-30276[*OCPBUGS-30276*]) +* Previously, if a new deployment was done at the OSTree level on the host, which is identical to the current deployment on a different stateroot, OSTree identified them as equal. This behavior prevented the bootloader from updating when the `set-default` command was invoked, because OSTree did not recognize the two stateroots as a differentiating factor for deployments. With this release, OSTree's logic is modified to consider the stateroots. As a result, OSTree properly sets the default deployment to a new deployment that has different stateroots. (link:https://issues.redhat.com/browse/OCPBUGS-30276[OCPBUGS-30276]) //// [discrete] @@ -2119,7 +2119,7 @@ With this update, the plugin checks the local cache during the disk-to-mirror pr [id="ocp-4-17-storage-bug-fixes_{context}"] ==== Storage -* Previously, the Secrets Store Container Storage Interface (CSI) Driver on {hcp} clusters failed to mount secrets because of an issue when using the {hcp} command-line interface, `hcp`, to create OpenID Connect (OIDC) infrastructure on {aws-full}. With this release, the issue has been fixed so that the driver can now mount volumes. (link:https://issues.redhat.com/browse/OCPBUGS-18711[*OCPBUGS-18711*]) +* Previously, the Secrets Store Container Storage Interface (CSI) Driver on {hcp} clusters failed to mount secrets because of an issue when using the {hcp} command-line interface, `hcp`, to create OpenID Connect (OIDC) infrastructure on {aws-full}. With this release, the issue has been fixed so that the driver can now mount volumes. (link:https://issues.redhat.com/browse/OCPBUGS-18711[OCPBUGS-18711]) //// [discrete] @@ -2805,16 +2805,16 @@ To know the status of the {hcp} features on {product-title} 4.17, see xref:../ho [id="ocp-4-17-known-issues_{context}"] == Known issues -* A regression in the behaviour of `libreswan` caused some nodes with IPsec enabled to lose communication with pods on other nodes in the same cluster. To resolve this issue, consider disabling IPsec for your cluster. (link:https://issues.redhat.com/browse/OCPBUGS-43714[*OCPBUGS-43714*]) +* A regression in the behaviour of `libreswan` caused some nodes with IPsec enabled to lose communication with pods on other nodes in the same cluster. To resolve this issue, consider disabling IPsec for your cluster. (link:https://issues.redhat.com/browse/OCPBUGS-43714[OCPBUGS-43714]) // TODO: This known issue should carry forward to 4.9 and beyond! -* 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. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1917280[*BZ#1917280*]) +* 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. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1917280[BZ#1917280]) -* A known issue exists when deleting a `NetworkAttachmentDefinition` (NAD) resource created by a `UserDefinedNetwork` resource. You must check to see if a pod is referencing the NAD before deleting the NAD. The pod should be deleted before the NAD. Failure to do so can leave pods in an unexpected state. (link:https://issues.redhat.com/browse/OCPBUGS-39185[*OCPBUGS-39185*]) +* A known issue exists when deleting a `NetworkAttachmentDefinition` (NAD) resource created by a `UserDefinedNetwork` resource. You must check to see if a pod is referencing the NAD before deleting the NAD. The pod should be deleted before the NAD. Failure to do so can leave pods in an unexpected state. (link:https://issues.redhat.com/browse/OCPBUGS-39185[OCPBUGS-39185]) -* The DNF package manager included in {op-system-first} images cannot be used at runtime, because DNF relies on additional packages to access entitled nodes in a cluster that are under a Red Hat subscription. As a workaround, use the `rpm-ostree` command instead. (link:https://issues.redhat.com/browse/OCPBUGS-35247[*OCPBUGS-35247*]) +* The DNF package manager included in {op-system-first} images cannot be used at runtime, because DNF relies on additional packages to access entitled nodes in a cluster that are under a Red Hat subscription. As a workaround, use the `rpm-ostree` command instead. (link:https://issues.redhat.com/browse/OCPBUGS-35247[OCPBUGS-35247]) -* When installing a cluster on {azure-full}, the installation will fail if no `install-config.yaml` file is provided. If an `install-config.yaml` file is provided, and `controlPlane.platform` is present but `controlPlane.platform.azure` is not provided, the installation will fail. (link:https://issues.redhat.com/browse/OCPBUGS-42296[*OCPBUGS-42296*]) +* When installing a cluster on {azure-full}, the installation will fail if no `install-config.yaml` file is provided. If an `install-config.yaml` file is provided, and `controlPlane.platform` is present but `controlPlane.platform.azure` is not provided, the installation will fail. (link:https://issues.redhat.com/browse/OCPBUGS-42296[OCPBUGS-42296]) + See xref:../installing/installing_azure/ipi/installing-azure-customizations.adoc#installation-azure-config-yaml_installing-azure-customizations[Sample customized install-config.yaml file for Azure] for a sample configuration file, or set a non-null parameter as in the following example: + @@ -2825,40 +2825,40 @@ controlPlane: azure: {} ---- -* When installing multiple clusters on {azure-full}, running multiple installations simultaneously from the same installation host will result in only one of the clusters installing successfully. If you run the installations sequentially rather than simultaneously, you can install multiple clusters on {azure-short} from the same installation host. (link:https://issues.redhat.com/browse/OCPBUGS-36202[*OCPBUGS-36202*]) +* When installing multiple clusters on {azure-full}, running multiple installations simultaneously from the same installation host will result in only one of the clusters installing successfully. If you run the installations sequentially rather than simultaneously, you can install multiple clusters on {azure-short} from the same installation host. (link:https://issues.redhat.com/browse/OCPBUGS-36202[OCPBUGS-36202]) -* When installing a cluster on {azure-full}, specifying the `Standard_M8-4ms` instance type for control plane machines results in an error due to that instance type specifying its memory in decimal format instead of integer format. (link:https://issues.redhat.com/browse/OCPBUGS-42241[*OCPBUGS-42241*]) +* When installing a cluster on {azure-full}, specifying the `Standard_M8-4ms` instance type for control plane machines results in an error due to that instance type specifying its memory in decimal format instead of integer format. (link:https://issues.redhat.com/browse/OCPBUGS-42241[OCPBUGS-42241]) * At the release of {product-title} {product-version}, a change in storage account naming caused an issue where the Azure File Container Storage Interface (CSI) driver would fail to mount all volumes when the image registry was configured as private. The mount failures occurred because the CSI driver tried to use the storage account of the Image Registry Operator, which was not configured to allow connections from worker subnets. This issue was resolved in xref:../release_notes/ocp-4-17-release-notes.adoc#ocp-4-17-5_release-notes[{product-title} 4.17.5] and applies to later releases. -* When installing a cluster on {azure-short}, the installation fails if a customer-managed encryption key is specified. (link:https://issues.redhat.com/browse/OCPBUGS-42349[*OCPBUGS-42349*]) +* When installing a cluster on {azure-short}, the installation fails if a customer-managed encryption key is specified. (link:https://issues.redhat.com/browse/OCPBUGS-42349[OCPBUGS-42349]) -* When an error occurs during mirroring Operators and additional images, the log message "Generating Catalog Source" might still appear, even if no files are generated. (link:https://issues.redhat.com/browse/OCPBUGS-42503[*OCPBUGS-42503*]) +* When an error occurs during mirroring Operators and additional images, the log message "Generating Catalog Source" might still appear, even if no files are generated. (link:https://issues.redhat.com/browse/OCPBUGS-42503[OCPBUGS-42503]) -* If you have IPsec enabled on the cluster, on the node hosting the north-south IPsec connection, restarting the `ipsec.service` systemd unit or restarting the `ovn-ipsec-host` pod causes a loss of the IPsec connection. (link:https://issues.redhat.com/browse/RHEL-26878[*RHEL-26878*]) +* If you have IPsec enabled on the cluster, on the node hosting the north-south IPsec connection, restarting the `ipsec.service` systemd unit or restarting the `ovn-ipsec-host` pod causes a loss of the IPsec connection. (link:https://issues.redhat.com/browse/RHEL-26878[RHEL-26878]) -* {run-once-operator} (RODOO) cannot be installed on clusters managed by the Hypershift Operator. (link:https://issues.redhat.com/browse/OCPBUGS-17533[*OCPBUGS-17533*]) +* {run-once-operator} (RODOO) cannot be installed on clusters managed by the Hypershift Operator. (link:https://issues.redhat.com/browse/OCPBUGS-17533[OCPBUGS-17533]) [id="ocp-telco-ran-4-17-known-issues_{context}"] * When you run Cloud-native Network Functions (CNF) latency tests on an {product-title} cluster, the test can sometimes return results greater than the latency threshold for the test; for example, 20 microseconds for `cyclictest` testing. This results in a test failure. -(link:https://issues.redhat.com/browse/OCPBUGS-42328[*OCPBUGS-42328*]) +(link:https://issues.redhat.com/browse/OCPBUGS-42328[OCPBUGS-42328]) [id="ocp-telco-core-4-17-known-issues_{context}"] -* Each node group must only match one `MachineConfigPool` object. In some cases, the NUMA Resources Operator can allow a configuration where a node group matches more than one `MachineConfigPool` object. This issue could lead to unexpected behavior in resource management. (link:https://issues.redhat.com/browse/OCPBUGS-42523[*OCPBUGS-42523*]) +* Each node group must only match one `MachineConfigPool` object. In some cases, the NUMA Resources Operator can allow a configuration where a node group matches more than one `MachineConfigPool` object. This issue could lead to unexpected behavior in resource management. (link:https://issues.redhat.com/browse/OCPBUGS-42523[OCPBUGS-42523]) -* If you plan to deploy the NUMA Resources Operator, avoid using {product-title} versions 4.17.7 or 4.17.8. (link:https://issues.redhat.com/browse/OCPBUGS-45639[*OCPBUGS-45639*]) +* If you plan to deploy the NUMA Resources Operator, avoid using {product-title} versions 4.17.7 or 4.17.8. (link:https://issues.redhat.com/browse/OCPBUGS-45639[OCPBUGS-45639]) -* When the bond mode in the `NetworkNodeConfigurationPolicy` is changed from `balance-rr` to `active-backup` on kernel bonds that are attached to the `br-ex` interface, the change might fail on arbitrary nodes. As a workaround, create a `NetworkNodeConfigurationPolicy` object without specifying the bond port configuration. (link:https://issues.redhat.com/browse/OCPBUGS-42031[*OCPBUGS-42031*]) +* When the bond mode in the `NetworkNodeConfigurationPolicy` is changed from `balance-rr` to `active-backup` on kernel bonds that are attached to the `br-ex` interface, the change might fail on arbitrary nodes. As a workaround, create a `NetworkNodeConfigurationPolicy` object without specifying the bond port configuration. (link:https://issues.redhat.com/browse/OCPBUGS-42031[OCPBUGS-42031]) [id="ocp-storage-core-4-17-known-issues_{context}"] -* If the controller pod terminates while cloning, or taking or restoring a volume snapshot, is in progress, the Microsoft Azure File clone or snapshot persistent volume claims (PVCs) remain in the Pending state. To resolve this issue, delete any affected clone or snapshot PVCs, and then recreate those PVCs. (link:https://issues.redhat.com/browse/OCPBUGS-35977[*OCPBUGS-35977*]) +* If the controller pod terminates while cloning, or taking or restoring a volume snapshot, is in progress, the Microsoft Azure File clone or snapshot persistent volume claims (PVCs) remain in the Pending state. To resolve this issue, delete any affected clone or snapshot PVCs, and then recreate those PVCs. (link:https://issues.redhat.com/browse/OCPBUGS-35977[OCPBUGS-35977]) [id="ocp-hosted-control-planes-4-17-known-issues_{context}"] -* Deploying a self-managed private hosted cluster on {aws-short} fails because the `bootstrap-kubeconfig` file uses an incorrect KAS port. As a result, the {aws-short} instances are provisioned, but cannot join the hosted cluster as nodes. (link:https://issues.redhat.com/browse/OCPBUGS-31840[*OCPBUGS-31840*]) +* Deploying a self-managed private hosted cluster on {aws-short} fails because the `bootstrap-kubeconfig` file uses an incorrect KAS port. As a result, the {aws-short} instances are provisioned, but cannot join the hosted cluster as nodes. (link:https://issues.redhat.com/browse/OCPBUGS-31840[OCPBUGS-31840]) [id="ocp-4-17-asynchronous-errata-updates_{context}"] == Asynchronous errata updates @@ -2899,13 +2899,13 @@ $ oc adm release info 4.17.24 --pullspecs [id="ocp-4-17-24-bug-fixes_{context}"] ==== Bug fixes -* Previously, an update to the {ibm-cloud-name} Cloud Internet Services (CIS) implementation impacted the upstream Terraform plugin. If you attempted to create an external-facing cluster on {ibm-cloud-name}, an error occurred. With this release, you can create an external cluster on {product-title} without the plugin issue. (link:https://issues.redhat.com/browse/OCPBUGS-54357[*OCPBUGS-54357*]) +* Previously, an update to the {ibm-cloud-name} Cloud Internet Services (CIS) implementation impacted the upstream Terraform plugin. If you attempted to create an external-facing cluster on {ibm-cloud-name}, an error occurred. With this release, you can create an external cluster on {product-title} without the plugin issue. (link:https://issues.redhat.com/browse/OCPBUGS-54357[OCPBUGS-54357]) -* Previously, when users tried building the agent ISO in a disconnected setup, an error occurred. With this release, the setup completes without an error. (link:https://issues.redhat.com/browse/OCPBUGS-53378[*OCPBUGS-53378*]) +* Previously, when users tried building the agent ISO in a disconnected setup, an error occurred. With this release, the setup completes without an error. (link:https://issues.redhat.com/browse/OCPBUGS-53378[OCPBUGS-53378]) -* Previously, the `ovn-ipsec-host` pod failed with a crash loop on RHEL worker nodes because of a missing shared library during the container execution. With this release, the `ovn-ipsec-host` pod successfully starts on the worker node without an error. (link:https://issues.redhat.com/browse/OCPBUGS-52951[*OCPBUGS-52951*]) +* Previously, the `ovn-ipsec-host` pod failed with a crash loop on RHEL worker nodes because of a missing shared library during the container execution. With this release, the `ovn-ipsec-host` pod successfully starts on the worker node without an error. (link:https://issues.redhat.com/browse/OCPBUGS-52951[OCPBUGS-52951]) -* Previously, the {olm-first} CSV annotation contained unexpected JSON data, which was successfully parsed, but then resulted in a runtime error when attempting to use the resulting value. With this release, JSON values from OLM annotations are validated before use, errors are logged, and the console does not fail when an unexpected JSON is received in an annotation. (link:https://issues.redhat.com/browse/OCPBUGS-51277[(*OCPBUGS-51277*)]) +* Previously, the {olm-first} CSV annotation contained unexpected JSON data, which was successfully parsed, but then resulted in a runtime error when attempting to use the resulting value. With this release, JSON values from OLM annotations are validated before use, errors are logged, and the console does not fail when an unexpected JSON is received in an annotation. (link:https://issues.redhat.com/browse/OCPBUGS-51277[OCPBUGS-51277]) [id="ocp-4-17-24-updating_{context}"] ==== Updating @@ -2940,11 +2940,11 @@ $ oc adm release info 4.17.23 --pullspecs [id="ocp-4-17-23-bug-fixes_{context}"] ==== Bug fixes -* Previously, the Operator Marketplace and the {olm-first} used an older version, v1.24, of the `pod-security.kubernetes.io/` label. With this release, the namespace where Operator Marketplace is deployed now uses the Pod Security Admission (PSA) label marked as `latest`. (link:https://issues.redhat.com/browse/OCPBUGS-53283[*OCPBUGS-53283*]) +* Previously, the Operator Marketplace and the {olm-first} used an older version, v1.24, of the `pod-security.kubernetes.io/` label. With this release, the namespace where Operator Marketplace is deployed now uses the Pod Security Admission (PSA) label marked as `latest`. (link:https://issues.redhat.com/browse/OCPBUGS-53283[OCPBUGS-53283]) -* Previously, the `openshift-install agent create pxe-files` command created temporary directories in `/tmp/agent` and the command did not remove these directories upon command completion. With this release, the command now removes the directories upon completion, so no you do not need to manual deleted the directories. (link:https://issues.redhat.com/browse/OCPBUGS-52961[*OCPBUGS-52961*]) +* Previously, the `openshift-install agent create pxe-files` command created temporary directories in `/tmp/agent` and the command did not remove these directories upon command completion. With this release, the command now removes the directories upon completion, so no you do not need to manual deleted the directories. (link:https://issues.redhat.com/browse/OCPBUGS-52961[OCPBUGS-52961]) -* Previously, a code migration operation failed to process external labels correctly on the *Alert detail* page on the *Administrator perspective* of the web console. These external labels are required to prevent silenced alert notifications from getting added to notification bell icon. Because the *Alert detail* page did not handle external labels correctly, the notification bell provided links to these *Alert detail* pages that generated a `no matching alerts found` message when you clicked on a link. With this release, the *Alert detail* page accepts external labels so clicking on an alert in the notification bell links to the correct *Alert detail* page. (link:https://issues.redhat.com/browse/OCPBUGS-51117[*OCPBUGS-51117*]) +* Previously, a code migration operation failed to process external labels correctly on the *Alert detail* page on the *Administrator perspective* of the web console. These external labels are required to prevent silenced alert notifications from getting added to notification bell icon. Because the *Alert detail* page did not handle external labels correctly, the notification bell provided links to these *Alert detail* pages that generated a `no matching alerts found` message when you clicked on a link. With this release, the *Alert detail* page accepts external labels so clicking on an alert in the notification bell links to the correct *Alert detail* page. (link:https://issues.redhat.com/browse/OCPBUGS-51117[OCPBUGS-51117]) * Previously, when you created a cluster that includes the following `kubevirt` CR configuration, you received a `failed to reconcile virt launcher policy: could not determine if ` is an IPv4 or IPv6 address` error message: + @@ -2960,9 +2960,9 @@ $ oc adm release info 4.17.23 --pullspecs # ... ---- + -This error message was generated because network policies were not properly deployed on virtual machine (VM) namespaces. With this release, a fix means that you can add a host name address to the `nodePort.address` configuration of the CR so that network policies can be properly deployed on VMs. (link:https://issues.redhat.com/browse/OCPBUGS-48439[*OCPBUGS-48439*]) +This error message was generated because network policies were not properly deployed on virtual machine (VM) namespaces. With this release, a fix means that you can add a host name address to the `nodePort.address` configuration of the CR so that network policies can be properly deployed on VMs. (link:https://issues.redhat.com/browse/OCPBUGS-48439[OCPBUGS-48439]) -* Previously, the Single Root I/O Virtualization (SR-IOV) network config daemon unbinded network drivers from the physical function (PF) interface instead of unbinding the drivers from the virtual function (VF) interface when SR-IOV was configured with an InfiniBand (IB) type. This unbinding workflow removed the IB interface from the node, and this sitaution made the IB interface non-functional. With this release, a fix to the SR-IOV network config daemon ensures that the IB interface remains functional when it correctly unbinds the VF network interface. Additionally, the SR-IOV Network Operator targets the network drivers of a VF interface instead of the PF interface when configuring SR-IOV with an IB type. (link:https://issues.redhat.com/browse/OCPBUGS-53254[*OCPBUGS-53254*]) +* Previously, the Single Root I/O Virtualization (SR-IOV) network config daemon unbinded network drivers from the physical function (PF) interface instead of unbinding the drivers from the virtual function (VF) interface when SR-IOV was configured with an InfiniBand (IB) type. This unbinding workflow removed the IB interface from the node, and this sitaution made the IB interface non-functional. With this release, a fix to the SR-IOV network config daemon ensures that the IB interface remains functional when it correctly unbinds the VF network interface. Additionally, the SR-IOV Network Operator targets the network drivers of a VF interface instead of the PF interface when configuring SR-IOV with an IB type. (link:https://issues.redhat.com/browse/OCPBUGS-53254[OCPBUGS-53254]) [id="ocp-4-17-23-updating_{context}"] ==== Updating @@ -2988,7 +2988,7 @@ $ oc adm release info 4.17.22 --pullspecs [id="ocp-4-17-22-bug-fixes_{context}"] ==== Bug fixes -* Previously, during cluster shutdown, a race condition prevented a stage `ostree` deployment from finalizing if the deployment was moved to a staging location during a reboot operation. With this release, a fix removes the race condition from the `ostree` deployment so that the staged deployment can finalize even during a reboot operation. (link:https://issues.redhat.com/browse/OCPBUGS-53225[*OCPBUGS-53225*]) +* Previously, during cluster shutdown, a race condition prevented a stage `ostree` deployment from finalizing if the deployment was moved to a staging location during a reboot operation. With this release, a fix removes the race condition from the `ostree` deployment so that the staged deployment can finalize even during a reboot operation. (link:https://issues.redhat.com/browse/OCPBUGS-53225[OCPBUGS-53225]) [id="ocp-4-17-22-updating_{context}"] ==== Updating @@ -3014,15 +3014,15 @@ $ oc adm release info 4.17.21 --pullspecs [id="ocp-4-17-21-bug-fixes_{context}"] ==== Bug fixes -* Previously, the `trusted-ca-bundle-managed` config map was a mandatory component. If you attempted to use a custom Public Key Infrastructure (PKI), the deployment would fail because the OpenShift API server expected the presence of the `trusted-ca-bundle-managed` config map. With this release, you can deploy clusters without the `trusted-ca-bundle-managed` config map when you use a custom PKI. (link:https://issues.redhat.com/browse/OCPBUGS-52657[*OCPBUGS-52657*]) +* Previously, the `trusted-ca-bundle-managed` config map was a mandatory component. If you attempted to use a custom Public Key Infrastructure (PKI), the deployment would fail because the OpenShift API server expected the presence of the `trusted-ca-bundle-managed` config map. With this release, you can deploy clusters without the `trusted-ca-bundle-managed` config map when you use a custom PKI. (link:https://issues.redhat.com/browse/OCPBUGS-52657[OCPBUGS-52657]) -* Previously, the *Observe* section on the web console did not show items contributed from plugins unless certain flags related to the monitoring were set. However, these flags prevented other plugins, such as logging, distributed tracing, network observability, and so on, from adding items to the *Observe* section. With this release, the monitoring flags are removed so that other plugins can add items to the *Observe* section. (link:https://issues.redhat.com/browse/OCPBUGS-52205[*OCPBUGS-52205*]) +* Previously, the *Observe* section on the web console did not show items contributed from plugins unless certain flags related to the monitoring were set. However, these flags prevented other plugins, such as logging, distributed tracing, network observability, and so on, from adding items to the *Observe* section. With this release, the monitoring flags are removed so that other plugins can add items to the *Observe* section. (link:https://issues.redhat.com/browse/OCPBUGS-52205[OCPBUGS-52205]) -* Previously, a custom Security Context Constraint (SCC) impacted pods that were generated by the Cluster Version Operator from receiving a cluster version upgrade. With this release, {product-title} now sets a default SCC to each pod, so that any custom SCC created does not impact a pod. (link:https://issues.redhat.com/browse/OCPBUGS-50589[*OCPBUGS-50589*]) +* Previously, a custom Security Context Constraint (SCC) impacted pods that were generated by the Cluster Version Operator from receiving a cluster version upgrade. With this release, {product-title} now sets a default SCC to each pod, so that any custom SCC created does not impact a pod. (link:https://issues.redhat.com/browse/OCPBUGS-50589[OCPBUGS-50589]) -* Previously, you could not create `NodePool` resources with ARM64 architecture on non-AWS or {azure-short} platforms. This bug resulted in validation errors that prevented the addition of bare-metal compute nodes and caused Common Expression Language (CEL) validation blocks when creating a `NodePool` resource. The fix modifies the `NodePool` spec validation rules to allow ARM64 architecture on non-AWS or {azure-short} by setting `None` for the `self.platform.type` section. You can now create `NodePool` with ARM64 architecture specifications on non-AWS or {azure-short} bare-metal platforms. (link:https://issues.redhat.com/browse/OCPBUGS-46440[*OCPBUGS-46440*]) +* Previously, you could not create `NodePool` resources with ARM64 architecture on non-AWS or {azure-short} platforms. This bug resulted in validation errors that prevented the addition of bare-metal compute nodes and caused Common Expression Language (CEL) validation blocks when creating a `NodePool` resource. The fix modifies the `NodePool` spec validation rules to allow ARM64 architecture on non-AWS or {azure-short} by setting `None` for the `self.platform.type` section. You can now create `NodePool` with ARM64 architecture specifications on non-AWS or {azure-short} bare-metal platforms. (link:https://issues.redhat.com/browse/OCPBUGS-46440[OCPBUGS-46440]) -* Previously, if you deleted a bare-metal host with a related data image, the data image stayed present. With this release, the issue is resolved, and the data image is deleted with the bare-metal host as expected. (link:https://issues.redhat.com/browse/OCPBUGS-42387[*OCPBUGS-42387*]) +* Previously, if you deleted a bare-metal host with a related data image, the data image stayed present. With this release, the issue is resolved, and the data image is deleted with the bare-metal host as expected. (link:https://issues.redhat.com/browse/OCPBUGS-42387[OCPBUGS-42387]) [id="ocp-4-17-21-updating_{context}"] ==== Updating @@ -3048,19 +3048,19 @@ $ oc adm release info 4.17.20 --pullspecs [id="ocp-4-17-20-bug-fixes_{context}"] ==== Bug fixes -* Previously, Local Storage Operator (LSO) ignored existing Small Computer System Interface (SCSI) symlinks during persistent volumes (PV) creation. With this release, the LSO no longer ignores these symlinks because it gathers these symlinks before finding new symlinks when creating a PV. (link:https://issues.redhat.com/browse/OCPBUGS-51291[*OCPBUGS-51291*]) +* Previously, Local Storage Operator (LSO) ignored existing Small Computer System Interface (SCSI) symlinks during persistent volumes (PV) creation. With this release, the LSO no longer ignores these symlinks because it gathers these symlinks before finding new symlinks when creating a PV. (link:https://issues.redhat.com/browse/OCPBUGS-51291[OCPBUGS-51291]) -* Previously, when the OVN-Kubernetes network plugin and the Kubernetes-NMState Operator interacted with each other, unexpected connection profiles persisted on disk storage. These connection profiles sometimes caused the `ovs-configuration` service to fail when restarted. With this release, the unnecessary connection profiles are now cleaned before the `ovs-configuration` starts so that this issue no longer occurs. (link:https://issues.redhat.com/browse/OCPBUGS-52257[*OCPBUGS-52257*]) +* Previously, when the OVN-Kubernetes network plugin and the Kubernetes-NMState Operator interacted with each other, unexpected connection profiles persisted on disk storage. These connection profiles sometimes caused the `ovs-configuration` service to fail when restarted. With this release, the unnecessary connection profiles are now cleaned before the `ovs-configuration` starts so that this issue no longer occurs. (link:https://issues.redhat.com/browse/OCPBUGS-52257[OCPBUGS-52257]) -* Previously, the `vmware-vsphere-csi-driver-operator` Container Storage Interface (CSI) driver entered panic mode when the {vmw-full} vCenter address was incorrect or missing. With this release, the CSI driver does not go into panic mode if the {vmw-full} vCenter address is incorrect or missing. (link:https://issues.redhat.com/browse/OCPBUGS-52207[*OCPBUGS-52207*]) +* Previously, the `vmware-vsphere-csi-driver-operator` Container Storage Interface (CSI) driver entered panic mode when the {vmw-full} vCenter address was incorrect or missing. With this release, the CSI driver does not go into panic mode if the {vmw-full} vCenter address is incorrect or missing. (link:https://issues.redhat.com/browse/OCPBUGS-52207[OCPBUGS-52207]) -* Previously, the *Cluster Settings* page would not properly render during a cluster update if the `ClusterVersion` did not receive a `Completed` update. With this release, the *Cluster Setting* page properly renders even if the `ClusterVersion` has not received a `Completed` update. (link:https://issues.redhat.com/browse/OCPBUGS-51292[*OCPBUGS-51292*]) +* Previously, the *Cluster Settings* page would not properly render during a cluster update if the `ClusterVersion` did not receive a `Completed` update. With this release, the *Cluster Setting* page properly renders even if the `ClusterVersion` has not received a `Completed` update. (link:https://issues.redhat.com/browse/OCPBUGS-51292[OCPBUGS-51292]) -* Previously, the alerts links on the *Alert rules* page of the *Developer* perspective included external labels to invalid links. This happened because the URL for the *Alerts* page did not expect external labels. With this release, the external labels are no longer added to the alerts URL on the *Alert rules* page so the alerts links are accurate. (link:https://issues.redhat.com/browse/OCPBUGS-51126[*OCPBUGS-51126*]) +* Previously, the alerts links on the *Alert rules* page of the *Developer* perspective included external labels to invalid links. This happened because the URL for the *Alerts* page did not expect external labels. With this release, the external labels are no longer added to the alerts URL on the *Alert rules* page so the alerts links are accurate. (link:https://issues.redhat.com/browse/OCPBUGS-51126[OCPBUGS-51126]) -* Previously, for a `kubevirt-csi` pod that ran on a node in a hosted cluster, the persistent volume claim (PVC) from the hosted cluster was removed from the virtual machine (VM) after the VM was rebooted. However, the `VolumeAttachment` resource was not removed and this caused issues for the cluster as it expected the PVC to be attached to the VM. With this release, after a VM is rebooted, the `VolumeAttachment` resource is removed so that the cluster issues no longer occur. (link:https://issues.redhat.com/browse/OCPBUGS-44623[*OCPBUGS-44623*]) +* Previously, for a `kubevirt-csi` pod that ran on a node in a hosted cluster, the persistent volume claim (PVC) from the hosted cluster was removed from the virtual machine (VM) after the VM was rebooted. However, the `VolumeAttachment` resource was not removed and this caused issues for the cluster as it expected the PVC to be attached to the VM. With this release, after a VM is rebooted, the `VolumeAttachment` resource is removed so that the cluster issues no longer occur. (link:https://issues.redhat.com/browse/OCPBUGS-44623[OCPBUGS-44623]) -* Previously, in bare-metal configurations where the provisioning network was disabled but the `bootstrapProvisioningIP` field was set, the bare-metal provisioning components would fail to start. These failures occur when the provisioning process reconfigures the external network interface on the bootstrap VM during the process of pulling container images. With this release, dependencies are added to ensure that interface reconfiguration only occurs when the network is idle, preventing conflicts with other processes. As a result, the bare-metal provisioning components now start reliably, even when the `bootstrapProvisioningIP` field is set and the provisioning network is disabled. (link:https://issues.redhat.com/browse/OCPBUGS-43528[*OCPBUGS-43528*]) +* Previously, in bare-metal configurations where the provisioning network was disabled but the `bootstrapProvisioningIP` field was set, the bare-metal provisioning components would fail to start. These failures occur when the provisioning process reconfigures the external network interface on the bootstrap VM during the process of pulling container images. With this release, dependencies are added to ensure that interface reconfiguration only occurs when the network is idle, preventing conflicts with other processes. As a result, the bare-metal provisioning components now start reliably, even when the `bootstrapProvisioningIP` field is set and the provisioning network is disabled. (link:https://issues.redhat.com/browse/OCPBUGS-43528[OCPBUGS-43528]) [id="ocp-4-17-20-updating_{context}"] ==== Updating @@ -3086,17 +3086,17 @@ $ oc adm release info 4.17.19 --pullspecs [id="ocp-4-17-19-bug-fixes_{context}"] ==== Bug fixes -* Previously, when the OpenShift cluster was created with a secure proxy enabled, and the certificate was set in `configuration.proxy.trustCA`, the cluster failed to complete provisioning. With this release, you can create a cluster with secure proxy enabled with the certificate set in `configuration.proxy.trustCA`. Also, the fix prevents an issue that prevented `oauth` from connecting to Cloud APIs using the management cluster proxy. (link:https://issues.redhat.com/browse/OCPBUGS-51098[*OCPBUGS-51098*]) +* Previously, when the OpenShift cluster was created with a secure proxy enabled, and the certificate was set in `configuration.proxy.trustCA`, the cluster failed to complete provisioning. With this release, you can create a cluster with secure proxy enabled with the certificate set in `configuration.proxy.trustCA`. Also, the fix prevents an issue that prevented `oauth` from connecting to Cloud APIs using the management cluster proxy. (link:https://issues.redhat.com/browse/OCPBUGS-51098[OCPBUGS-51098]) -* Previously, when you deleted a Dynamic Host Configuration Protocol (DHCP) network on an {ibm-power-server-title} cluster, subresources still existed. With this release, when you delete a DHCP network, the subresources deletion occurs before continuing with the delete operation. (link:https://issues.redhat.com/browse/OCPBUGS-50967[*OCPBUGS-50967*]) +* Previously, when you deleted a Dynamic Host Configuration Protocol (DHCP) network on an {ibm-power-server-title} cluster, subresources still existed. With this release, when you delete a DHCP network, the subresources deletion occurs before continuing with the delete operation. (link:https://issues.redhat.com/browse/OCPBUGS-50967[OCPBUGS-50967]) -* Previously, when a worker node tried to join a cluster, the rendezvous node rebooted before the process completed. Because the worker node could not communicate with the rendezvous node, the installation was not successful. With this release, a patch is applied that fixes the racing condition that caused the rendezvous node to reboot prematurely and the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-50011[*OCPBUGS-50011*]) +* Previously, when a worker node tried to join a cluster, the rendezvous node rebooted before the process completed. Because the worker node could not communicate with the rendezvous node, the installation was not successful. With this release, a patch is applied that fixes the racing condition that caused the rendezvous node to reboot prematurely and the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-50011[OCPBUGS-50011]) -* Previously, the DNS-based egress firewall incorrectly disallowed creation of rules containing DNS names in uppercase. With this release, the issue is fixed and the egress firewall is created with uppercase DNS names. (link:https://issues.redhat.com/browse/OCPBUGS-49961[*OCPBUGS-49961*]) +* Previously, the DNS-based egress firewall incorrectly disallowed creation of rules containing DNS names in uppercase. With this release, the issue is fixed and the egress firewall is created with uppercase DNS names. (link:https://issues.redhat.com/browse/OCPBUGS-49961[OCPBUGS-49961]) -* Previously, all host validation status logs referred to the name of the first host registered. When a host validation failed, it was not possible to decide the host with an issue. With this release, the correct host is identified in each log message and the host validation logs correctly how the host that they are linked to. (link:https://issues.redhat.com/browse/OCPBUGS-44058[*OCPBUGS-44058*]) +* Previously, all host validation status logs referred to the name of the first host registered. When a host validation failed, it was not possible to decide the host with an issue. With this release, the correct host is identified in each log message and the host validation logs correctly how the host that they are linked to. (link:https://issues.redhat.com/browse/OCPBUGS-44058[OCPBUGS-44058]) -* Previously, when the {vmw-first} vCenter cluster contained an ESXi host that did not have a standard port group defined and the installation program tried to select that host to import the Open Virtual Appliance (OVA), the import failed and the error `Invalid Configuration for device 0` was reported. With this release, the installation program verifies whether a standard port group for an ESXi host is defined and, if not, continues verifying until it locates an ESXi host with a defined standard port group, or reports an error message if it fails to locate one. (link:https://issues.redhat.com/browse/OCPBUGS-37945[*OCPBUGS-37945*]) +* Previously, when the {vmw-first} vCenter cluster contained an ESXi host that did not have a standard port group defined and the installation program tried to select that host to import the Open Virtual Appliance (OVA), the import failed and the error `Invalid Configuration for device 0` was reported. With this release, the installation program verifies whether a standard port group for an ESXi host is defined and, if not, continues verifying until it locates an ESXi host with a defined standard port group, or reports an error message if it fails to locate one. (link:https://issues.redhat.com/browse/OCPBUGS-37945[OCPBUGS-37945]) [id="ocp-4-17-19-updating_{context}"] ==== Updating @@ -3122,13 +3122,13 @@ $ oc adm release info 4.17.18 --pullspecs [id="ocp-4-17-18-bug-fixes_{context}"] ==== Bug fixes -* Previously, the control plane Operator did not honor the set PROXY environment variables when it checked the API endpoint availability. With this release, the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-50596[*OCPBUGS-50596*]) +* Previously, the control plane Operator did not honor the set PROXY environment variables when it checked the API endpoint availability. With this release, the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-50596[OCPBUGS-50596]) -* Previously, when installing a cluster on {aws-first} in existing subnets that were located in edge zones, such as a AWS Local Zone or a Wavelength Zone, the `kubernetes.io/cluster/:shared` tag was missing in the subnet resources of the edge zone. With this release, a fix ensures that all subnets that are used in the `install-config.yaml` configuration file have the required tag. (link:https://issues.redhat.com/browse/OCPBUGS-49975[*OCPBUGS-49975*]) +* Previously, when installing a cluster on {aws-first} in existing subnets that were located in edge zones, such as a AWS Local Zone or a Wavelength Zone, the `kubernetes.io/cluster/:shared` tag was missing in the subnet resources of the edge zone. With this release, a fix ensures that all subnets that are used in the `install-config.yaml` configuration file have the required tag. (link:https://issues.redhat.com/browse/OCPBUGS-49975[OCPBUGS-49975]) -* Previously, incorrect addresses were being passed to the Kubernetes `EndpointSlice` on a cluster, and this issue prevented the installation of the MetalLB Operator on an Agent-based cluster in an IPv6 disconnected environment. With this release, a fix modifies the address evaluation method. Red{nbsp}Hat Marketplace pods can now successfully connect to the cluster API server, so that the installation of MetalLB Operator and handling of ingress traffic in IPv6 disconnected environments can occur. (link:https://issues.redhat.com/browse/OCPBUGS-46665[*OCPBUGS-46665*]) +* Previously, incorrect addresses were being passed to the Kubernetes `EndpointSlice` on a cluster, and this issue prevented the installation of the MetalLB Operator on an Agent-based cluster in an IPv6 disconnected environment. With this release, a fix modifies the address evaluation method. Red{nbsp}Hat Marketplace pods can now successfully connect to the cluster API server, so that the installation of MetalLB Operator and handling of ingress traffic in IPv6 disconnected environments can occur. (link:https://issues.redhat.com/browse/OCPBUGS-46665[OCPBUGS-46665]) -* Previously, the method to validate the container image architecture did not go through the image metadata provider. As a consequence, the image overrides did not take effect. With this release, the methods on the image metadata provider were modified to allow multi-architecture validations, and those methods were propagated through all components for image validation steps. As a result, the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-46664[*OCPBUGS-46664*]) +* Previously, the method to validate the container image architecture did not go through the image metadata provider. As a consequence, the image overrides did not take effect. With this release, the methods on the image metadata provider were modified to allow multi-architecture validations, and those methods were propagated through all components for image validation steps. As a result, the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-46664[OCPBUGS-46664]) [id="ocp-4-17-18-updating_{context}"] ==== Updating @@ -3154,9 +3154,9 @@ $ oc adm release info 4.17.17 --pullspecs [id="ocp-4-17-17-bug-fixes_{context}"] ==== Bug fixes -* Previously, the availability set fault domain count was hardcoded to `2`. This value works in most regions on {azure-first} because the fault domain counts are typically at least `2`, but failed in the `centraluseuap` and `eastusstg` regions. With this release, the availability set fault domain count in a region is set dynamically so that this issue no longer occurs. (link:https://issues.redhat.com/browse/OCPBUGS-50017[*OCPBUGS-50017*]) +* Previously, the availability set fault domain count was hardcoded to `2`. This value works in most regions on {azure-first} because the fault domain counts are typically at least `2`, but failed in the `centraluseuap` and `eastusstg` regions. With this release, the availability set fault domain count in a region is set dynamically so that this issue no longer occurs. (link:https://issues.redhat.com/browse/OCPBUGS-50017[OCPBUGS-50017]) -* Previously, when installing a cluster on {gcp-first}, a cluster installation failed when an instance required IP Forwarding to be disabled. With this release, IP Forwarding is disabled for all {gcp-short} machines before cluster installation so that the cluster installation issue no longer occurs. (link:https://issues.redhat.com/browse/OCPBUGS-49993[*OCPBUGS-49993*]) +* Previously, when installing a cluster on {gcp-first}, a cluster installation failed when an instance required IP Forwarding to be disabled. With this release, IP Forwarding is disabled for all {gcp-short} machines before cluster installation so that the cluster installation issue no longer occurs. (link:https://issues.redhat.com/browse/OCPBUGS-49993[OCPBUGS-49993]) // SME * Previously, you could not install an cluster on {aws-short} in the `ap-southeast-5` region or other regions because the {product-title} internal registry did not support these regions. With this release, the internal registry is updated to include the following regions so that this issue no longer occurs: @@ -3167,11 +3167,11 @@ $ oc adm release info 4.17.17 --pullspecs ** `il-central-1` ** `mx-central-1` + -(link:https://issues.redhat.com/browse/OCPBUGS-49695[*OCPBUGS-49695*]) +(link:https://issues.redhat.com/browse/OCPBUGS-49695[OCPBUGS-49695]) -* Previously, when a pod was running on a node on which egress IPv6 is assigned, the pod was not able to communicate with the Kubernetes service in a dual-stack cluster. This resulted in traffic with the IP family, that the `egressIP` object is not applicable to, being dropped. With this release, only the source network address translation (SNAT) for the IP family that the egress IP applied to is deleted, eliminating the risk of traffic being dropped. (link:https://issues.redhat.com/browse/OCPBUGS-48828[*OCPBUGS-48828*]) +* Previously, when a pod was running on a node on which egress IPv6 is assigned, the pod was not able to communicate with the Kubernetes service in a dual-stack cluster. This resulted in traffic with the IP family, that the `egressIP` object is not applicable to, being dropped. With this release, only the source network address translation (SNAT) for the IP family that the egress IP applied to is deleted, eliminating the risk of traffic being dropped. (link:https://issues.redhat.com/browse/OCPBUGS-48828[OCPBUGS-48828]) -* Previously, when you attempted to use the {hcp} CLI to create a cluster in a disconnected environment, the installation command failed. An issue existed with the registry that hosts the command. With this release, a fix to the command registry means that you can use the {hcp} CLI to create a cluster in a disconnected environment. (link:https://issues.redhat.com/browse/OCPBUGS-48170[*OCPBUGS-48170*]) +* Previously, when you attempted to use the {hcp} CLI to create a cluster in a disconnected environment, the installation command failed. An issue existed with the registry that hosts the command. With this release, a fix to the command registry means that you can use the {hcp} CLI to create a cluster in a disconnected environment. (link:https://issues.redhat.com/browse/OCPBUGS-48170[OCPBUGS-48170]) [id="ocp-4-17-17-updating_{context}"] ==== Updating @@ -3197,19 +3197,19 @@ $ oc adm release info 4.17.16 --pullspecs [id="ocp-4-17-16-bug-fixes_{context}"] ==== Bug fixes -* Previously, the Bare Metal Operator (BMO) created the `HostFirmwareComponents` custom resource for all Bare-metal hosts (BMH), including ones based on the intelligent platform management interface (IPMI), which did not support it. With this release, `HostFirmwareComponents` custom resources are only created for BMH that support it. (link:https://issues.redhat.com/browse/OCPBUGS-49701[*OCPBUGS-49701*]) +* Previously, the Bare Metal Operator (BMO) created the `HostFirmwareComponents` custom resource for all Bare-metal hosts (BMH), including ones based on the intelligent platform management interface (IPMI), which did not support it. With this release, `HostFirmwareComponents` custom resources are only created for BMH that support it. (link:https://issues.redhat.com/browse/OCPBUGS-49701[OCPBUGS-49701]) -* Previously, importing manifest lists could cause an API crash if the source registry returned an invalid sub-manifest result. With this update, the API flags an error on the imported tag instead of crashing. (link:https://issues.redhat.com/browse/OCPBUGS-49399[*OCPBUGS-49399*]) +* Previously, importing manifest lists could cause an API crash if the source registry returned an invalid sub-manifest result. With this update, the API flags an error on the imported tag instead of crashing. (link:https://issues.redhat.com/browse/OCPBUGS-49399[OCPBUGS-49399]) * Previously, the Konnectivity proxy used by the `openshift-apiserver` in the control plane resolved registry names with cloud API suffixes on the control plane and then attempted to access them through the data plane. + -A hosted cluster that used the no-egress feature in ROSA, and a container registry that was accessible through an Amazon Virtual Private Cloud (VPC) endpoint was created but failed to install because `imagestreams` that use the container registry did not resolve. With this release, the Konnectivity proxy resolves and routes hostnames consistently. (link:https://issues.redhat.com/browse/OCPBUGS-46465[*OCPBUGS-46465*]) +A hosted cluster that used the no-egress feature in ROSA, and a container registry that was accessible through an Amazon Virtual Private Cloud (VPC) endpoint was created but failed to install because `imagestreams` that use the container registry did not resolve. With this release, the Konnectivity proxy resolves and routes hostnames consistently. (link:https://issues.redhat.com/browse/OCPBUGS-46465[OCPBUGS-46465]) -* Previously, if you ran a build that required a trust bundle to access registries, it did not pick up the bundle configured in the cluster proxy. The builds failed if they referenced a registry required for a custom trust bundle. With this release, builds that require the trust bundle specified in the proxy configuration succeed, and the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-45268[*OCPBUGS-45268*]) +* Previously, if you ran a build that required a trust bundle to access registries, it did not pick up the bundle configured in the cluster proxy. The builds failed if they referenced a registry required for a custom trust bundle. With this release, builds that require the trust bundle specified in the proxy configuration succeed, and the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-45268[OCPBUGS-45268]) -* Previously, when you attempted to use the {hcp} CLI to create a {hcp} cluster, the installation failed because of a release image check on multi-arch images. With this release, an update to the {hcp} CLI codebase fixes the issue so that the release image check does not fail when checking for multi-arch images. (link:https://issues.redhat.com/browse/OCPBUGS-44927[*OCPBUGS-44927*]) +* Previously, when you attempted to use the {hcp} CLI to create a {hcp} cluster, the installation failed because of a release image check on multi-arch images. With this release, an update to the {hcp} CLI codebase fixes the issue so that the release image check does not fail when checking for multi-arch images. (link:https://issues.redhat.com/browse/OCPBUGS-44927[OCPBUGS-44927]) -* Previously, installing an {aws-short} cluster in either the Commercial Cloud Services (C2S) region or the Secret Commercial Cloud Services (SC2S) region failed because the installation program added unsupported security groups to the load balancer. With this release, the installation program no longer adds unsupported security groups to the load balancer for a cluster that needs to be installed in either the C2S region or SC2S region. (link:https://issues.redhat.com/browse/OCPBUGS-42763[*OCPBUGS-42763*]) +* Previously, installing an {aws-short} cluster in either the Commercial Cloud Services (C2S) region or the Secret Commercial Cloud Services (SC2S) region failed because the installation program added unsupported security groups to the load balancer. With this release, the installation program no longer adds unsupported security groups to the load balancer for a cluster that needs to be installed in either the C2S region or SC2S region. (link:https://issues.redhat.com/browse/OCPBUGS-42763[OCPBUGS-42763]) [id="ocp-4-17-16-updating_{context}"] ==== Updating @@ -3235,11 +3235,11 @@ $ oc adm release info 4.17.15 --pullspecs [id="ocp-4-17-15-bug-fixes_{context}"] ==== Bug fixes -* Previously, when you used the installation program to install a cluster in a Prism Central environment, the installation failed because a `prism-api` call that loads an {op-system} image timed out. This issue happened because the `prismAPICallTimeout` parameter was set to `5` minutes. With this release, the `prismAPICallTimeout` parameter in the `install-config.yaml` configuration file now defaults to `10` minutes. You can also configure the parameter if you need a longer timeout for a `prism-api` call. (link:https://issues.redhat.com/browse/OCPBUGS-49362[*OCPBUGS-49362*]) +* Previously, when you used the installation program to install a cluster in a Prism Central environment, the installation failed because a `prism-api` call that loads an {op-system} image timed out. This issue happened because the `prismAPICallTimeout` parameter was set to `5` minutes. With this release, the `prismAPICallTimeout` parameter in the `install-config.yaml` configuration file now defaults to `10` minutes. You can also configure the parameter if you need a longer timeout for a `prism-api` call. (link:https://issues.redhat.com/browse/OCPBUGS-49362[OCPBUGS-49362]) -* Previously, every time a subcription was reconciled, the {olm} catalog Operator requested a full view of the catalog metadata from the catalog source pod of the subscription. These requests caused performance issues for the catalog pods. With this release, the {olm} catalog Operator now uses a local cache that is refreshed periodically and reused by all subscription reconciliations, so that the performance issue for the catalog pods no longer persists. (link:https://issues.redhat.com/browse/OCPBUGS-48695[*OCPBUGS-48695*]) +* Previously, every time a subcription was reconciled, the {olm} catalog Operator requested a full view of the catalog metadata from the catalog source pod of the subscription. These requests caused performance issues for the catalog pods. With this release, the {olm} catalog Operator now uses a local cache that is refreshed periodically and reused by all subscription reconciliations, so that the performance issue for the catalog pods no longer persists. (link:https://issues.redhat.com/browse/OCPBUGS-48695[OCPBUGS-48695]) -* Previously, if you specified a `forceSelinuxRelabel` field in the `ClusterResourceOverride` CR and then modified the CR at a later stage, the Cluster Resource Override Operator did not apply the update to the associated `ConfigMap` resource. This `ConfigMap` resource is important for an SELinux relabeling feature, `forceSelinuxRelabel`. With this release, the Cluster Resource Override Operator now applies and tracks any `ClusterResourceOverride` CR changes to the `ConfigMap` resource. (link:https://issues.redhat.com/browse/OCPBUGS-48691[*OCPBUGS-48691*]) +* Previously, if you specified a `forceSelinuxRelabel` field in the `ClusterResourceOverride` CR and then modified the CR at a later stage, the Cluster Resource Override Operator did not apply the update to the associated `ConfigMap` resource. This `ConfigMap` resource is important for an SELinux relabeling feature, `forceSelinuxRelabel`. With this release, the Cluster Resource Override Operator now applies and tracks any `ClusterResourceOverride` CR changes to the `ConfigMap` resource. (link:https://issues.redhat.com/browse/OCPBUGS-48691[OCPBUGS-48691]) [id="ocp-4-17-15-updating_{context}"] ==== Updating @@ -3265,22 +3265,22 @@ $ oc adm release info 4.17.14 --pullspecs [id="ocp-4-17-14-bug-fixes_{context}"] ==== Bug fixes -* Previously, some cluster autoscaler metrics were not initialized and were unavailable. With this release, the cluster autoscaler metrics are initialized and available. (link:https://issues.redhat.com/browse/OCPBUGS-48606[*OCPBUGS-48606*]) +* Previously, some cluster autoscaler metrics were not initialized and were unavailable. With this release, the cluster autoscaler metrics are initialized and available. (link:https://issues.redhat.com/browse/OCPBUGS-48606[OCPBUGS-48606]) -* Previously, you could not add a new worker by using the `oc adm node-image create` command if the node date or time was inaccurate. With this release, the issue is resolved by applying the same NTP configuration that is in the target cluster `machineconfig chrony` resource to the node ephemeral live environment. (link:https://issues.redhat.com/browse/OCPBUGS-45344[*OCPBUGS-45344*]) +* Previously, you could not add a new worker by using the `oc adm node-image create` command if the node date or time was inaccurate. With this release, the issue is resolved by applying the same NTP configuration that is in the target cluster `machineconfig chrony` resource to the node ephemeral live environment. (link:https://issues.redhat.com/browse/OCPBUGS-45344[OCPBUGS-45344]) -* Previously, you could not use all available machine types in a zone because all zones in a region were assumed to have the same set of machine types. With this release, all machine types are available in all enabled zones. (link:https://issues.redhat.com/browse/OCPBUGS-46432[*OCPBUGS-46432*]) +* Previously, you could not use all available machine types in a zone because all zones in a region were assumed to have the same set of machine types. With this release, all machine types are available in all enabled zones. (link:https://issues.redhat.com/browse/OCPBUGS-46432[OCPBUGS-46432]) -* Previously, the installation program was not compliant with PCI-DSS/BAFIN regulations. With this release, the cross-tenant replication in {azure-first} is disabled, which reduces the chance of unauthorized data access and ensures strict adherence to data governance policies. (link:https://issues.redhat.com/browse/OCPBUGS-48119[*OCPBUGS-48119*]) +* Previously, the installation program was not compliant with PCI-DSS/BAFIN regulations. With this release, the cross-tenant replication in {azure-first} is disabled, which reduces the chance of unauthorized data access and ensures strict adherence to data governance policies. (link:https://issues.redhat.com/browse/OCPBUGS-48119[OCPBUGS-48119]) -* Previously, when you clicked the *Don't show again* link in the Red Hat Ansible Lightspeed modal, it did not display the correct *General User Preference* tab when one of the other *User Preference* tabs was open. With this release, clicking the *Don't show again* link goes to the correct *General User Preference* tab. (link:https://issues.redhat.com/browse/OCPBUGS-48227[*OCPBUGS-48227*]) +* Previously, when you clicked the *Don't show again* link in the Red Hat Ansible Lightspeed modal, it did not display the correct *General User Preference* tab when one of the other *User Preference* tabs was open. With this release, clicking the *Don't show again* link goes to the correct *General User Preference* tab. (link:https://issues.redhat.com/browse/OCPBUGS-48227[OCPBUGS-48227]) -* Previously, when a Google Cloud Platform (GCP) service account was created, the account would not always be immediately available. When the account was not available for updates, the installation program received failures when adding permissions to the account. According to link:https://cloud.google.com/iam/docs/retry-strategy[*Retry failed requests*], a service account might be created, but is not active for up to 60 seconds. With this release, the service account is updated on an exponential backoff to give the account enough time to update correctly. (link:https://issues.redhat.com/browse/OCPBUGS-48359[*OCPBUGS-48359*]) +* Previously, when a Google Cloud Platform (GCP) service account was created, the account would not always be immediately available. When the account was not available for updates, the installation program received failures when adding permissions to the account. According to link:https://cloud.google.com/iam/docs/retry-strategy[*Retry failed requests*], a service account might be created, but is not active for up to 60 seconds. With this release, the service account is updated on an exponential backoff to give the account enough time to update correctly. (link:https://issues.redhat.com/browse/OCPBUGS-48359[OCPBUGS-48359]) * Previously, on RHEL 9 FIPS STIG compliant machines, The SHA-1 key caused the release signature verification to fail because of the restriction to use weak keys. -With this release, the key used by the oc-mirror plugin for release signature verification is changed and release images are signed by a new SHA256 trusted-key that is different from the old SHA-1 key. (link:https://issues.redhat.com/browse/OCPBUGS-48363[*OCPBUGS-48363*]) +With this release, the key used by the oc-mirror plugin for release signature verification is changed and release images are signed by a new SHA256 trusted-key that is different from the old SHA-1 key. (link:https://issues.redhat.com/browse/OCPBUGS-48363[OCPBUGS-48363]) -* Previously, the {olm-first} would sometimes concurrently resolve the same namespace in a cluster. This led to subscriptions reaching a terminal state of `ConstraintsNotSatisfiable`, because two concurrent processes interacted with a subscription and this caused a CSV file to become unassociated. With this release, {olm} can resolve concurrent namespaces for a subscription so no CSV remains unassociated. (link:https://issues.redhat.com/browse/OCPBUGS-45845[*OCPBUGS-45845*]) +* Previously, the {olm-first} would sometimes concurrently resolve the same namespace in a cluster. This led to subscriptions reaching a terminal state of `ConstraintsNotSatisfiable`, because two concurrent processes interacted with a subscription and this caused a CSV file to become unassociated. With this release, {olm} can resolve concurrent namespaces for a subscription so no CSV remains unassociated. (link:https://issues.redhat.com/browse/OCPBUGS-45845[OCPBUGS-45845]) [id="ocp-4-17-14-updating_{context}"] ==== Updating @@ -3336,15 +3336,15 @@ For more information, see xref:../storage/container_storage_interface/persistent [id="ocp-4-17-11-bug-fixes_{context}"] ==== Bug fixes -* Previously, the certificate signing request (CSR) approver included certificates from other systems when it calculated if it should stop approving certificates when the system was overloaded. In larger clusters, where other subsystems used CSRs, the CSR approver determined that there were many unapproved CSRs and prevented additional approvals. With this release, the CSR approver prevents new approvals when there are many CSRs for the `signerName` values that it observes, but has not been able to approve. The CSR approver now only includes CSRs that it can approve, using the `signerName` property as a filter. (link:https://issues.redhat.com/browse/OCPBUGS-46429[*OCPBUGS-46429*]) +* Previously, the certificate signing request (CSR) approver included certificates from other systems when it calculated if it should stop approving certificates when the system was overloaded. In larger clusters, where other subsystems used CSRs, the CSR approver determined that there were many unapproved CSRs and prevented additional approvals. With this release, the CSR approver prevents new approvals when there are many CSRs for the `signerName` values that it observes, but has not been able to approve. The CSR approver now only includes CSRs that it can approve, using the `signerName` property as a filter. (link:https://issues.redhat.com/browse/OCPBUGS-46429[OCPBUGS-46429]) -* Previously, a hard eviction of a pod in a node caused a pod to enter a termination grace period instead of instantly shutting down and deleted by the kubelet. Each pod that enters a termination grace period exhausts the node resources. With this release, a bug fix ensures that a pod enters a one-second termination grace period so the kubelet can shut down and then delete the pod. (link:https://issues.redhat.com/browse/OCPBUGS-46364[*OCPBUGS-46364*]) +* Previously, a hard eviction of a pod in a node caused a pod to enter a termination grace period instead of instantly shutting down and deleted by the kubelet. Each pod that enters a termination grace period exhausts the node resources. With this release, a bug fix ensures that a pod enters a one-second termination grace period so the kubelet can shut down and then delete the pod. (link:https://issues.redhat.com/browse/OCPBUGS-46364[OCPBUGS-46364]) -* Previously, the permissions `ec2:AllocateAddress` and `ec2:AssociateAddress` were not verified when the `PublicIpv4Pool` feature was used, which resulted in permission failures during the installation. With this release, the required permissions are validated before the cluster is installed. (link:https://issues.redhat.com/browse/OCPBUGS-46360[*OCPBUGS-46360*]) +* Previously, the permissions `ec2:AllocateAddress` and `ec2:AssociateAddress` were not verified when the `PublicIpv4Pool` feature was used, which resulted in permission failures during the installation. With this release, the required permissions are validated before the cluster is installed. (link:https://issues.redhat.com/browse/OCPBUGS-46360[OCPBUGS-46360]) -* Previously, users could enter an invalid string for any CPU set in the performance profile, resulting in a broken cluster. With this release, the fix ensures that only valid strings can be entered, eliminating the risk of cluster breakage. (link:https://issues.redhat.com/browse/OCPBUGS-45964[*OCPBUGS-45964*]) +* Previously, users could enter an invalid string for any CPU set in the performance profile, resulting in a broken cluster. With this release, the fix ensures that only valid strings can be entered, eliminating the risk of cluster breakage. (link:https://issues.redhat.com/browse/OCPBUGS-45964[OCPBUGS-45964]) -* Previously, in certain scenarios, an event was missed by the informer watch stream. If an object was deleted while this disconnection occurred, the informer returned an unexpected type, which caused a stale state. As a result, the incorrect returned type caused a problem. With this release, the unexpected types are correctly handled, and the temporary disconnection possibilities are successful. (link:https://issues.redhat.com/browse/OCPBUGS-46039[*OCPBUGS-46039*]) +* Previously, in certain scenarios, an event was missed by the informer watch stream. If an object was deleted while this disconnection occurred, the informer returned an unexpected type, which caused a stale state. As a result, the incorrect returned type caused a problem. With this release, the unexpected types are correctly handled, and the temporary disconnection possibilities are successful. (link:https://issues.redhat.com/browse/OCPBUGS-46039[OCPBUGS-46039]) [id="ocp-4-17-11-updating_{context}"] ==== Updating @@ -3373,34 +3373,34 @@ $ oc adm release info 4.17.10 --pullspecs [id="ocp-4-17-10-node-tuning-operator_{context}"] ===== Node Tuning Operator architecture detection -The Node Tuning Operator can now properly select kernel arguments and management options for Intel and AMD CPUs. (link:https://issues.redhat.com/browse/OCPBUGS-43664[*OCPBUGS-43664*]) +The Node Tuning Operator can now properly select kernel arguments and management options for Intel and AMD CPUs. (link:https://issues.redhat.com/browse/OCPBUGS-43664[OCPBUGS-43664]) [id="ocp-4-17-10-bug-fixes_{context}"] ==== Bug fixes -* Previously, when the webhook token authenticator was enabled and had the authorization type set to `None`, the {product-title} web console would consistently crash. With this release, a bug fix ensures that this configuration does not cause the {product-title} web console to crash. (link:https://issues.redhat.com/browse/OCPBUGS-46390[*OCPBUGS-46390*]) +* Previously, when the webhook token authenticator was enabled and had the authorization type set to `None`, the {product-title} web console would consistently crash. With this release, a bug fix ensures that this configuration does not cause the {product-title} web console to crash. (link:https://issues.redhat.com/browse/OCPBUGS-46390[OCPBUGS-46390]) -* Previously, the `SiteConfig` custom resource (CR) configuration, which configures ingress rules and sevices for a cluster, caused the `BareMetalHost` CR to remain in a deleted state instead of being deleted as part of the cluster cleanup operation. With this release, this issue no longer occurs provided that you update to the GitOps Operator to version 1.13 or a later version. (link:https://issues.redhat.com/browse/OCPBUGS-46071[*OCPBUGS-46071*]) +* Previously, the `SiteConfig` custom resource (CR) configuration, which configures ingress rules and sevices for a cluster, caused the `BareMetalHost` CR to remain in a deleted state instead of being deleted as part of the cluster cleanup operation. With this release, this issue no longer occurs provided that you update to the GitOps Operator to version 1.13 or a later version. (link:https://issues.redhat.com/browse/OCPBUGS-46071[OCPBUGS-46071]) -* Previously, when you attempted to use {olm-first} to upgrade an Operator, the upgrade was blocked and an `error validating existing CRs against new CRD's schema` message was generated. An issue existed with {olm}, whereby {olm} erroneously identified incompatibility issues validating existing custom resources (CRs) against the new Operator version's custom resource definitions (CRDs). With this release, the validation is corrected so that Operator upgrades are no longer blocked. (link:https://issues.redhat.com/browse/OCPBUGS-46054[*OCPBUGS-46054*]) +* Previously, when you attempted to use {olm-first} to upgrade an Operator, the upgrade was blocked and an `error validating existing CRs against new CRD's schema` message was generated. An issue existed with {olm}, whereby {olm} erroneously identified incompatibility issues validating existing custom resources (CRs) against the new Operator version's custom resource definitions (CRDs). With this release, the validation is corrected so that Operator upgrades are no longer blocked. (link:https://issues.redhat.com/browse/OCPBUGS-46054[OCPBUGS-46054]) -* Previously, a `PipelineRuns` CR that used a resolver could not be rerun on the {product-title} web console. If you attempted ro rerun the CR, an `Invalid PipelineRun configuration, unable to start Pipeline` message was generated. With this release, you can now rerun a `PipelineRuns` CR that uses resolver without experience this issue. (link:https://issues.redhat.com/browse/OCPBUGS-45949[*OCPBUGS-45949*]) +* Previously, a `PipelineRuns` CR that used a resolver could not be rerun on the {product-title} web console. If you attempted ro rerun the CR, an `Invalid PipelineRun configuration, unable to start Pipeline` message was generated. With this release, you can now rerun a `PipelineRuns` CR that uses resolver without experience this issue. (link:https://issues.redhat.com/browse/OCPBUGS-45949[OCPBUGS-45949]) -* Previously, when you used the *Form View* to edit `Deployment` or `DeploymentConfig` API objects on the {product-title} web console, duplicate `ImagePullSecrets` parameters existed in the YAML configuration for either object. With this release, a fix ensures that duplicate `ImagePullSecrets` parameters do not get automatically added for either object. (link:https://issues.redhat.com/browse/OCPBUGS-45948[*OCPBUGS-45948*]) +* Previously, when you used the *Form View* to edit `Deployment` or `DeploymentConfig` API objects on the {product-title} web console, duplicate `ImagePullSecrets` parameters existed in the YAML configuration for either object. With this release, a fix ensures that duplicate `ImagePullSecrets` parameters do not get automatically added for either object. (link:https://issues.redhat.com/browse/OCPBUGS-45948[OCPBUGS-45948]) -* Previously, the `aws-sdk-go-v2` software development kit (SDK) failed to authenticate an `AssumeRoleWithWebIdentity` API operation on an {aws-short} {sts-first} cluster. With this release, the pod identity webhook now includes a default region so that this issue no longer persists. (link:https://issues.redhat.com/browse/OCPBUGS-45938[*OCPBUGS-45938*]) +* Previously, the `aws-sdk-go-v2` software development kit (SDK) failed to authenticate an `AssumeRoleWithWebIdentity` API operation on an {aws-short} {sts-first} cluster. With this release, the pod identity webhook now includes a default region so that this issue no longer persists. (link:https://issues.redhat.com/browse/OCPBUGS-45938[OCPBUGS-45938]) -* Previously, installation of an {aws-short} cluster failed in certain environments on existing subnets when the `publicIp` parameter of the `MachineSet` object was explicity set to `false`. With this release, a fix ensures that a configuration value set for `publicIp` no longer causes issues when the installation program provisions machines for your {aws-short} cluster in certain environments. (link:https://issues.redhat.com/browse/OCPBUGS-45186[*OCPBUGS-45186*]) +* Previously, installation of an {aws-short} cluster failed in certain environments on existing subnets when the `publicIp` parameter of the `MachineSet` object was explicity set to `false`. With this release, a fix ensures that a configuration value set for `publicIp` no longer causes issues when the installation program provisions machines for your {aws-short} cluster in certain environments. (link:https://issues.redhat.com/browse/OCPBUGS-45186[OCPBUGS-45186]) -* Previously, an additional filtering property was passed into the component that is used to list operands on the *Operator details* page. The additional property caused the list to always be empty if it was extended by a dynamic plugin. With this release, the extra property has been removed so that available operands are listed as expected. (link:https://issues.redhat.com/browse/OCPBUGS-45667[*OCPBUGS-45667*]) +* Previously, an additional filtering property was passed into the component that is used to list operands on the *Operator details* page. The additional property caused the list to always be empty if it was extended by a dynamic plugin. With this release, the extra property has been removed so that available operands are listed as expected. (link:https://issues.redhat.com/browse/OCPBUGS-45667[OCPBUGS-45667]) -* Previously, when you ran the `oc adm node-image create` command, the command would sometimes fail and output an `image can't be pulled` error message. With this release, a fix adds a retry mechanism to the command so that if the command fails to pull images from a release workload, a retry operation ensures the command runs as expected. (link:https://issues.redhat.com/browse/OCPBUGS-45517[*OCPBUGS-45517*]) +* Previously, when you ran the `oc adm node-image create` command, the command would sometimes fail and output an `image can't be pulled` error message. With this release, a fix adds a retry mechanism to the command so that if the command fails to pull images from a release workload, a retry operation ensures the command runs as expected. (link:https://issues.redhat.com/browse/OCPBUGS-45517[OCPBUGS-45517]) -* Previously, an {ibm-power-server-name} cluster installation failed on installer-provisioned infrastructure because the installation program used a random network type instead of using of the specified network type that was specified in the `install-config.yaml` configuration file. With this release, the installation program now uses the network type that is specified in the `install-config.yaml` so that this issue no longer persists. (link:https://issues.redhat.com/browse/OCPBUGS-45484[*OCPBUGS-45484*]) +* Previously, an {ibm-power-server-name} cluster installation failed on installer-provisioned infrastructure because the installation program used a random network type instead of using of the specified network type that was specified in the `install-config.yaml` configuration file. With this release, the installation program now uses the network type that is specified in the `install-config.yaml` so that this issue no longer persists. (link:https://issues.redhat.com/browse/OCPBUGS-45484[OCPBUGS-45484]) * Previously, the Performance Profile Creator (PPC) failed to build a performance profile for compute nodes that had different core ID numbering (core per socket) for their logical processors and the nodes existed under the same node pool. For example, the PPC failed in a situation for two compute nodes that have logical processors `2` and `18`, where one node groups them as core ID `2` and the other node groups them as core ID `9`. + -With this release, PPC no longer fails to create the performance profile because PPC can now build a performance profile for a cluster that has compute nodes that each have different core ID numbering for their logical processors. The PPC now outputs a warning message that indicates to use the generated performance profile with caution, because different core ID numbering might impact system optimization and isolated management of tasks. (link:https://issues.redhat.com/browse/OCPBUGS-44644[*OCPBUGS-44644*]) +With this release, PPC no longer fails to create the performance profile because PPC can now build a performance profile for a cluster that has compute nodes that each have different core ID numbering for their logical processors. The PPC now outputs a warning message that indicates to use the generated performance profile with caution, because different core ID numbering might impact system optimization and isolated management of tasks. (link:https://issues.redhat.com/browse/OCPBUGS-44644[OCPBUGS-44644]) [id="ocp-4-17-10-updating_{context}"] ==== Updating @@ -3426,30 +3426,30 @@ $ oc adm release info 4.17.9 --pullspecs [id="ocp-4-17-9-known-issues_{context}"] ==== Known issues -* If you plan to deploy the NUMA Resources Operator, avoid using {product-title} versions 4.17.7 or 4.17.8. (link:https://issues.redhat.com/browse/OCPBUGS-45639[*OCPBUGS-45639*]) +* If you plan to deploy the NUMA Resources Operator, avoid using {product-title} versions 4.17.7 or 4.17.8. (link:https://issues.redhat.com/browse/OCPBUGS-45639[OCPBUGS-45639]) [id="ocp-4-17-9-bug-fixes_{context}"] ==== Bug fixes -* Previously, the {gcp-first} *Project Number input* field was incorrectly labeled as *GCP Pool ID*. With this release, the {gcp-short} *Project Number input* field is correctly labeled. (link:https://issues.redhat.com/browse/OCPBUGS-46000[*OCPBUGS-46000*]) +* Previously, the {gcp-first} *Project Number input* field was incorrectly labeled as *GCP Pool ID*. With this release, the {gcp-short} *Project Number input* field is correctly labeled. (link:https://issues.redhat.com/browse/OCPBUGS-46000[OCPBUGS-46000]) -* Previously, there was a maximum bulk delete limit of 10. This limit caused an issue with the `PreferNoSchedule` taint. With this release, the maximum bulk delete rate is disabled. (link:https://issues.redhat.com/browse/OCPBUGS-45929[*OCPBUGS-45929*]) +* Previously, there was a maximum bulk delete limit of 10. This limit caused an issue with the `PreferNoSchedule` taint. With this release, the maximum bulk delete rate is disabled. (link:https://issues.redhat.com/browse/OCPBUGS-45929[OCPBUGS-45929]) -* Previously, users wanted to configure their {aws-full} DHCP option set with a custom domain name that contained a trailing period. When the hostname of EC2 instances were converted to Kubelet node names, the trailing period was not removed. Trailing periods are not allowed in a Kubernetes object name. With this release, trailing periods are allowed in a domain name in a DHCP option set. (link:https://issues.redhat.com/browse/OCPBUGS-45918[*OCPBUGS-45918*]) +* Previously, users wanted to configure their {aws-full} DHCP option set with a custom domain name that contained a trailing period. When the hostname of EC2 instances were converted to Kubelet node names, the trailing period was not removed. Trailing periods are not allowed in a Kubernetes object name. With this release, trailing periods are allowed in a domain name in a DHCP option set. (link:https://issues.redhat.com/browse/OCPBUGS-45918[OCPBUGS-45918]) -* Previously, when a long string of individual CPUs were in the Performance Profile, the machine configurations were not processed. With this release, the user input process is updated to use a sequence of numbers or a range of numbers on the kernel command line. (link:https://issues.redhat.com/browse/OCPBUGS-45627[*OCPBUGS-45627*]) +* Previously, when a long string of individual CPUs were in the Performance Profile, the machine configurations were not processed. With this release, the user input process is updated to use a sequence of numbers or a range of numbers on the kernel command line. (link:https://issues.redhat.com/browse/OCPBUGS-45627[OCPBUGS-45627]) -* Previously, when accessing the image from the release payload to run the `oc adm node-image` command, the command failed. With this release, a retry mechanism is added to correct the temporary failures when the image is accessed. (link:https://issues.redhat.com/browse/OCPBUGS-45517[*OCPBUGS-45517*]) +* Previously, when accessing the image from the release payload to run the `oc adm node-image` command, the command failed. With this release, a retry mechanism is added to correct the temporary failures when the image is accessed. (link:https://issues.redhat.com/browse/OCPBUGS-45517[OCPBUGS-45517]) -* Previously, the first reboot failed while running Agent-based Installer using FCP or NVME storage devices for multiple images on s390x hardware. With this release, this issue is resolved and the reboot completes. (link:https://issues.redhat.com/browse/OCPBUGS-44904[*OCPBUGS-44904*]) +* Previously, the first reboot failed while running Agent-based Installer using FCP or NVME storage devices for multiple images on s390x hardware. With this release, this issue is resolved and the reboot completes. (link:https://issues.redhat.com/browse/OCPBUGS-44904[OCPBUGS-44904]) -* Previously, a missing permission caused cluster deprovision to fail when using a custom identity and access management (IAM) profile. With this release, the list of required permissions includes `tag:UntagResource` and the cluster deprovision completes. (link:https://issues.redhat.com/browse/OCPBUGS-44848[*OCPBUGS-44848*]) +* Previously, a missing permission caused cluster deprovision to fail when using a custom identity and access management (IAM) profile. With this release, the list of required permissions includes `tag:UntagResource` and the cluster deprovision completes. (link:https://issues.redhat.com/browse/OCPBUGS-44848[OCPBUGS-44848]) -* Previously, when you created a hosted cluster by using a shared VPC where the private DNS hosted zones existed in the cluster creator account, the private link controller failed to create the `route53` DNS records in the local zone. With this release, the ingress shared role adds records to the private link controller. The VPC endpoint is used to share the role to create the VPC endpoint in the VPC owner account. A hosted cluster is created in a shared VPC configuration, where the private hosted zones exist in the cluster creator account. (link:https://issues.redhat.com/browse/OCPBUGS-44630[*OCPBUGS-44630*]) +* Previously, when you created a hosted cluster by using a shared VPC where the private DNS hosted zones existed in the cluster creator account, the private link controller failed to create the `route53` DNS records in the local zone. With this release, the ingress shared role adds records to the private link controller. The VPC endpoint is used to share the role to create the VPC endpoint in the VPC owner account. A hosted cluster is created in a shared VPC configuration, where the private hosted zones exist in the cluster creator account. (link:https://issues.redhat.com/browse/OCPBUGS-44630[OCPBUGS-44630]) -* Previously, the `kdump initramfs` stopped responding when opening a local encrypted disk, even when the kdump destination was a remote machine that did not need to access the local machine. With this release, this issue is fixed and the `kdump initranfs` successfully opens a local encrypted disk. (link:https://issues.redhat.com/browse/OCPBUGS-43079[*OCPBUGS-43079*]) +* Previously, the `kdump initramfs` stopped responding when opening a local encrypted disk, even when the kdump destination was a remote machine that did not need to access the local machine. With this release, this issue is fixed and the `kdump initranfs` successfully opens a local encrypted disk. (link:https://issues.redhat.com/browse/OCPBUGS-43079[OCPBUGS-43079]) -* Previously, the Cluster Version Operator (CVO) did not filter internal errors that were propogated to the `ClusterVersion Failing condition` message. As a result, errors that did not negatively impact the update were shown for the `ClusterVersion Failing condition` message. With this release, the errors that are propogated to the `ClusterVersion Failing condition` message are filtered. (link:https://issues.redhat.com/browse/OCPBUGS-39558[*OCPBUGS-39558*]) +* Previously, the Cluster Version Operator (CVO) did not filter internal errors that were propogated to the `ClusterVersion Failing condition` message. As a result, errors that did not negatively impact the update were shown for the `ClusterVersion Failing condition` message. With this release, the errors that are propogated to the `ClusterVersion Failing condition` message are filtered. (link:https://issues.redhat.com/browse/OCPBUGS-39558[OCPBUGS-39558]) [id="ocp-4-17-9-updating_{context}"] ==== Updating @@ -3475,15 +3475,15 @@ $ oc adm release info 4.17.8 --pullspecs [id="ocp-4-17-8-bug-fixes_{context}"] ==== Bug fixes -* Previously, the provider ID for the `IBMPowerVSCluster` object did not populate properly due to an improper retrieval of the IBM Cloud Workspace ID. As a result, certificate signing requests (CSRs) were pending in the hosted cluster. With this release, the provider ID successfully populates and the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-44880[*OCPBUGS-44880*]) +* Previously, the provider ID for the `IBMPowerVSCluster` object did not populate properly due to an improper retrieval of the IBM Cloud Workspace ID. As a result, certificate signing requests (CSRs) were pending in the hosted cluster. With this release, the provider ID successfully populates and the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-44880[OCPBUGS-44880]) -* Previously, you could not remove a finally pipeline task from the edit Pipeline form if you created a pipeline with only one finally task. With this change, you can remove the finally task from the edit Pipeline form and the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-44873[*OCPBUGS-44873*]) +* Previously, you could not remove a finally pipeline task from the edit Pipeline form if you created a pipeline with only one finally task. With this change, you can remove the finally task from the edit Pipeline form and the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-44873[OCPBUGS-44873]) -* Previously, if you used the `oc adm node-image create` command and the image generation step failed, it reported a simple error and did not show the log for the container. As a result, the error message did not show the underlying issue that caused the image generation step to fail. With this release, the `oc adm node-image create` command shows the log for the container. (link:https://issues.redhat.com/browse/OCPBUGS-44508[*OCPBUGS-44508*]) +* Previously, if you used the `oc adm node-image create` command and the image generation step failed, it reported a simple error and did not show the log for the container. As a result, the error message did not show the underlying issue that caused the image generation step to fail. With this release, the `oc adm node-image create` command shows the log for the container. (link:https://issues.redhat.com/browse/OCPBUGS-44508[OCPBUGS-44508]) -* Previously, if you created load balancers for a cluster that you wanted to install on {ibm-power-name} and the creation of the load balancers timed out, the installation of the cluster failed and did not report the error. The cluster failed because both internal and external DNS load balancer names were not created. With this release, if internal and external DNS load balancer names do not exist during cluster installation, the installation program produces an error notification, and you can add the names so that the cluster installation process continues. (link:https://issues.redhat.com/browse/OCPBUGS-44247[*OCPBUGS-44247*]) +* Previously, if you created load balancers for a cluster that you wanted to install on {ibm-power-name} and the creation of the load balancers timed out, the installation of the cluster failed and did not report the error. The cluster failed because both internal and external DNS load balancer names were not created. With this release, if internal and external DNS load balancer names do not exist during cluster installation, the installation program produces an error notification, and you can add the names so that the cluster installation process continues. (link:https://issues.redhat.com/browse/OCPBUGS-44247[OCPBUGS-44247]) -* Previously, the IDs that were used to determine the number of rows in a Dashboard table were not unique, and some rows were combined if their IDs were the same. With this release, the ID uses more information to prevent duplicate IDs and the table can display each expected row. (link:https://issues.redhat.com/browse/OCPBUGS-43441[*OCPBUGS-43441*]) +* Previously, the IDs that were used to determine the number of rows in a Dashboard table were not unique, and some rows were combined if their IDs were the same. With this release, the ID uses more information to prevent duplicate IDs and the table can display each expected row. (link:https://issues.redhat.com/browse/OCPBUGS-43441[OCPBUGS-43441]) [id="ocp-4-17-8-updating_{context}"] ==== Updating @@ -3512,16 +3512,16 @@ $ oc adm release info 4.17.7 --pullspecs [id="ocp-4-17-7-cluster-tasks-pipelines_{context}"] ===== Deprecated clusterTasks {pipelines-shortname} version 1.17 -* The {product-title} {product-version} release deprecates the `clusterTasks` resource from {pipelines-title} version 1.17. The release also removes `clusterTasks` resource dependencies from the static plugin on the {pipelines-shortname} page of the {product-title} web console. (link:https://issues.redhat.com/browse/OCPBUGS-44183[*OCPBUGS-44183*]) +* The {product-title} {product-version} release deprecates the `clusterTasks` resource from {pipelines-title} version 1.17. The release also removes `clusterTasks` resource dependencies from the static plugin on the {pipelines-shortname} page of the {product-title} web console. (link:https://issues.redhat.com/browse/OCPBUGS-44183[OCPBUGS-44183]) [id="ocp-4-17-7-bug-fixes_{context}"] ==== Bug fixes -* Previously, you could not enter multi-line parameters in a custom template, such as private keys. With this release, you can switch between single-line and multi-line modes in a custom template so that you can enter multi-line inputs in a template field. (link:https://issues.redhat.com/browse/OCPBUGS-44699[*OCPBUGS-44699*]) +* Previously, you could not enter multi-line parameters in a custom template, such as private keys. With this release, you can switch between single-line and multi-line modes in a custom template so that you can enter multi-line inputs in a template field. (link:https://issues.redhat.com/browse/OCPBUGS-44699[OCPBUGS-44699]) -* Previously, when you attempted to use the Cluster Network Operator (CNO) to upgrade a cluster with existing `localnet` networks, `ovnkube-control-plane` pods would fail to run. This happened because the `ovnkube-cluster-manager` container could not process an OVN-Kubernetes `localnet` topology network that did not have subnets defined. With this release, a fix ensures that the `ovnkube-cluster-manager` container can process an OVN-Kubernetes `localnet` topology network that does not have subnets defined. (link:https://issues.redhat.com/browse/OCPBUGS-43454[*OCPBUGS-43454*]) +* Previously, when you attempted to use the Cluster Network Operator (CNO) to upgrade a cluster with existing `localnet` networks, `ovnkube-control-plane` pods would fail to run. This happened because the `ovnkube-cluster-manager` container could not process an OVN-Kubernetes `localnet` topology network that did not have subnets defined. With this release, a fix ensures that the `ovnkube-cluster-manager` container can process an OVN-Kubernetes `localnet` topology network that does not have subnets defined. (link:https://issues.redhat.com/browse/OCPBUGS-43454[OCPBUGS-43454]) -* Previously, when you attempted to scale a `DeploymentConfig` object with an admission webhook that the object's `deploymentconfigs/scale` subresource, the `apiserver` failed to handle the request. This impacted the `DeploymentConfig` object as it could not be scaled. With this release, a fix ensures that this issue no longer occurs. (link:https://issues.redhat.com/browse/OCPBUGS-42752[*OCPBUGS-42752*]) +* Previously, when you attempted to scale a `DeploymentConfig` object with an admission webhook that the object's `deploymentconfigs/scale` subresource, the `apiserver` failed to handle the request. This impacted the `DeploymentConfig` object as it could not be scaled. With this release, a fix ensures that this issue no longer occurs. (link:https://issues.redhat.com/browse/OCPBUGS-42752[OCPBUGS-42752]) [id="ocp-4-17-7-updating_{context}"] ==== Updating @@ -3550,32 +3550,32 @@ $ oc adm release info 4.17.6 --pullspecs [id="ocp-4-17-6-kubernetes-1-30-6_{context}"] ===== Updating to Kubernetes version 1.30.6 -{product-title} release {product-version}.6 contains the changes that come from the update to Kubernetes version 1.30.6. (link:https://issues.redhat.com/browse/OCPBUGS-44512[*OCPBUGS-44512*]) +{product-title} release {product-version}.6 contains the changes that come from the update to Kubernetes version 1.30.6. (link:https://issues.redhat.com/browse/OCPBUGS-44512[OCPBUGS-44512]) [id="ocp-4-17-6-bug-fixes_{context}"] ==== Bug fixes //OCPBUGS-44760 Need to confirm with SME. -* Previously, if you set custom annotations in a custom resource (CR), the SR-IOV Operator would override all the default annotations in the `SriovNetwork` CR. With this release, when you define custom annotations in a CR, the SR-IOV Operator does not override the default annotations. (link:https://issues.redhat.com/browse/OCPBUGS-42252[*OCPBUGS-42252*]) +* Previously, if you set custom annotations in a custom resource (CR), the SR-IOV Operator would override all the default annotations in the `SriovNetwork` CR. With this release, when you define custom annotations in a CR, the SR-IOV Operator does not override the default annotations. (link:https://issues.redhat.com/browse/OCPBUGS-42252[OCPBUGS-42252]) -* Previously, in the Red{nbsp}Hat {product-title} web console *Notifications* section, silenced alerts were visible in the notification drawer because the alerts did not include external labels. With this release, the alerts include external labels so that silenced alerts are not visible on the notification drawer. (link:https://issues.redhat.com/browse/OCPBUGS-44722[*OCPBUGS-44722*]) +* Previously, in the Red{nbsp}Hat {product-title} web console *Notifications* section, silenced alerts were visible in the notification drawer because the alerts did not include external labels. With this release, the alerts include external labels so that silenced alerts are not visible on the notification drawer. (link:https://issues.redhat.com/browse/OCPBUGS-44722[OCPBUGS-44722]) -* Previously, when you clicked the `start lastrun` option in the Red{nbsp}Hat {product-title} web console *Edit BuildConfig* page, an error prevented the `lastrun` operation from running. With this release, a fix ensures that `start lastrun` option runs as expected. (link:https://issues.redhat.com/browse/OCPBUGS-44587[*OCPBUGS-44587*]) +* Previously, when you clicked the `start lastrun` option in the Red{nbsp}Hat {product-title} web console *Edit BuildConfig* page, an error prevented the `lastrun` operation from running. With this release, a fix ensures that `start lastrun` option runs as expected. (link:https://issues.redhat.com/browse/OCPBUGS-44587[OCPBUGS-44587]) -* Previously, {product-title} {product-version} introduced collapsing and expanding the *Getting started* section on the *Administrator perspective* of the Red{nbsp}Hat {product-title} web console. When you either collapsed or expanded the section, you could not close the section. With this release, a fix ensures that you can now close the *Getting started* section. (link:https://issues.redhat.com/browse/OCPBUGS-44586[*OCPBUGS-44586*]) +* Previously, {product-title} {product-version} introduced collapsing and expanding the *Getting started* section on the *Administrator perspective* of the Red{nbsp}Hat {product-title} web console. When you either collapsed or expanded the section, you could not close the section. With this release, a fix ensures that you can now close the *Getting started* section. (link:https://issues.redhat.com/browse/OCPBUGS-44586[OCPBUGS-44586]) -* Previously, the `MachineConfig` tab on the *Details* page of the Red{nbsp}Hat {product-title} web console displayed an error when one or more `spec.config.storage.files` did not include data fields that were marked as optional. With this update, a fix ensures that this error no longer displays if you populated no values in the optional fields. (link:https://issues.redhat.com/browse/OCPBUGS-44479[*OCPBUGS-44479*]) +* Previously, the `MachineConfig` tab on the *Details* page of the Red{nbsp}Hat {product-title} web console displayed an error when one or more `spec.config.storage.files` did not include data fields that were marked as optional. With this update, a fix ensures that this error no longer displays if you populated no values in the optional fields. (link:https://issues.redhat.com/browse/OCPBUGS-44479[OCPBUGS-44479]) -* Previously, a {hcp-capital} cluster that used the {ibm-name} platform was unable to accept authenticatation from an `oc login` command. This behavior caused an error for the web broswer where the browser could not fetch the token from the cluster. With this release, a fix ensures that cloud-based endpoints do not get proxied so that authentication by using the `oc login` command works as expected. (link:https://issues.redhat.com/browse/OCPBUGS-44276[*OCPBUGS-44276*]) +* Previously, a {hcp-capital} cluster that used the {ibm-name} platform was unable to accept authenticatation from an `oc login` command. This behavior caused an error for the web broswer where the browser could not fetch the token from the cluster. With this release, a fix ensures that cloud-based endpoints do not get proxied so that authentication by using the `oc login` command works as expected. (link:https://issues.redhat.com/browse/OCPBUGS-44276[OCPBUGS-44276]) -* Previously, if the `RendezvousIP` matched a substring in the `next-hop-address` field of a compute node configuration, a validation error. The `RendezvousIP` must match only a control plane host address. With this release, a substring comparison for `RendezvousIP` is used only against a control plane host address, so that the error no longer exists. (link:https://issues.redhat.com/browse/OCPBUGS-44261[*OCPBUGS-44261*]) +* Previously, if the `RendezvousIP` matched a substring in the `next-hop-address` field of a compute node configuration, a validation error. The `RendezvousIP` must match only a control plane host address. With this release, a substring comparison for `RendezvousIP` is used only against a control plane host address, so that the error no longer exists. (link:https://issues.redhat.com/browse/OCPBUGS-44261[OCPBUGS-44261]) -* Previously, when you created load balancers for a cluster that you wanted to install on {ibm-power-name} and the creation of the load balancers timed out, the installation of the cluster failed and did not report the error. The cluster failed because both internal and external DNS load balancer names were not created. With this release, if internal and external DNS load balancer names do not exist during cluster installation, the installation program outputs an error so that you have an opportunity to add the names so that the cluster installation process can continue. (link:https://issues.redhat.com/browse/OCPBUGS-44247[*OCPBUGS-44247*]) +* Previously, when you created load balancers for a cluster that you wanted to install on {ibm-power-name} and the creation of the load balancers timed out, the installation of the cluster failed and did not report the error. The cluster failed because both internal and external DNS load balancer names were not created. With this release, if internal and external DNS load balancer names do not exist during cluster installation, the installation program outputs an error so that you have an opportunity to add the names so that the cluster installation process can continue. (link:https://issues.redhat.com/browse/OCPBUGS-44247[OCPBUGS-44247]) -* Previously, when you attempted to run a disk cleanup operation on a physical storage device that used thin provisioning, the cleanup operation failed. With this release, a bug fix now ensures that you can run a disk cleanup operation on a physical storage device without the cleanup operation failing. (link:https://issues.redhat.com/browse/OCPBUGS-31570[*OCPBUGS-31570*]) +* Previously, when you attempted to run a disk cleanup operation on a physical storage device that used thin provisioning, the cleanup operation failed. With this release, a bug fix now ensures that you can run a disk cleanup operation on a physical storage device without the cleanup operation failing. (link:https://issues.redhat.com/browse/OCPBUGS-31570[OCPBUGS-31570]) -* Previously, if the {olm-first} was unable to access the secret associated with a service account, {olm} would rely on the Kubernetes API server to automatically create a bearer token. With this release, Kubernetes versions 1.22 and later do not automatically create the bearer token. Instead, {olm} now uses the `TokenRequest` API to request a new Kubernetes API token. (link:https://issues.redhat.com/browse/OCPBUGS-44760[*OCPBUGS-44760*]) +* Previously, if the {olm-first} was unable to access the secret associated with a service account, {olm} would rely on the Kubernetes API server to automatically create a bearer token. With this release, Kubernetes versions 1.22 and later do not automatically create the bearer token. Instead, {olm} now uses the `TokenRequest` API to request a new Kubernetes API token. (link:https://issues.redhat.com/browse/OCPBUGS-44760[OCPBUGS-44760]) [id="ocp-4-17-6-updating_{context}"] ==== Updating @@ -3604,16 +3604,16 @@ $ oc adm release info 4.17.5 --pullspecs [id="ocp-4-17-5-enhancements-cmo-improved-criteria_{context}"] ===== Improving the validation criteria for Cluster Monitoring Operator -* With this release, the Cluster Monitoring Operator (CMO) has improved validation criteria. The CMO blocks cluster updates with configurations in `openshift-monitoring/cluster-monitoring-config` or `openshift-user-workload-monitoring/user-workload-monitoring-config` that include unsupported fields or misconfigurations. (link:https://issues.redhat.com/browse/OCPBUGS-43690[*OCPBUGS-43690*]) +* With this release, the Cluster Monitoring Operator (CMO) has improved validation criteria. The CMO blocks cluster updates with configurations in `openshift-monitoring/cluster-monitoring-config` or `openshift-user-workload-monitoring/user-workload-monitoring-config` that include unsupported fields or misconfigurations. (link:https://issues.redhat.com/browse/OCPBUGS-43690[OCPBUGS-43690]) [id="ocp-4-17-5-bug-fixes_{context}"] ==== Bug fixes -* Previously, the Azure File Driver attempted to reuse existing storage accounts. With this release, the Azure File Driver creates storage accounts during dynamic provisioning. For updated clusters, newly-created Persistent Volumes use a new storage account. Persistent Volumes that were previously provisioned continue using the same storage account used before the cluster update. (link:https://issues.redhat.com/browse/OCPBUGS-42949[*OCPBUGS-42949*]) +* Previously, the Azure File Driver attempted to reuse existing storage accounts. With this release, the Azure File Driver creates storage accounts during dynamic provisioning. For updated clusters, newly-created Persistent Volumes use a new storage account. Persistent Volumes that were previously provisioned continue using the same storage account used before the cluster update. (link:https://issues.redhat.com/browse/OCPBUGS-42949[OCPBUGS-42949]) -* Previously, when you used the `must-gather` tool, a Multus Container Network Interface (CNI) log file, `multus.log`, was stored in a node's file system. This situation caused the tool to generate unnecessary debug pods in a node. With this release, the Multus CNI no longer creates a `multus.log` file, and instead uses a CNI plugin pattern to inspect any logs for Multus DaemonSet pods in the `openshift-multus` namespace. (link:https://issues.redhat.com/browse/OCPBUGS-42835[*OCPBUGS-42835*]) +* Previously, when you used the `must-gather` tool, a Multus Container Network Interface (CNI) log file, `multus.log`, was stored in a node's file system. This situation caused the tool to generate unnecessary debug pods in a node. With this release, the Multus CNI no longer creates a `multus.log` file, and instead uses a CNI plugin pattern to inspect any logs for Multus DaemonSet pods in the `openshift-multus` namespace. (link:https://issues.redhat.com/browse/OCPBUGS-42835[OCPBUGS-42835]) -* Previously, the task data did not fully load on ArtifactHub when you attempted to create a pipeline. With this release, the console fully loads the data from ArtifactHub and the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-16141[*OCPBUGS-16141*]) +* Previously, the task data did not fully load on ArtifactHub when you attempted to create a pipeline. With this release, the console fully loads the data from ArtifactHub and the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-16141[OCPBUGS-16141]) [id="ocp-4-17-5-updating_{context}"] ==== Updating @@ -3651,34 +3651,34 @@ For more information, see xref:../nodes/pods/nodes-pods-short-term-auth.adoc#nod [id="ocp-4-17-4-enhancements-ansible-operator_{context}"] ===== ansible-operator upstream version information -* The `ansible-operator` version now shows the corresponding upstream version information. (link:https://issues.redhat.com/browse/OCPBUGS-43836[*OCPBUGS-43836*]) +* The `ansible-operator` version now shows the corresponding upstream version information. (link:https://issues.redhat.com/browse/OCPBUGS-43836[OCPBUGS-43836]) [id="ocp-4-17-4-bug-fixes_{context}"] ==== Bug fixes -* Previously, when installing a cluster on an {ibm-title} platform and adding an existing VPC to the cluster, the {cap-ibm-first} would not add ports 443, 5000, and 6443 to the security group of the VPC. This situation prevented the VPC from being added to the cluster. With this release, a fix ensures that the {cap-ibm-first} adds the ports to the security group of the VPC so that the VPC gets added to your cluster. (link:https://issues.redhat.com/browse/OCPBUGS-44226[*OCPBUGS-44226*]) +* Previously, when installing a cluster on an {ibm-title} platform and adding an existing VPC to the cluster, the {cap-ibm-first} would not add ports 443, 5000, and 6443 to the security group of the VPC. This situation prevented the VPC from being added to the cluster. With this release, a fix ensures that the {cap-ibm-first} adds the ports to the security group of the VPC so that the VPC gets added to your cluster. (link:https://issues.redhat.com/browse/OCPBUGS-44226[OCPBUGS-44226]) * Previously, the installation program populated the `network.devices`, `template` and `workspace` fields in the `spec.template.spec.providerSpec.value` section of the {vmw-full} control plane machine set custom resource (CR). These fields should be set in the {vmw-short} failure domain, and the installation program populating them caused unintended behaviors. + -Updating these fields did not trigger an update to the control plane machines, and these fields were cleared when the control plane machine set was deleted. With this release, the installation program is updated to no longer populate values that are included in the failure domain configuration. If these values are not defined in a failure domain configuration, for instance on a cluster that is updated to {product-title} {product-version} from an earlier version, the values defined by the installation program are used. (link:https://issues.redhat.com/browse/OCPBUGS-44047[*OCPBUGS-44047*]) +Updating these fields did not trigger an update to the control plane machines, and these fields were cleared when the control plane machine set was deleted. With this release, the installation program is updated to no longer populate values that are included in the failure domain configuration. If these values are not defined in a failure domain configuration, for instance on a cluster that is updated to {product-title} {product-version} from an earlier version, the values defined by the installation program are used. (link:https://issues.redhat.com/browse/OCPBUGS-44047[OCPBUGS-44047]) -* Previously, enabling ESP hardware offload using IPSec on attached interfaces in Open vSwitch broke connectivity due to a bug in Open vSwitch. With this release, OpenShift automatically disables ESP hardware offload on the Open vSwitch attached interfaces, and the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-43917[*OCPBUGS-43917*]) +* Previously, enabling ESP hardware offload using IPSec on attached interfaces in Open vSwitch broke connectivity due to a bug in Open vSwitch. With this release, OpenShift automatically disables ESP hardware offload on the Open vSwitch attached interfaces, and the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-43917[OCPBUGS-43917]) -* Previously, if you configured the identity provider (IDP) name for OAuth custom resource (CR) to contain whitespaces, `oauth-server` crashed. With this release, an identity provider (IDP) name that contains whitespaces does not cause `oauth-server` to crash. (link:https://issues.redhat.com/browse/OCPBUGS-44118[*OCPBUGS-44118*]) +* Previously, if you configured the identity provider (IDP) name for OAuth custom resource (CR) to contain whitespaces, `oauth-server` crashed. With this release, an identity provider (IDP) name that contains whitespaces does not cause `oauth-server` to crash. (link:https://issues.redhat.com/browse/OCPBUGS-44118[OCPBUGS-44118]) -* Previously, due to a behavior regression in Go 1.22, `oauth-server` pods crashed if the IDP configuration contained multiple password-based IDPs, such as `htpasswd`, with at least one of them having spaces in its name. Note that if the bootstrap user ,`kubeadmin`, still exists in a cluster, the user also counts as a password-based IDP. With this release, a fix to the `oauth-server` resolves this issue and prevents the server from crashing. (link:https://issues.redhat.com/browse/OCPBUGS-43587[*OCPBUGS-43587*]) +* Previously, due to a behavior regression in Go 1.22, `oauth-server` pods crashed if the IDP configuration contained multiple password-based IDPs, such as `htpasswd`, with at least one of them having spaces in its name. Note that if the bootstrap user ,`kubeadmin`, still exists in a cluster, the user also counts as a password-based IDP. With this release, a fix to the `oauth-server` resolves this issue and prevents the server from crashing. (link:https://issues.redhat.com/browse/OCPBUGS-43587[OCPBUGS-43587]) -* Previously, when you used the Agent-based Installer to install a cluster on a node that had an incorrect date, the cluster installation failed. With this release, a patch is applied to the Agent-based Installer live ISO time synchronization. The patch configures the `/etc/chrony.conf` file with the list of additional Network Time Protocol (NTP) servers, so that you can set any of these additional NTP servers in the `agent-config.yaml` without experiencing a cluster installation issue. (link:https://issues.redhat.com/browse/OCPBUGS-43846[*OCPBUGS-43846*]) +* Previously, when you used the Agent-based Installer to install a cluster on a node that had an incorrect date, the cluster installation failed. With this release, a patch is applied to the Agent-based Installer live ISO time synchronization. The patch configures the `/etc/chrony.conf` file with the list of additional Network Time Protocol (NTP) servers, so that you can set any of these additional NTP servers in the `agent-config.yaml` without experiencing a cluster installation issue. (link:https://issues.redhat.com/browse/OCPBUGS-43846[OCPBUGS-43846]) -* Previously, when you installed a private cluster on {gcp-first}, the API firewall rule used the source range of `0.0.0.0/0`. This address allowed non-cluster resources unintended access to the private cluster. With this release, the API firewall rule now only allows resources that have source ranges in the Machine Network to access the private cluster. (link:https://issues.redhat.com/browse/OCPBUGS-43786[*OCPBUGS-43786*]) +* Previously, when you installed a private cluster on {gcp-first}, the API firewall rule used the source range of `0.0.0.0/0`. This address allowed non-cluster resources unintended access to the private cluster. With this release, the API firewall rule now only allows resources that have source ranges in the Machine Network to access the private cluster. (link:https://issues.redhat.com/browse/OCPBUGS-43786[OCPBUGS-43786]) -* Previously, an invalid or unreachable identity provider (IDP) blocked updates to {hcp}. With this release, the `ValidIDPConfiguration` condition in the `HostedCluster` object now reports any IDP errors so that these errors do not block updates to {hcp}. (link:https://issues.redhat.com/browse/OCPBUGS-43746[*OCPBUGS-43746*]) +* Previously, an invalid or unreachable identity provider (IDP) blocked updates to {hcp}. With this release, the `ValidIDPConfiguration` condition in the `HostedCluster` object now reports any IDP errors so that these errors do not block updates to {hcp}. (link:https://issues.redhat.com/browse/OCPBUGS-43746[OCPBUGS-43746]) -* Previously, the `attach`, `oc exec`, and `port-forward` commands received an error if you ran the commands through a proxy. With this release, a patch applied to kubectl ensures kubectl can handle any proxy errors with these commands, so that the commands run as expected. (link:https://issues.redhat.com/browse/OCPBUGS-43696[*OCPBUGS-43696*]) +* Previously, the `attach`, `oc exec`, and `port-forward` commands received an error if you ran the commands through a proxy. With this release, a patch applied to kubectl ensures kubectl can handle any proxy errors with these commands, so that the commands run as expected. (link:https://issues.redhat.com/browse/OCPBUGS-43696[OCPBUGS-43696]) -* Previously, {op-system-base-full} CoreOS templates that were shipped by the Machine Config Operator (MCO) caused node scaling to fail on {rh-openstack-first}. This issue happened because of an issue with `systemd` and the presence of a legacy boot image from older versions of {product-title}. With this release, a patch fixes the issue with `systemd` and removes the legacy boot image, so that node scaling can continue as expected. (link:https://issues.redhat.com/browse/OCPBUGS-42577[*OCPBUGS-42577*]) +* Previously, {op-system-base-full} CoreOS templates that were shipped by the Machine Config Operator (MCO) caused node scaling to fail on {rh-openstack-first}. This issue happened because of an issue with `systemd` and the presence of a legacy boot image from older versions of {product-title}. With this release, a patch fixes the issue with `systemd` and removes the legacy boot image, so that node scaling can continue as expected. (link:https://issues.redhat.com/browse/OCPBUGS-42577[OCPBUGS-42577]) -* Previously, if a Cluster Version Operator (CVO) pod restarted while the pod was initializing a syncing operation, the guard for a blocked upgrade request failed. As a consequence, the blocked upgrade request was unexpectedly accepted. With this release, a CVO pod postpones the reconciliation of requests during initialization, so that the guard of a blocked upgrade requests persists after the CVO pod restarts. (link:https://issues.redhat.com/browse/OCPBUGS-42386[*OCPBUGS-42386*]) +* Previously, if a Cluster Version Operator (CVO) pod restarted while the pod was initializing a syncing operation, the guard for a blocked upgrade request failed. As a consequence, the blocked upgrade request was unexpectedly accepted. With this release, a CVO pod postpones the reconciliation of requests during initialization, so that the guard of a blocked upgrade requests persists after the CVO pod restarts. (link:https://issues.redhat.com/browse/OCPBUGS-42386[OCPBUGS-42386]) [id="ocp-4-17-4-updating_{context}"] ==== Updating @@ -3707,29 +3707,29 @@ $ oc adm release info 4.17.3 --pullspecs [id="ocp-4-17-3-enhancements-exposing-network-overlap-metrics-cno_{context}"] ===== Exposing network overlap metrics with the Cluster Network Operator -* When you start the limited live migration method and an issue exists with network overlap, the Cluster Network Operator (CNO) can expose network overlap metrics for the issue. This is possible because the `openshift_network_operator_live_migration_blocked` metric now includes the new `NetworkOverlap` label. (link:https://issues.redhat.com/browse/OCPBUGS-39121[*OCPBUGS-39121*]) +* When you start the limited live migration method and an issue exists with network overlap, the Cluster Network Operator (CNO) can expose network overlap metrics for the issue. This is possible because the `openshift_network_operator_live_migration_blocked` metric now includes the new `NetworkOverlap` label. (link:https://issues.redhat.com/browse/OCPBUGS-39121[OCPBUGS-39121]) [id="ocp-4-17-3-automatic-variable-loading-git-repository_{context}"] ===== Loading git repository environment variables automatically from your repository -* Previously, when you imported a git repository by using the serverless import strategy, the environment variables from the `func.yaml` file were not automatically loaded into the form. With this update, the environment variables are now loaded upon import. (link:https://issues.redhat.com/browse/OCPBUGS-42474[*OCPBUGS-42474*]) +* Previously, when you imported a git repository by using the serverless import strategy, the environment variables from the `func.yaml` file were not automatically loaded into the form. With this update, the environment variables are now loaded upon import. (link:https://issues.redhat.com/browse/OCPBUGS-42474[OCPBUGS-42474]) [id="ocp-4-17-3-bug-fixes_{context}"] ==== Bug fixes -* Previously, a regression was introduced to the OpenShift installer during a Power VS deployment. As a result, the security group rules required for OpenShift Install were not created. With this release, the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-43547[*OCPBUGS-43547*]) +* Previously, a regression was introduced to the OpenShift installer during a Power VS deployment. As a result, the security group rules required for OpenShift Install were not created. With this release, the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-43547[OCPBUGS-43547]) -* Previously, if an image registry Operator was configured with the `networkAccess` field set to `Internal` in Azure, an authorization error prevented the image registry Operator from deleting the storage container, and the `managementState` field from being set to `Removed`. With this release, the Operator can delete the storage account and storage container, and the `managementState` field can successfully set to `Removed`. (link:https://issues.redhat.com/browse/OCPBUGS-43350[*OCPBUGS-43350*]) +* Previously, if an image registry Operator was configured with the `networkAccess` field set to `Internal` in Azure, an authorization error prevented the image registry Operator from deleting the storage container, and the `managementState` field from being set to `Removed`. With this release, the Operator can delete the storage account and storage container, and the `managementState` field can successfully set to `Removed`. (link:https://issues.redhat.com/browse/OCPBUGS-43350[OCPBUGS-43350]) -* Previously, both active and passive high-availability (HA) deployments ran three replicas instead of the required two. As a result, control planes contained more pods than required, which led to scaling issues. With this release, the number of replicas in active and passive HA deployments is reduced from three to two. (link:https://issues.redhat.com/browse/OCPBUGS-42704[*OCPBUGS-42704*]) +* Previously, both active and passive high-availability (HA) deployments ran three replicas instead of the required two. As a result, control planes contained more pods than required, which led to scaling issues. With this release, the number of replicas in active and passive HA deployments is reduced from three to two. (link:https://issues.redhat.com/browse/OCPBUGS-42704[OCPBUGS-42704]) -* Previously, the configuration loader logged `yaml` unmarshal errors when the INI succeeded. With this release, the unmarshal errors are no longer logged when the INI succeeds. (link:https://issues.redhat.com/browse/OCPBUGS-42327[*OCPBUGS-42327*]) +* Previously, the configuration loader logged `yaml` unmarshal errors when the INI succeeded. With this release, the unmarshal errors are no longer logged when the INI succeeds. (link:https://issues.redhat.com/browse/OCPBUGS-42327[OCPBUGS-42327]) -* Previously, the Machine Config Operator (MCO)'s vSphere `resolve-prepender` script used `systemd` directives that were incompatible with old bootimage versions used in {product-title} 4. With this release, nodes can scale using newer bootimage versions {product-version} 4.13 and above, through manual intervention, or by upgrading to a release that includes this fix. (link:https://issues.redhat.com/browse/OCPBUGS-42108[*OCPBUGS-42108*]) +* Previously, the Machine Config Operator (MCO)'s vSphere `resolve-prepender` script used `systemd` directives that were incompatible with old bootimage versions used in {product-title} 4. With this release, nodes can scale using newer bootimage versions {product-version} 4.13 and above, through manual intervention, or by upgrading to a release that includes this fix. (link:https://issues.redhat.com/browse/OCPBUGS-42108[OCPBUGS-42108]) -* Previously, the installation program did not validate the maximum transmission unit (MTU) for a custom IPv6 network on {op-system-first}. If you specified a low value for the MTU, the installation of the cluster would fail. With this release, the minimum MTU value for IPv6 networks is set to `1380`, where `1280` is the minimum MTU for IPv6 and `100` is the OVN-Kubernetes encapsulation overhead. With this release, the installation program now validates the MTU for a custom IPv6 network on {op-system-first}. (link:https://issues.redhat.com/browse/OCPBUGS-41812[*OCPBUGS-41812*]) +* Previously, the installation program did not validate the maximum transmission unit (MTU) for a custom IPv6 network on {op-system-first}. If you specified a low value for the MTU, the installation of the cluster would fail. With this release, the minimum MTU value for IPv6 networks is set to `1380`, where `1280` is the minimum MTU for IPv6 and `100` is the OVN-Kubernetes encapsulation overhead. With this release, the installation program now validates the MTU for a custom IPv6 network on {op-system-first}. (link:https://issues.redhat.com/browse/OCPBUGS-41812[OCPBUGS-41812]) -* Previously, the `rpm-ostree-fix-shadow-mode.service` service would run when you ran RHCOS in a live environment. As a result, the `rpm-ostree-fix-shadow-mode.service` service logged a failure that did not impact the deployment or live system. With this release, the `rpm-ostree-fix-shadow-mode.service` service will not run if the RHCOS is not running from an installed environment and the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-41621[*OCPBUGS-41621*]) +* Previously, the `rpm-ostree-fix-shadow-mode.service` service would run when you ran RHCOS in a live environment. As a result, the `rpm-ostree-fix-shadow-mode.service` service logged a failure that did not impact the deployment or live system. With this release, the `rpm-ostree-fix-shadow-mode.service` service will not run if the RHCOS is not running from an installed environment and the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-41621[OCPBUGS-41621]) [id="ocp-4-17-3-updating_{context}"] ==== Updating @@ -3755,22 +3755,22 @@ $ oc adm release info 4.17.2 --pullspecs [id="ocp-4-17-2-enhancements_{context}"] ==== Enhancements -* The Operator SDK now correctly scaffolds the Dockerfile for `kube-rbac-proxy`. Additionally, the Operator SDK can now use `-rhel9` container images. (link:https://issues.redhat.com/browse/OCPBUGS-42953[*OCPBUGS-42953*]) +* The Operator SDK now correctly scaffolds the Dockerfile for `kube-rbac-proxy`. Additionally, the Operator SDK can now use `-rhel9` container images. (link:https://issues.redhat.com/browse/OCPBUGS-42953[OCPBUGS-42953]) -* When you start the limited live migration method and an issue exists with network overlap, the Cluster Network Operator (CNO) can now expose network overlap metrics for the issue. This is possible because the `openshift_network_operator_live_migration_blocked` metric now includes the new `NetworkOverlap` label. (link:https://issues.redhat.com/browse/OCPBUGS-39121[*OCPBUGS-39121*]) +* When you start the limited live migration method and an issue exists with network overlap, the Cluster Network Operator (CNO) can now expose network overlap metrics for the issue. This is possible because the `openshift_network_operator_live_migration_blocked` metric now includes the new `NetworkOverlap` label. (link:https://issues.redhat.com/browse/OCPBUGS-39121[OCPBUGS-39121]) [id="ocp-4-17-2-bug-fixes_{context}"] ==== Bug fixes -* Previously, the approval mechanism for certificate signing requests (CSRs) failed because the node name and internal DNS entry for a CSR did not match in terms of character case differences. With this release, an update to the approval mechanism for CSRs skips case-sensitive checks so that a CSR with a matching node name and internal DNS entry does not fail the check because of character case differences. (link:https://issues.redhat.com/browse/OCPBUGS-43312[*OCPBUGS-43312*]) +* Previously, the approval mechanism for certificate signing requests (CSRs) failed because the node name and internal DNS entry for a CSR did not match in terms of character case differences. With this release, an update to the approval mechanism for CSRs skips case-sensitive checks so that a CSR with a matching node name and internal DNS entry does not fail the check because of character case differences. (link:https://issues.redhat.com/browse/OCPBUGS-43312[OCPBUGS-43312]) -* Previously, a port conflict on the Cloud Credential Operator (CCO) and the `assisted-service` object caused cluster installations on {vmw-first} to fail. With this release, the installation program ignores the `pprof` module in the `assisted-service` object so that the port conflict no longer exists. (link:https://issues.redhat.com/browse/OCPBUGS-43069[*OCPBUGS-43069*]) +* Previously, a port conflict on the Cloud Credential Operator (CCO) and the `assisted-service` object caused cluster installations on {vmw-first} to fail. With this release, the installation program ignores the `pprof` module in the `assisted-service` object so that the port conflict no longer exists. (link:https://issues.redhat.com/browse/OCPBUGS-43069[OCPBUGS-43069]) -* Previously, when you attempted to use the `oc import-image` command to import an image in a {hcp} cluster, the command failed because of access issues with a private image registry. With this release, an update to `openshift-apiserver` pods in a {hcp} cluster resolves names that use the data plane so that the `oc import-image` command now works as expected with private image registries. (link:https://issues.redhat.com/browse/OCPBUGS-43051[*OCPBUGS-43051*]) +* Previously, when you attempted to use the `oc import-image` command to import an image in a {hcp} cluster, the command failed because of access issues with a private image registry. With this release, an update to `openshift-apiserver` pods in a {hcp} cluster resolves names that use the data plane so that the `oc import-image` command now works as expected with private image registries. (link:https://issues.redhat.com/browse/OCPBUGS-43051[OCPBUGS-43051]) -* Previously, for managed services on {hcp}, audit logs were sent to a local webhook service, `audit-webhook`. This caused issues for {hcp} pods that sent audit logs through the `konnectivity` service. With this release, `audit-webhook` is added to the list of `no_proxy` hosts so that {hcp} pods can send auti logs to the `audit-webhook` service. (link:https://issues.redhat.com/browse/OCPBUGS-42974[*OCPBUGS-42974*]) +* Previously, for managed services on {hcp}, audit logs were sent to a local webhook service, `audit-webhook`. This caused issues for {hcp} pods that sent audit logs through the `konnectivity` service. With this release, `audit-webhook` is added to the list of `no_proxy` hosts so that {hcp} pods can send auti logs to the `audit-webhook` service. (link:https://issues.redhat.com/browse/OCPBUGS-42974[OCPBUGS-42974]) -* Previously, when you used the Agent-based Installer to install a cluster, `assisted-installer-controller` timed out or exited the installation process depending on whether `assisted-service` was unavailable on the rendezvous host. This situation caused the cluster installation to fail during CSR approval checks. With this release, an update to `assisted-installer-controller` ensures that the controller does not timeout or exit if `assisted-service` is unavailable. The CSR approval check now works as expected. (link:https://issues.redhat.com/browse/OCPBUGS-42839[*OCPBUGS-42839*]) +* Previously, when you used the Agent-based Installer to install a cluster, `assisted-installer-controller` timed out or exited the installation process depending on whether `assisted-service` was unavailable on the rendezvous host. This situation caused the cluster installation to fail during CSR approval checks. With this release, an update to `assisted-installer-controller` ensures that the controller does not timeout or exit if `assisted-service` is unavailable. The CSR approval check now works as expected. (link:https://issues.redhat.com/browse/OCPBUGS-42839[OCPBUGS-42839]) * Previously, running the `openshift-install gather bootstrap --dir ` command might cause the installation program to skip the analysis of the collected logs. The command would output the following message: + @@ -3779,15 +3779,15 @@ $ oc adm release info 4.17.2 --pullspecs Invalid log bundle or the bootstrap machine could not be reached and bootstrap logs were not collected ---- + -With this release, the installation program can now analyze log handles that the `gather bootstrap --dir ` argument generates. (link:https://issues.redhat.com/browse/OCPBUGS-42806[*OCPBUGS-42806*]) +With this release, the installation program can now analyze log handles that the `gather bootstrap --dir ` argument generates. (link:https://issues.redhat.com/browse/OCPBUGS-42806[OCPBUGS-42806]) -* Previously, when you used the *Developer* perspective with custom editors on the {product-title} web console, entering the `n` keyboard shortcut caused the namespace menu to unexpectedly open. This issue happened because the keyboard shortcut key did not account for custom editors. With this release, the namespace menu now accounts for custom editors and does not unexpectedly open when you enter the `n` keyboard shortcut. (link:https://issues.redhat.com/browse/OCPBUGS-42607[*OCPBUGS-42607*]) +* Previously, when you used the *Developer* perspective with custom editors on the {product-title} web console, entering the `n` keyboard shortcut caused the namespace menu to unexpectedly open. This issue happened because the keyboard shortcut key did not account for custom editors. With this release, the namespace menu now accounts for custom editors and does not unexpectedly open when you enter the `n` keyboard shortcut. (link:https://issues.redhat.com/browse/OCPBUGS-42607[OCPBUGS-42607]) -* Previously, the installation program did not validate the maximum transmission unit (MTU) for a custom IPv6 network on {op-system-first}. If you specified a low value for the MTU, installation of the cluster would fail. With this release, the minimum MTU value for IPv6 networks is set to `1380`, where `1280` is the minimum MTU for IPv6 and `100` is the OVN-Kubernetes encapsulation overhead. With this release, the installation program now validates the MTU for a custom IPv6 network on {op-system-first} (link:https://issues.redhat.com/browse/OCPBUGS-41812[*OCPBUGS-41812*]) +* Previously, the installation program did not validate the maximum transmission unit (MTU) for a custom IPv6 network on {op-system-first}. If you specified a low value for the MTU, installation of the cluster would fail. With this release, the minimum MTU value for IPv6 networks is set to `1380`, where `1280` is the minimum MTU for IPv6 and `100` is the OVN-Kubernetes encapsulation overhead. With this release, the installation program now validates the MTU for a custom IPv6 network on {op-system-first} (link:https://issues.redhat.com/browse/OCPBUGS-41812[OCPBUGS-41812]) -* Previously, a {hcp} cluster that used mirroring release images might result in existing node pools to use the hosted cluster's operating system version instead of the `NodePool` version. With this release, a fix ensures that node pools use their own versions. (link:https://issues.redhat.com/browse/OCPBUGS-41552[*OCPBUGS-41552*]) +* Previously, a {hcp} cluster that used mirroring release images might result in existing node pools to use the hosted cluster's operating system version instead of the `NodePool` version. With this release, a fix ensures that node pools use their own versions. (link:https://issues.redhat.com/browse/OCPBUGS-41552[OCPBUGS-41552]) -* Previously, after you creating a private {product-title} cluster on {azure-first}, the installation program did not mark the storage account that it created as private. As a result, the storage account was publically available. With this release, the installation program now correctly always marks the storage account as private regardless if the cluster is publically or privately available. (link:https://issues.redhat.com/browse/OCPBUGS-42349[*OCPBUGS-42349*]) +* Previously, after you creating a private {product-title} cluster on {azure-first}, the installation program did not mark the storage account that it created as private. As a result, the storage account was publically available. With this release, the installation program now correctly always marks the storage account as private regardless if the cluster is publically or privately available. (link:https://issues.redhat.com/browse/OCPBUGS-42349[OCPBUGS-42349]) [id="ocp-4-17-2-updating_{context}"] ==== Updating @@ -3813,77 +3813,77 @@ $ oc adm release info 4.17.1 --pullspecs [id="ocp-4-17-1-enhancements_{context}"] ==== Enhancements -* The Operator SDK now correctly scaffolds the Dockerfile for `ansible-operator`. Additionally, the Operator SDK can now use `-rhel9` container images. (link:https://issues.redhat.com/browse/OCPBUGS-42853[*OCPBUGS-42853*]) +* The Operator SDK now correctly scaffolds the Dockerfile for `ansible-operator`. Additionally, the Operator SDK can now use `-rhel9` container images. (link:https://issues.redhat.com/browse/OCPBUGS-42853[OCPBUGS-42853]) -* The Operator SDK now correctly scaffolds the Dockerfile for `helm-operator`. Additionally, the Operator SDK can now use `-rhel9` container images. (link:https://issues.redhat.com/browse/OCPBUGS-42786[*OCPBUGS-42786*]) +* The Operator SDK now correctly scaffolds the Dockerfile for `helm-operator`. Additionally, the Operator SDK can now use `-rhel9` container images. (link:https://issues.redhat.com/browse/OCPBUGS-42786[OCPBUGS-42786]) -* When you install the {ols-official}, which is a Developer Preview feature only, the checkbox for enabling in-cluster monitoring is now enabled by default. (link:https://issues.redhat.com/browse/OCPBUGS-42380[*OCPBUGS-42380*]) +* When you install the {ols-official}, which is a Developer Preview feature only, the checkbox for enabling in-cluster monitoring is now enabled by default. (link:https://issues.redhat.com/browse/OCPBUGS-42380[OCPBUGS-42380]) -* The installation program now uses a newer version of the `cluster-api-provider-ibmcloud` provider that includes Transit Gateway fixes. (link:https://issues.redhat.com/browse/OCPBUGS-42483[*OCPBUGS-42483*]) +* The installation program now uses a newer version of the `cluster-api-provider-ibmcloud` provider that includes Transit Gateway fixes. (link:https://issues.redhat.com/browse/OCPBUGS-42483[OCPBUGS-42483]) * The migrating CNS volumes feature, which is a Developer Preview feature only, includes the following enhancements: + -** The feature now checks for the vCenter version before moving CNS volumes to {vmw-first}. (link:https://issues.redhat.com/browse/OCPBUGS-42006[*OCPBUGS-42006*]) -** The feature keeps migrating CNS volumes even if some volumes do not exist, so that the migration operation does not exit when no volume exists. (link:https://issues.redhat.com/browse/OCPBUGS-42008[*OCPBUGS-42008*]) +** The feature now checks for the vCenter version before moving CNS volumes to {vmw-first}. (link:https://issues.redhat.com/browse/OCPBUGS-42006[OCPBUGS-42006]) +** The feature keeps migrating CNS volumes even if some volumes do not exist, so that the migration operation does not exit when no volume exists. (link:https://issues.redhat.com/browse/OCPBUGS-42008[OCPBUGS-42008]) -* The vSphere CSI Driver Operator can now delete all resources for a vSphere CSI driver that was removed from a cluster. (link:https://issues.redhat.com/browse/OCPBUGS-42007[*OCPBUGS-42007*]) +* The vSphere CSI Driver Operator can now delete all resources for a vSphere CSI driver that was removed from a cluster. (link:https://issues.redhat.com/browse/OCPBUGS-42007[OCPBUGS-42007]) [id="ocp-4-17-1-bug-fixes_{context}"] ==== Bug fixes -* Previously, the Single-Root I/O Virtualization (SR-IOV) Operator did not expire the acquired lease during the Operator's shutdown operation. This impacted a new instance of the Operator, because the new instance had to wait for the lease to expire before the new instance was operational. With this release, an update to the Operator shutdown logic ensures that the Operator expires the lease when the Operator is shutting down. (link:https://issues.redhat.com/browse/OCPBUGS-37668[*OCPBUGS-37668*]) +* Previously, the Single-Root I/O Virtualization (SR-IOV) Operator did not expire the acquired lease during the Operator's shutdown operation. This impacted a new instance of the Operator, because the new instance had to wait for the lease to expire before the new instance was operational. With this release, an update to the Operator shutdown logic ensures that the Operator expires the lease when the Operator is shutting down. (link:https://issues.redhat.com/browse/OCPBUGS-37668[OCPBUGS-37668]) -* Previously, when you configured the image registry to use an {azure-first} storage account that was located in a resource group other than the cluster's resource group, the Image Registry Operator would become degraded. This occurred because of a validation error. With this release, an update to the Operator allows for authentication only by using a storage account key. Validation of other authentication requirements is not required. (link:https://issues.redhat.com/browse/OCPBUGS-42812[*OCPBUGS-42812*]) +* Previously, when you configured the image registry to use an {azure-first} storage account that was located in a resource group other than the cluster's resource group, the Image Registry Operator would become degraded. This occurred because of a validation error. With this release, an update to the Operator allows for authentication only by using a storage account key. Validation of other authentication requirements is not required. (link:https://issues.redhat.com/browse/OCPBUGS-42812[OCPBUGS-42812]) -* Previously, if availability zones were not in a specific order in the `install-config.yaml` configuration file, the installation program would wrongly sort the zones before saving the control plane machine set manifests. When the program created the machines, additional control plane virtual machines were created to reconcile the machines into each zone. This caused a resource-constraint issue. With this release, the installation program no longer sorts availability zones so that this issue no longer occurs. (link:https://issues.redhat.com/browse/OCPBUGS-42699[*OCPBUGS-42699*]) +* Previously, if availability zones were not in a specific order in the `install-config.yaml` configuration file, the installation program would wrongly sort the zones before saving the control plane machine set manifests. When the program created the machines, additional control plane virtual machines were created to reconcile the machines into each zone. This caused a resource-constraint issue. With this release, the installation program no longer sorts availability zones so that this issue no longer occurs. (link:https://issues.redhat.com/browse/OCPBUGS-42699[OCPBUGS-42699]) -* Previously, the Red{nbsp}Hat {product-title} web console did not require the `Creator` field as a mandatory field. API changes specified an empty value for this field, but a user profile could still create silent alerts. With this release, the API marks the `Creator` field as a mandatory field for a user profile. (link:https://issues.redhat.com/browse/OCPBUGS-42606[*OCPBUGS-42606*]) +* Previously, the Red{nbsp}Hat {product-title} web console did not require the `Creator` field as a mandatory field. API changes specified an empty value for this field, but a user profile could still create silent alerts. With this release, the API marks the `Creator` field as a mandatory field for a user profile. (link:https://issues.redhat.com/browse/OCPBUGS-42606[OCPBUGS-42606]) -* Previously, during root certification rotation, the Ingress Operator and DNS Operator failed to start. With this release, an update to the kubeconfigs for the Ingress Operator and DNS Operator ensure that annotations set the conditions for managing the public key infrastructure (PKI). This update ensures that both Operators can start as expected during root certification rotation. (link:https://issues.redhat.com/browse/OCPBUGS-42261[*OCPBUGS-42261*]) +* Previously, during root certification rotation, the Ingress Operator and DNS Operator failed to start. With this release, an update to the kubeconfigs for the Ingress Operator and DNS Operator ensure that annotations set the conditions for managing the public key infrastructure (PKI). This update ensures that both Operators can start as expected during root certification rotation. (link:https://issues.redhat.com/browse/OCPBUGS-42261[OCPBUGS-42261]) -* Previously, during root certification rotation, the `metrics-server` pod in the data plane failed to start correctly. This happened because of a certificate issue. With this release, the `hostedClusterConfigOperator` resource sends the correct certificate to the data plane so that the `metrics-server` pod starts as expected. (link:https://issues.redhat.com/browse/OCPBUGS-42098[*OCPBUGS-42098*]) +* Previously, during root certification rotation, the `metrics-server` pod in the data plane failed to start correctly. This happened because of a certificate issue. With this release, the `hostedClusterConfigOperator` resource sends the correct certificate to the data plane so that the `metrics-server` pod starts as expected. (link:https://issues.redhat.com/browse/OCPBUGS-42098[OCPBUGS-42098]) -* Previously, the installation program attempted to create a private zone for a cluster that needed to be installed on a {gcp-full} shared virtual private network (VPC). This caused the installation of the cluster to fail. With this release, a fix skips the creation of the private zone so that this cluster installation issue no longer exists. (link:https://issues.redhat.com/browse/OCPBUGS-42142[*OCPBUGS-42142*]) +* Previously, the installation program attempted to create a private zone for a cluster that needed to be installed on a {gcp-full} shared virtual private network (VPC). This caused the installation of the cluster to fail. With this release, a fix skips the creation of the private zone so that this cluster installation issue no longer exists. (link:https://issues.redhat.com/browse/OCPBUGS-42142[OCPBUGS-42142]) -* Previously, when the installation program installed a cluster on a {gcp-full} VPC, role bindings for the control plane service account were not removed by the program. With this release, a fix removes the role bindings so that your cluster no longer includes these artifacts. (link:https://issues.redhat.com/browse/OCPBUGS-42116[*OCPBUGS-42116*]) +* Previously, when the installation program installed a cluster on a {gcp-full} VPC, role bindings for the control plane service account were not removed by the program. With this release, a fix removes the role bindings so that your cluster no longer includes these artifacts. (link:https://issues.redhat.com/browse/OCPBUGS-42116[OCPBUGS-42116]) -* Previously, if you enabled on-cluster layering for your cluster and you attempted to configure kernel arguments in the machine configuration, machine config pools (MCPs) and nodes entered a degraded state. This happened because of a configuration mismatch. With this release, a check for kernel arguments for a cluster with OCL-enabled ensures that the arguments are configured and applied to nodes in the cluster. This update prevents any mismatch that previously occurred between the machine configuration and the node configuration. (link:https://issues.redhat.com/browse/OCPBUGS-42081[*OCPBUGS-42081*]) +* Previously, if you enabled on-cluster layering for your cluster and you attempted to configure kernel arguments in the machine configuration, machine config pools (MCPs) and nodes entered a degraded state. This happened because of a configuration mismatch. With this release, a check for kernel arguments for a cluster with OCL-enabled ensures that the arguments are configured and applied to nodes in the cluster. This update prevents any mismatch that previously occurred between the machine configuration and the node configuration. (link:https://issues.redhat.com/browse/OCPBUGS-42081[OCPBUGS-42081]) -* Previously, creating cron jobs to create pods for your cluster caused the component that fetches the pods to fail. Because of this issue, the *Topology* page on the {product-title} web console failed. With this release, a `3` second delay is configured for the component that fetches pods that are generated from the cron job so that this issue no longer exists. (link:https://issues.redhat.com/browse/OCPBUGS-41685[*OCPBUGS-41685*]) +* Previously, creating cron jobs to create pods for your cluster caused the component that fetches the pods to fail. Because of this issue, the *Topology* page on the {product-title} web console failed. With this release, a `3` second delay is configured for the component that fetches pods that are generated from the cron job so that this issue no longer exists. (link:https://issues.redhat.com/browse/OCPBUGS-41685[OCPBUGS-41685]) -* Previously, when you deployed an {product-title} cluster that listed a `TechPreviewNoUpgrade` feature gate in its configured on {rh-openstack}, the `cluster-capi-operator` pod crashed. This occurred because the Cluster CAPI Operator expected a different API version than the one that was served. With this release, an update to the Cluster CAPI Operator ensures that the Operator uses the correct version of the API so that this issue no longer occurs. (link:https://issues.redhat.com/browse/OCPBUGS-41576[*OCPBUGS-41576*]) +* Previously, when you deployed an {product-title} cluster that listed a `TechPreviewNoUpgrade` feature gate in its configured on {rh-openstack}, the `cluster-capi-operator` pod crashed. This occurred because the Cluster CAPI Operator expected a different API version than the one that was served. With this release, an update to the Cluster CAPI Operator ensures that the Operator uses the correct version of the API so that this issue no longer occurs. (link:https://issues.redhat.com/browse/OCPBUGS-41576[OCPBUGS-41576]) -* Previously, using DNF to install additional packages on your customized {op-system-first} builds caused builds to fail because packages could not be located. With this release, the Subscription Manager adds the correct packages to {op-system} so that this issue no longer occurs. (link:https://issues.redhat.com/browse/OCPBUGS-41376[*OCPBUGS-41376*]) +* Previously, using DNF to install additional packages on your customized {op-system-first} builds caused builds to fail because packages could not be located. With this release, the Subscription Manager adds the correct packages to {op-system} so that this issue no longer occurs. (link:https://issues.redhat.com/browse/OCPBUGS-41376[OCPBUGS-41376]) -* Previosuly, bonds that were configured in `active-backup` mode would have EFI System Partition (ESP) offload active even if underlying links did not support ESP offload. This caused IPsec associations to fail. With this release, ESP offload is disabled for bonds so that IPsec associations pass. (link:https://issues.redhat.com/browse/OCPBUGS-41255[*OCPBUGS-41255*]) +* Previosuly, bonds that were configured in `active-backup` mode would have EFI System Partition (ESP) offload active even if underlying links did not support ESP offload. This caused IPsec associations to fail. With this release, ESP offload is disabled for bonds so that IPsec associations pass. (link:https://issues.redhat.com/browse/OCPBUGS-41255[OCPBUGS-41255]) -* Previosuly, resources for a new user account were not removed when the account was deleted. This caused unnecessary information in config maps, roles, and role-bindings. With this release, an `ownerRef` tag is added to these resources, so that when you delete a user account the resources are also deleted from all cluster resources. (link:https://issues.redhat.com/browse/OCPBUGS-39601[*OCPBUGS-39601*]) +* Previosuly, resources for a new user account were not removed when the account was deleted. This caused unnecessary information in config maps, roles, and role-bindings. With this release, an `ownerRef` tag is added to these resources, so that when you delete a user account the resources are also deleted from all cluster resources. (link:https://issues.redhat.com/browse/OCPBUGS-39601[OCPBUGS-39601]) -* Previosuly, a coding issue caused the Ansible script on {op-system} user-provisioned installation infrastructure to fail. This occurred when IPv6 was enabled for a three-node cluster. With this release, support exists for installing a three-node cluster with IPv6 enabled on {op-system}. (link:https://issues.redhat.com/browse/OCPBUGS-39409[*OCPBUGS-39409*]) +* Previosuly, a coding issue caused the Ansible script on {op-system} user-provisioned installation infrastructure to fail. This occurred when IPv6 was enabled for a three-node cluster. With this release, support exists for installing a three-node cluster with IPv6 enabled on {op-system}. (link:https://issues.redhat.com/browse/OCPBUGS-39409[OCPBUGS-39409]) -* Previously, the order of an Ansible Playbook was modified to run before the `metadata.json` file was created, which caused issues with older versions of Ansible. With this release, the playbook is more tolerant of missing files and the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-39286[*OCPBUGS-39286*]) +* Previously, the order of an Ansible Playbook was modified to run before the `metadata.json` file was created, which caused issues with older versions of Ansible. With this release, the playbook is more tolerant of missing files and the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-39286[OCPBUGS-39286]) -* Previously, when the Node Tuning Operator (NTO) was configured to use `PerformanceProfiles`, NTO would create an `ocp-tuned-one-shot systemd` service. The `systemd` service would run before kubelet and blocked execution. The `systemd` service invokes Podman which uses an NTO image, but when the NTO image was not present Podman still tried to fetch the image and it would fail. With this release, support is added for cluster-wide proxy environment variables defined in `/etc/mco/proxy.env`. Now, Podman pulls NTO images in environments which need to use proxies for out-of-cluster connections. (link:https://issues.redhat.com/browse/OCPBUGS-39124[*OCPBUGS-39124*]) +* Previously, when the Node Tuning Operator (NTO) was configured to use `PerformanceProfiles`, NTO would create an `ocp-tuned-one-shot systemd` service. The `systemd` service would run before kubelet and blocked execution. The `systemd` service invokes Podman which uses an NTO image, but when the NTO image was not present Podman still tried to fetch the image and it would fail. With this release, support is added for cluster-wide proxy environment variables defined in `/etc/mco/proxy.env`. Now, Podman pulls NTO images in environments which need to use proxies for out-of-cluster connections. (link:https://issues.redhat.com/browse/OCPBUGS-39124[OCPBUGS-39124]) -* Previously, the resource type filter for the *Events* page on the {product-title} web console wrongly reported the number of resources when you selected more than three resources. With this release, the filter now reports the correct number of resources based on your resource selection. (link:https://issues.redhat.com/browse/OCPBUGS-39091[*OCPBUGS-39091*]) +* Previously, the resource type filter for the *Events* page on the {product-title} web console wrongly reported the number of resources when you selected more than three resources. With this release, the filter now reports the correct number of resources based on your resource selection. (link:https://issues.redhat.com/browse/OCPBUGS-39091[OCPBUGS-39091]) -* Previously, Ironic inspection failed if special or invalid characters existed in the serial number of a block device. This occurred because the `lsblk` command failed to escape the characters. With this release, the command now escapes the characters so this issue no longer persists. (link:https://issues.redhat.com/browse/OCPBUGS-39013[*OCPBUGS-39013*]) +* Previously, Ironic inspection failed if special or invalid characters existed in the serial number of a block device. This occurred because the `lsblk` command failed to escape the characters. With this release, the command now escapes the characters so this issue no longer persists. (link:https://issues.redhat.com/browse/OCPBUGS-39013[OCPBUGS-39013]) -* Previously, when you used the Redfish Virtual Media to add an xFusion bare-metal node to your cluster, the node did not get added because of a node registration issue. The issue occurred because the hardware was not 100% compliant with Redfish. With this release, you can now add xFusion bare-metal nodes to your cluster. (link:https://issues.redhat.com/browse/OCPBUGS-38784[*OCPBUGS-38784*]) +* Previously, when you used the Redfish Virtual Media to add an xFusion bare-metal node to your cluster, the node did not get added because of a node registration issue. The issue occurred because the hardware was not 100% compliant with Redfish. With this release, you can now add xFusion bare-metal nodes to your cluster. (link:https://issues.redhat.com/browse/OCPBUGS-38784[OCPBUGS-38784]) -* Previously, on the *Developer* perspective on the {product-title} web console, when you navigated to *Observe* > *Metrics*, two *Metrics* tabs existed. With this release, the duplicate tab is removed and now exists in the `openshift-monitoring/monitoring-plugin` application that serves the *Metrics* tabs on the web console. (link:https://issues.redhat.com/browse/OCPBUGS-38462[*OCPBUGS-38462*]) +* Previously, on the *Developer* perspective on the {product-title} web console, when you navigated to *Observe* > *Metrics*, two *Metrics* tabs existed. With this release, the duplicate tab is removed and now exists in the `openshift-monitoring/monitoring-plugin` application that serves the *Metrics* tabs on the web console. (link:https://issues.redhat.com/browse/OCPBUGS-38462[OCPBUGS-38462]) -* Previously, the `manila-csi-driver` and node registrar pods had missing healthchecks because of a configuration issue. With this release, the health checks are now added to both of these resources. (link:https://issues.redhat.com/browse/OCPBUGS-38457[*OCPBUGS-38457*]) +* Previously, the `manila-csi-driver` and node registrar pods had missing healthchecks because of a configuration issue. With this release, the health checks are now added to both of these resources. (link:https://issues.redhat.com/browse/OCPBUGS-38457[OCPBUGS-38457]) -* Previously, updating the `additionalTrustBundle` parameter in a {hcp} cluster configuration did not get applied to compute nodes. With this release, a fix ensures that updates to the `additionalTrustBundle` parameter automatically apply to compute nodes that exist in your {hcp} cluster. (link:https://issues.redhat.com/browse/OCPBUGS-36680[*OCPBUGS-36680*]) +* Previously, updating the `additionalTrustBundle` parameter in a {hcp} cluster configuration did not get applied to compute nodes. With this release, a fix ensures that updates to the `additionalTrustBundle` parameter automatically apply to compute nodes that exist in your {hcp} cluster. (link:https://issues.redhat.com/browse/OCPBUGS-36680[OCPBUGS-36680]) -* Previously, with oc-mirror plugin v2 (Technology Preview), images that referenced both `tag` and `digest` references were not supported. During the disk-to-mirror process for fully disconnected environments, the images were skipped and this caused build issues for the archive file. With this release, oc-mirror plugin v2 now supports an image that includes both of these references. An image is now pulled from the `digest` reference and keeps the `tag` reference for information purposes, while an appropriate warning message is displayed in the console output. (link:https://issues.redhat.com/browse/OCPBUGS-42421[*OCPBUGS-42421*]) +* Previously, with oc-mirror plugin v2 (Technology Preview), images that referenced both `tag` and `digest` references were not supported. During the disk-to-mirror process for fully disconnected environments, the images were skipped and this caused build issues for the archive file. With this release, oc-mirror plugin v2 now supports an image that includes both of these references. An image is now pulled from the `digest` reference and keeps the `tag` reference for information purposes, while an appropriate warning message is displayed in the console output. (link:https://issues.redhat.com/browse/OCPBUGS-42421[OCPBUGS-42421]) -* Previously, the Cluster API used an unsupported tag template for a virtual network installation when compared with the default non-cluster-API-provisioned installation. This caused the Image Registry Operator to enter a degraded state when configured with `networkAccess: Internal`. With this release, the Image Registry Operator now supports both tag templates so that this issue no longer exists. (link:https://issues.redhat.com/browse/OCPBUGS-42394[*OCPBUGS-42394*]) +* Previously, the Cluster API used an unsupported tag template for a virtual network installation when compared with the default non-cluster-API-provisioned installation. This caused the Image Registry Operator to enter a degraded state when configured with `networkAccess: Internal`. With this release, the Image Registry Operator now supports both tag templates so that this issue no longer exists. (link:https://issues.redhat.com/browse/OCPBUGS-42394[OCPBUGS-42394]) -* Previously, the Cloud Controller Manager (CCM) liveness probe used on {ibm-cloud-title} cluster installations could not use loopback and this caused the probe to continuously restart. With this release, the probe can use loopback so that this issue not longer occurs. (link:https://issues.redhat.com/browse/OCPBUGS-41941[*OCPBUGS-41941*]) +* Previously, the Cloud Controller Manager (CCM) liveness probe used on {ibm-cloud-title} cluster installations could not use loopback and this caused the probe to continuously restart. With this release, the probe can use loopback so that this issue not longer occurs. (link:https://issues.redhat.com/browse/OCPBUGS-41941[OCPBUGS-41941]) -* Previously, when the `globallyDisableIrqLoadBalancing` field was set to `true` in the `PerformanceProfile` object, the isolated CPUs were listed in the `IRQBALANCE_BANNED_CPULIST` variable instead of the `IRQBALANCE_BANNED_CPUS` variable. These variables are stored in `/etc/sysconfig/irqbalance`. Changing the value of the `globallyDisableIrqLoadBalancing` field from `true` to `false` did not update the `IRQBALANCE_BANNED_CPULIST` variable correctly. As a result, the number of CPUs available for load rebalancing did not increase because the isolated CPUs remained in the `IRQBALANCE_BANNED_CPULIST` variable. With this release, a fix ensures that isolated CPUs are now listed in the `IRQBALANCE_BANNED_CPUS` variable, so that the number of CPUs available for load rebalancing increase as expected. (link:https://issues.redhat.com/browse/OCPBUGS-42323[*OCPBUGS-42323*]) +* Previously, when the `globallyDisableIrqLoadBalancing` field was set to `true` in the `PerformanceProfile` object, the isolated CPUs were listed in the `IRQBALANCE_BANNED_CPULIST` variable instead of the `IRQBALANCE_BANNED_CPUS` variable. These variables are stored in `/etc/sysconfig/irqbalance`. Changing the value of the `globallyDisableIrqLoadBalancing` field from `true` to `false` did not update the `IRQBALANCE_BANNED_CPULIST` variable correctly. As a result, the number of CPUs available for load rebalancing did not increase because the isolated CPUs remained in the `IRQBALANCE_BANNED_CPULIST` variable. With this release, a fix ensures that isolated CPUs are now listed in the `IRQBALANCE_BANNED_CPUS` variable, so that the number of CPUs available for load rebalancing increase as expected. (link:https://issues.redhat.com/browse/OCPBUGS-42323[OCPBUGS-42323]) [id="ocp-4-17-1-updating_{context}"] ==== Updating @@ -3916,7 +3916,7 @@ $ oc adm release info 4.17.0 --pullspecs The `IRQBALANCE_BANNED_CPULIST` variable and the `IRQBALANCE_BANNED_CPUS` variable are stored in the `/etc/sysconfig/irqbalance` file. ==== + -(link:https://issues.redhat.com/browse/OCPBUGS-42323[*OCPBUGS-42323*]) +(link:https://issues.redhat.com/browse/OCPBUGS-42323[OCPBUGS-42323]) [id="ocp-4-17-0-updating_{context}"] ==== Updating