-
Bug
-
Resolution: Unresolved
-
Critical
-
None
-
4.18.0
-
Critical
-
Yes
-
1
-
OCPEDGE Sprint 258
-
1
-
Approved
-
False
-
Component Readiness has found a potential regression in the following test:
[sig-node][apigroup:config.openshift.io] CPU Partitioning node validation should have correct cpuset and cpushare set in crio containers [Suite:openshift/conformance/parallel]
Probability of significant regression: 100.00%
Sample (being evaluated) Release: 4.18
Start Time: 2024-08-14T00:00:00Z
End Time: 2024-08-21T23:59:59Z
Success Rate: 94.89%
Successes: 128
Failures: 7
Flakes: 2
Base (historical) Release: 4.16
Start Time: 2024-05-31T00:00:00Z
End Time: 2024-06-27T23:59:59Z
Success Rate: 100.00%
Successes: 647
Failures: 0
Flakes: 15
The test is permafailing on latest payloads on multiple platforms, not just azure. It does seem to coincide with arrival of the 4.18 rhcos images.
{ fail [github.com/openshift/origin/test/extended/cpu_partitioning/crio.go:166]: error getting crio container data from node ci-op-z5sh003f-431b2-r2nm4-master-0
Unexpected error:
<*errors.errorString | 0xc001e80190>:
err execing command jq: error (at <stdin>:1): Cannot index array with string "info"
jq: error (at <stdin>:1): Cannot iterate over null (null)
{
s: "err execing command jq: error (at <stdin>:1): Cannot index array with string \"info\"\njq: error (at <stdin>:1): Cannot iterate over null (null)",
}
occurred
Ginkgo exit error 1: exit with code 1}
The script involved is likely in: https://github.com/openshift/origin/blob/a365380cb3a39cfc26b9f28f04b66418c993a879/test/extended/cpu_partitioning/crio.go#L4
Nightly payloads are fully blocked as multiple blocking aggregated jobs are permafailing this test.
- links to
-
RHEA-2024:6122
OpenShift Container Platform 4.18.z bug fix update
