openshift/openshift-docs
1
0
Fork 0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00
Code Issues Releases Activity

Merge pull request #100678 from bergerhoffer/420-rn-typo-check

Browse Source 
Typo fixes [No OSDOCS]
This commit is contained in:
Andrea Hoffer
2025-10-17 09:50:43 -04:00
committed by GitHub
parent c4d873b315 69aa01f33d
commit 2f7e1f6602
1 changed files with 4 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
release_notes/ocp-4-20-release-notes.adoc
View File

@@ -1693,7 +1693,7 @@ As a result, the controller handles errors during migration better.
* Before this update, the Machine Config Operator (MCO) was updating node boot images without checking whether the current boot image was from {gcp-first} or {aws-first} Marketplace. As a consequence, the MCO would override a marketplace boot image with a standard {product-title} image. With this release, for {aws-short} images, the MCO has a lookup table that has all of the standard {product-title} installer Advanced Metering Infrastructures (AMIs), which it references before updating the boot image. For {gcp-first} images, the MCO checks the URL header before updating the boot image. As a result, the MCO no longer updates machine sets that have a marketplace boot image. (link:https://issues.redhat.com/browse/OCPBUGS-57426[OCPBUGS-57426])
* Before this update, {product-title} updates that shipped a change to Core DNS templates would restart the `coredns` pod before the image pull for the updated base operating system (OS) image. As a consequence, a race occurred when the operating system update manager failed failed the image pull because of network errors, causing the update to stall. With this release, a retry update operation is added to the the Machine Config Operator (MCO) to work around this race condition. https://issues.redhat.com/browse/OCPBUGS-43406[OCPBUGS-43406]
* Before this update, {product-title} updates that shipped a change to Core DNS templates would restart the `coredns` pod before the image pull for the updated base operating system (OS) image. As a consequence, a race occurred when the operating system update manager failed failed the image pull because of network errors, causing the update to stall. With this release, a retry update operation is added to the Machine Config Operator (MCO) to work around this race condition. https://issues.redhat.com/browse/OCPBUGS-43406[OCPBUGS-43406]
[id="ocp-release-note-management-console-bug-fixes_{context}"]
@@ -1724,7 +1724,7 @@ As a result, the controller handles errors during migration better.
* Before this update, when the Gateway API feature was enabled, it installed an Istio control plane configured with one pod replica and an associated `PodDisruptionBudget` setting. The `PodDisruptionBudget` setting prevented the only pod replica from being evicted, blocking cluster upgrades. With this release, the Ingress Operator prevents the Istio control plane from being configured with the `PodDisruptionBudget` setting. Cluster upgrades are no longer blocked by the pod replica. (link:https://issues.redhat.com/browse/OCPBUGS-58358[OCPBUGS-58358])
* Before this update, the Cluster Network Operator (CNO) stopped during a cluster upgrade when the `whereabouts-shim` network attachment was enabled. This issue occured because of a missing `release.openshift.io/version` annotation in the `openshift-multus` namespace. With this release, the missing annotation is now added to the cluster, so that the CNO no longer stops during a cluster upgrade when the `whereabouts-shim` attached is enabled. The cluster upgrade can now continue as expected. (link:https://issues.redhat.com/browse/OCPBUGS-57643[OCPBUGS-57643])
* Before this update, the Cluster Network Operator (CNO) stopped during a cluster upgrade when the `whereabouts-shim` network attachment was enabled. This issue occurred because of a missing `release.openshift.io/version` annotation in the `openshift-multus` namespace. With this release, the missing annotation is now added to the cluster, so that the CNO no longer stops during a cluster upgrade when the `whereabouts-shim` attached is enabled. The cluster upgrade can now continue as expected. (link:https://issues.redhat.com/browse/OCPBUGS-57643[OCPBUGS-57643])
* Before this update, the Ingress Operator added resources, most noteably gateway resources, to the `status.relatedObjects` parameter of the Cluster Operator even if the CRDs for those resources did not exist. Additionally, the Ingress Operator specified a namespace for the `istios` and `GatewayClass`resources, which are both cluster-scoped resources. As a result of these configurations, the `relatedObjects` parameter contained misleading information. With this release, an update to the status controller of the Ingress Operator ensures that the controller checks if these resources already exist and also checks the related feature gates before adding any of these resources to the `relatedObjects` parameter . The controller no longer specifies namespaces for the `GatewayClass` and `istio` resources. This update ensures that the `relatedObjects` parameter contains accurate information for the `GatewayClass` and `istio` resources. (link:https://issues.redhat.com/browse/OCPBUGS-57433[OCPBUGS-57433])
@@ -1747,7 +1747,7 @@ As a result, the controller handles errors during migration better.
* Before this release, the Container Runtime Interface-OpenShift (CRI-O) system failed to recognize the terminated state of a stateful set pod when the backend storage went down, causing the pod to remain in a `Terminating` state due to an inability to detect that the container process no longer existed. This caused resource inefficiency and potential service disruption. With this release, the CRI-O now correctly recognizes terminated pods, improving StatefulSet termination flow. (link:https://issues.redhat.com/browse/OCPBUGS-55485[OCPBUGS-55485])
* Before this update, if a CPU-pinned container within a Guaranteed QoS pod has cgroups quota defined, rounding and small delays in kernel CPU time accounting could cause throttling of the CPU-pinned process, even if the the quota is set to allow 100% consumption for each allocated CPU. With this release, when `cpu-manager-policy=static` and the qualifications for static CPU assignment are satisfied, that is containers have Guaranteed QOS with integer CPU requests, the CFS quota is disabled. (link:https://issues.redhat.com/browse/OCPBUGS-14051[OCPBUGS-14051])
* Before this update, if a CPU-pinned container within a Guaranteed QoS pod has cgroups quota defined, rounding and small delays in kernel CPU time accounting could cause throttling of the CPU-pinned process, even if the quota is set to allow 100% consumption for each allocated CPU. With this release, when `cpu-manager-policy=static` and the qualifications for static CPU assignment are satisfied, that is containers have Guaranteed QOS with integer CPU requests, the CFS quota is disabled. (link:https://issues.redhat.com/browse/OCPBUGS-14051[OCPBUGS-14051])
@@ -1799,7 +1799,7 @@ As a result, the controller handles errors during migration better.
* Before this update, when an Operator supplied more than one API in an Operator group namespace, {olmv0} made unnecessary update calls to the cluster roles that were created for the Operator group. As a result, these unnecessary calls caused churn for ectd and the API server. With this update, {olmv0} does not make unnecessary update calls to the cluster role objects in Operator groups. (link:https://issues.redhat.com/browse/OCPBUGS-57222[OCPBUGS-57222])
* Before this update, if the `olm-operator` pod crashed during cluster updates due to mislabeled resources, the notification message used the the `info` label. With this update, crash notification messages due to mislabeled resources use the `error` label instead. (link:https://issues.redhat.com/browse/OCPBUGS-53161[OCPBUGS-53161])
* Before this update, if the `olm-operator` pod crashed during cluster updates due to mislabeled resources, the notification message used the `info` label. With this update, crash notification messages due to mislabeled resources use the `error` label instead. (link:https://issues.redhat.com/browse/OCPBUGS-53161[OCPBUGS-53161])
* Before this update, the catalog Operator scheduled catalog snapshots for every 5 minutes. On clusters with many namespaces and subscriptions, snapshots failed and cascaded across catalog sources. As a result, the spikes in CPU loads effectively blocked installing and updating Operators. With this update, catalog snapshots are scheduled for every 30 minutes to allow enough time for the snapshotes to resolve. (link:https://issues.redhat.com/browse/OCPBUGS-43966[OCPBUGS-43966])