Skip to content

OSDOCS-18179-Bare-Metal-Networking-tavery:Bug Batching #112345

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
tedaveryredhat wants to merge 1 commit into
base: enterprise-4.22
Choose a base branch
from
+3 −1
Open

OSDOCS-18179-Bare-Metal-Networking-tavery:Bug Batching #112345

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion modules/rn-ocp-release-notes-known-issues.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,4 +4,6 @@

This section includes several known issues for {product-title} {product-version}.

* Currently, the `topo-aware-scheduler` provided by the NUMA Resources Operator (NRO) does not support Kubernetes priority-based preemption. When all NUMA zones on available nodes are fully consumed by lower-priority pods, a high-priority pod with a `PreemptLowerPriority` policy remains in `Pending` state indefinitely instead of preempting the lower-priority pods. As a consequence, workloads that depend on priority-based preemption for scheduling recovery do not function correctly when using the `topo-aware-scheduler`. (link:https://issues.redhat.com/browse/OCPBUGS-77930[OCPBUGS-77930])
* Booting the `Baremetalhost` object into the correct operating system repeatedly fails on certain Baseboard Management Controller (BMC) firmware versions because the SuperMicro ARS-111GL-NHR server boots into an existing hard drive instead of virtual media. This issue is caused by an unusual change of boot device names between `CD` and `USB CD` across firmware versions. As a consequence, the node inspection might fail. In this situation, try updating to the latest BMC and BIOS firmware or manually setting the `BootSourceOverrideTarget` parameter to `USB CD` instead of `CD` to successfully boot the node from the correct virtual media. (link:https://issues.redhat.com/browse/OCPBUGS-61851[OCPBUGS-61851])

* Currently, the `topo-aware-scheduler` provided by the NUMA Resources Operator (NRO) does not support Kubernetes priority-based preemption. When all NUMA zones on available nodes are fully consumed by lower-priority pods, a high-priority pod with a `PreemptLowerPriority` policy remains in `Pending` state indefinitely instead of preempting the lower-priority pods. As a consequence, workloads that depend on priority-based preemption for scheduling recovery do not function correctly when using the `topo-aware-scheduler`. (link:https://issues.redhat.com/browse/OCPBUGS-77930[OCPBUGS-77930])