Skip to content

TELCODOCS-2840 - 4.22 TELCO RAN Known Issues #112319

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
slovern wants to merge 1 commit into
base: enterprise-4.22
Choose a base branch
from
+8 −0
Open

TELCODOCS-2840 - 4.22 TELCO RAN Known Issues #112319

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
8 changes: 8 additions & 0 deletions 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 @@ -5,3 +5,11 @@
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])

* When you run Cloud-native Network Functions (CNF) latency tests on an {product-title} cluster, the test might return results that exceed the latency threshold, such as 20 microseconds for cyclictest testing. This can result in intermittent test failures even when the cluster is correctly configured for low-latency workloads. As a workaround, revert the stalld backend to `sched_debug` to reduce the frequency and magnitude of latency spikes. (link:https://redhat.atlassian.net/browse/OCPBUGS-86339[OCPBUGS-86339])

* A race condition in Telecom Grandmaster (T-GM) PTP configurations can cause a 37-second offset at system startup. This occurs because `phc2sys` synchronizes the system clock before `ts2phc` has synchronized the hardware clock (PHC) from the GNSS signal. The 37-second offset corresponds to the current UTC-TAI leap second difference. This issue resolves itself once the PHC is properly synchronized from the GNSS signal. (link:https://redhat.atlassian.net/browse/OCPBUGS-85586[OCPBUGS-85586])

* After the cloud-event-proxy sidecar restarts, stale replay data from the linuxptp-daemon can race with live data over the event socket. This can cause the `openshift_ptp_clock_state` metric and the aggregate `/master` SyncStateChange cloud event to remain stuck at FREERUN or HOLDOVER, even when `ptp4l` has fully recovered to LOCKED state. As a workaround, restart the linuxptp-daemon pods. (link:https://redhat.atlassian.net/browse/OCPBUGS-85092[OCPBUGS-85092])

* When a Telecom Boundary Clock (T-BC) enters holdover, the `event.sync.sync-status.synchronization-state-change` event might report FREERUN instead of HOLDOVER. This is due to an issue in the calculation of the overall node sync state. As a workaround, use the worst state from the `event.sync.ptp-status.ptp-state-change` and `event.sync.sync-status.os-clock-sync-state-change` events, which are calculated correctly. Once the clock transitions out of holdover, the events return to sync. (link:https://redhat.atlassian.net/browse/OCPBUGS-86530[OCPBUGS-86530])