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 #88939 from dfitzmau/OSDOCS-12237-pa-rhcos-win

Browse Source 
OSDOCS-12237-pa-rhcos-win: Bug batched pa-rhcos-win
This commit is contained in:
Darragh Fitzmaurice
2025-02-20 13:32:44 +00:00
committed by GitHub
parent 3ce3a2bbaf 0bbdcf731d
commit 7bf47c2f52
1 changed files with 21 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
release_notes/ocp-4-18-release-notes.adoc
View File

@@ -1594,13 +1594,6 @@ If these values are not defined in a failure domain configuration, for instance
[id="ocp-release-note-node-tuning-operator-bug-fixes_{context}"]
==== Node Tuning Operator (NTO)
* Previously, if you specified a long string of isolated CPUs in a performance profile, such as `0,1,2,...,512`, the `tuned`, Machine Config Operator, and `rpm-ostree` components failed to process the string as expected. As a consequence, after you applied the performance profile, the expected kernel arguments were missing. The system failed silently with no reported errors. With this release, the string for isolated CPUs in a performance profile is converted to sequential ranges, such as `0-512`. As a result, the kernel arguments are applied as expected in most scenarios. (link:https://issues.redhat.com/browse/OCPBUGS-45264[*OCPBUGS-45264*])
+
[NOTE]
====
The issue might still occur with some combinations of input for isolated CPUs in a performance profile, such as a long list of odd numbers `1,3,5,...,511`.
====
* Previously, CPU masks for interrupt and network handling CPU affinity were computed incorrectly on machines with more than 256 CPUs. This issue prevented proper CPU isolation and caused `systemd` unit failures during internal node configuration. This fix ensures accurate CPU affinity calculations, enabling correct CPU isolation on machines with more than 256 CPUs. (link:https://issues.redhat.com/browse/OCPBUGS-36431[*OCPBUGS-36431*])
* Previously, entering an invalid value in any `cpuset` field under `spec.cpu` in the `PerformanceProfile` resource caused the webhook validation to crash. With this release, improved error handling for the `PerformanceProfile` validation webhook ensures that invalid values for these fields return an informative error. (link:https://issues.redhat.com/browse/OCPBUGS-45616[*OCPBUGS-45616*])
@@ -1621,10 +1614,29 @@ The issue might still occur with some combinations of input for isolated CPUs in
[id="ocp-release-note-openshift-api-server-bug-fixes_{context}"]
==== OpenShift API server
[discrete]
[id="ocp-release-note-pao-bug-fixes_{context}"]
==== Performance Addon Operator
* 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*])
* Previously, if you specified a long string of isolated CPUs in a performance profile, such as `0,1,2,...,512`, the `tuned`, Machine Config Operator and `rpm-ostree` components failed to process the string as expected. As a consequence, after you applied the performance profile, the expected kernel arguments were missing. The system failed silently with no reported errors. With this release, the string for isolated CPUs in a performance profile is converted to sequential ranges, such as `0-512`. As a result, the kernel arguments are applied as expected in most scenarios. (link:https://issues.redhat.com/browse/OCPBUGS-45264[*OCPBUGS-45264*])
+
[NOTE]
====
The issue might still occur with some combinations of input for isolated CPUs in a performance profile, such as a long list of odd numbers `1,3,5,...,511`.
====
[discrete]
[id="ocp-release-note-rhcos-bug-fixes_{context}"]
==== {op-system-first}
* Previously, the `kdump` initramfs would stop responding when trying to open a local encrypted disk. This occurred even when the `kdump` destination was a remote machine that did not need access to the local disk. With this release, the issue is fixed and the `kdump` initramfs successfully opens a local encrypted disk. (link:https://issues.redhat.com/browse/OCPBUGS-43040[*OCPBUGS-43040*])
* Previously, explicitly disabling FIPS mode with `fips=0` caused some systemd services, that assume FIPS mode was requested, to run and consequently fail. This issue resulted in {op-system} failing to boot. With this release, the relevant systemd services now only run if FIPS mode is enabled by specifying `fips=1`. As a result, {op-system} now correctly boots without FIPS mode enabled when `fips=0` is specified. (link:https://issues.redhat.com/browse/OCPBUGS-39536[*OCPBUGS-39536*])
[discrete]
[id="ocp-release-note-scalability-and-performance-bug-fixes_{context}"]
==== Scalability and performance
@@ -2211,6 +2223,8 @@ In the following tables, features are marked with the following statuses:
[id="ocp-4-18-known-issues_{context}"]
== Known issues
* 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*])
* 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-43713[*OCPBUGS-43713*])
* There is a known issue with {op-base-system} 8 worker nodes that use `cgroupv1` Linux Control Groups (cgroup). The following is an example of the error message displayed for impacted nodes: `UDN are not supported on the node ip-10-0-51-120.us-east-2.compute.internal as it uses cgroup v1.` As a workaround, users should migrate worker nodes from `cgroupv1` to `cgroupv2`. (link:https://issues.redhat.com/browse/OCPBUGS-49933[*OCPBUGS-49933*])