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

Merge pull request #105526 from lcavalle/TELCODOCS-2525

TELCODOCS#2525:Adding Telco CORE known issues
This commit is contained in:
Shane Lovern
2026-01-28 13:49:20 +00:00
committed by GitHub

View File

@@ -4,7 +4,7 @@
This section includes several known issues for {product-title} {product-version}.
* If you mirrored the {product-title} release images to the registry of a disconnected environment by using the `oc adm release mirror` command, the release image Sigstore signature is not mirrored with the image.
* If you mirrored the {product-title} release images to the registry of a disconnected environment by using the `oc adm release mirror` command, the release image Sigstore signature is not mirrored with the image.
+
This has become an issue in {product-title} {product-version}, because the `openshift` cluster image policy is now deployed to the cluster by default. This policy causes CRI-O to automatically verify the Sigstore signature when pulling images into a cluster. (link:https://issues.redhat.com/browse/OCPBUGS-70297[OCPBUGS-70297])
+
@@ -17,7 +17,7 @@ If you cannot use the oc-mirror plugin v2, you can use the `oc image mirror` com
----
$ oc image mirror "quay.io/openshift-release-dev/ocp-release:${RELEASE_DIGEST}.sig" "${LOCAL_REGISTRY}/${LOCAL_RELEASE_IMAGES_REPOSITORY}:${RELEASE_DIGEST}.sig"
----
where:
where:
`RELEASE_DIGEST`:: Specifies your digest image with the `:` character replaced by a `-` character. For example: `sha256:884e1ff5effeaa04467fab9725900e7f0ed1daa89a7734644f14783014cebdee` becomes `sha256-884e1ff5effeaa04467fab9725900e7f0ed1daa89a7734644f14783014cebdee.sig`.
--
@@ -25,3 +25,9 @@ where:
For information on the oc-mirror v2 plugin, see _Mirroring images for a disconnected installation by using the oc-mirror plugin v2_.
* Starting with {product-title} 4.21, there is a decrease in the default maximum open files soft limit for containers. As a consequence, end users might experience application failures. To work around this problem, increase the container runtimes (CRI-O) ulimit configuration using a method of your choice, such as the `ulimit` command. (link:https://issues.redhat.com/browse/OCPBUGS-62095[OCPBUGS-62095])
* Currently, on clusters with SR-IOV network virtual functions configured, a race condition might occur between system services responsible for network device renaming and the TuneD service managed by the Node Tuning Operator. As a consequence, the TuneD profile might become degraded after the node restarts, leading to performance degradation. As a workaround, restart the TuneD pod to restore the profile state. (link:https://issues.redhat.com/browse/OCPBUGS-41934[OCPBUGS-41934])
* Currently, pods that use a `guaranteed` QoS class and request whole CPUs might not restart automatically after a node reboot or kubelet restart. The issue might occur in nodes configured with a static CPU Manager policy and using the `full-pcpus-only` specification, and when most or all CPUs on the node are already allocated by such workloads. As a workaround, manually delete and re-create the affected pods. (link:https://issues.redhat.com/browse/OCPBUGS-43280[OCPBUGS-43280])
* On systems using specific AMD EPYC processors, some low-level system interrupts, for example `AMD-Vi`, might contain CPUs in the CPU mask that overlaps with CPU-pinned workloads. This behavior is because of the hardware design. These specific error-reporting interrupts are generally inactive and there is currently no known performance impact.(link:https://issues.redhat.com/browse/OCPBUGS-57787[OCPBUGS-57787])