OCPBUGS-45272: KI for CNI plugin, 4.18 GA, from Telco team. #88543
Conversation
openshift-ci-robot
added
jira/severity-critical
|
@rohennes: This pull request references Jira Issue OCPBUGS-45272, which is invalid:
Comment The bug has been updated to refer to the pull request using the external bug tracker. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
openshift-ci
bot
added
the
size/XS
rohennes
changed the title
|
🤖 Fri Feb 14 10:57:58 - Prow CI generated the docs preview: |
|
/label peer-review-needed |
openshift-ci
bot
added
the
peer-review-needed
ShaunaDiaz
added
peer-review-in-progress
| * Due to an issue with Kubernetes, the CPU Manager is unable to return CPU resources from the last pod admitted to a node to the pool of available CPU resources. These resources are allocatable if a subsequent pod is admitted to the node. However, this pod then becomes the last pod, and again, the CPU manager cannot return this pod's resources to the available pool. | ||
| + | ||
| This issue affects CPU load balancing features, which depend on the CPU Manager releasing CPUs to the available pool. Consequently, non-guaranteed pods might run with a reduced number of CPUs. As a workaround, schedule a pod with a `best-effort` CPU Manager policy on the affected node. This pod will be the last admitted pod and this ensures the resources will be correctly released to the available pool. (link:https://issues.redhat.com/browse/OCPBUGS-17792[*OCPBUGS-17792*]) | ||
| This issue affects CPU load balancing features, which depend on the CPU Manager releasing CPUs to the available pool. Consequently, non-guaranteed pods might run with a reduced number of CPUs. As a workaround, schedule a pod with a `best-effort` CPU Manager policy on the affected node. This pod will be the last admitted pod and this ensures the resources will be correctly released to the available pool. (link:https://issues.redhat.com/browse/OCPBUGS-46428[*OCPBUGS-46428*]) |
There was a problem hiding this comment.
| This issue affects CPU load balancing features, which depend on the CPU Manager releasing CPUs to the available pool. Consequently, non-guaranteed pods might run with a reduced number of CPUs. As a workaround, schedule a pod with a `best-effort` CPU Manager policy on the affected node. This pod will be the last admitted pod and this ensures the resources will be correctly released to the available pool. (link:https://issues.redhat.com/browse/OCPBUGS-46428[*OCPBUGS-46428*]) | |
| This issue affects CPU load-balancing features, which depend on the CPU Manager releasing CPUs to the available pool. Consequently, non-guaranteed pods might run with a reduced number of CPUs. As a workaround, schedule a pod with a `best-effort` CPU Manager policy on the affected node. This pod is the last admitted pod and this order ensures that the resources are correctly released to the available pool. (link:https://issues.redhat.com/browse/OCPBUGS-46428[*OCPBUGS-46428*]) |
Nits; hyphenate compound modifier; present-tense only; addition of a "that" for readability
| This issue affects CPU load balancing features, which depend on the CPU Manager releasing CPUs to the available pool. Consequently, non-guaranteed pods might run with a reduced number of CPUs. As a workaround, schedule a pod with a `best-effort` CPU Manager policy on the affected node. This pod will be the last admitted pod and this ensures the resources will be correctly released to the available pool. (link:https://issues.redhat.com/browse/OCPBUGS-17792[*OCPBUGS-17792*]) | ||
| This issue affects CPU load balancing features, which depend on the CPU Manager releasing CPUs to the available pool. Consequently, non-guaranteed pods might run with a reduced number of CPUs. As a workaround, schedule a pod with a `best-effort` CPU Manager policy on the affected node. This pod will be the last admitted pod and this ensures the resources will be correctly released to the available pool. (link:https://issues.redhat.com/browse/OCPBUGS-46428[*OCPBUGS-46428*]) | ||
|
|
||
| * When a pod uses the CNI plugin for DHCP address assignment, in conjunction with other CNI plugins, the pod's network interface might be unexpectedly deleted. As a result, when the pod's DHCP lease expires, the DHCP proxy enters a loop when trying to re-create a new lease, leading to the node becoming unresponsive. There is currently no known workaround. (link:https://issues.redhat.com/browse/OCPBUGS-45272[*OCPBUGS-45272*]) |
There was a problem hiding this comment.
| * When a pod uses the CNI plugin for DHCP address assignment, in conjunction with other CNI plugins, the pod's network interface might be unexpectedly deleted. As a result, when the pod's DHCP lease expires, the DHCP proxy enters a loop when trying to re-create a new lease, leading to the node becoming unresponsive. There is currently no known workaround. (link:https://issues.redhat.com/browse/OCPBUGS-45272[*OCPBUGS-45272*]) | |
| * When a pod uses the CNI plugin for DHCP address assignment in conjunction with other CNI plugins, the pod's network interface might be unexpectedly deleted. As a result, when the pod's DHCP lease expires, the DHCP proxy enters a loop when trying to re-create a new lease, leading to the node becoming unresponsive. There is currently no workaround. (link:https://issues.redhat.com/browse/OCPBUGS-45272[*OCPBUGS-45272*]) |
Since it seems like "in conjunction with" is the critical factor, only one comma is needed (if....then).
Don't think you need "known" as that is inherent and is just an extra word.
ShaunaDiaz
added
peer-review-done
rohennes
force-pushed
the
OCPBUGS-45272
branch
from
05ab8dd to
b5815ab
Compare
|
/label merge-review-needed |
openshift-ci
bot
added
the
merge-review-needed
rohennes
force-pushed
the
OCPBUGS-45272
branch
from
b5815ab to
2fbcd5f
Compare
xenolinux
added
merge-review-in-progress
| This issue affects CPU load balancing features, which depend on the CPU Manager releasing CPUs to the available pool. Consequently, non-guaranteed pods might run with a reduced number of CPUs. As a workaround, schedule a pod with a `best-effort` CPU Manager policy on the affected node. This pod will be the last admitted pod and this ensures the resources will be correctly released to the available pool. (link:https://issues.redhat.com/browse/OCPBUGS-17792[*OCPBUGS-17792*]) | ||
| This issue affects CPU load-balancing features, which depend on the CPU Manager releasing CPUs to the available pool. Consequently, non-guaranteed pods might run with a reduced number of CPUs. As a workaround, schedule a pod with a `best-effort` CPU Manager policy on the affected node. This pod will be the last admitted pod and this ensures the resources will be correctly released to the available pool. (link:https://issues.redhat.com/browse/OCPBUGS-46428[*OCPBUGS-46428*]) | ||
|
|
||
| * When a pod uses the CNI plugin for DHCP address assignment in conjunction with other CNI plugins, the pod's network interface might be unexpectedly deleted. As a result, when the pod's DHCP lease expires, the DHCP proxy enters a loop when trying to re-create a new lease, leading to the node becoming unresponsive. There is currently no workaround. (link:https://issues.redhat.com/browse/OCPBUGS-45272[*OCPBUGS-45272*]) |
There was a problem hiding this comment.
| * When a pod uses the CNI plugin for DHCP address assignment in conjunction with other CNI plugins, the pod's network interface might be unexpectedly deleted. As a result, when the pod's DHCP lease expires, the DHCP proxy enters a loop when trying to re-create a new lease, leading to the node becoming unresponsive. There is currently no workaround. (link:https://issues.redhat.com/browse/OCPBUGS-45272[*OCPBUGS-45272*]) | |
| * When a pod uses the CNI plugin for DHCP address assignment in conjunction with other CNI plugins, the network interface of a pod might be unexpectedly deleted. As a result, when the DHCP lease of a pod expires, the DHCP proxy enters a loop when trying to re-create a new lease, leading to the node becoming unresponsive. There is currently no workaround. (link:https://issues.redhat.com/browse/OCPBUGS-45272[*OCPBUGS-45272*]) |
https://www.ibm.com/docs/en/ibm-style?topic=grammar-possessives
Do not use possessive ’s with inanimate objects.
xenolinux
removed
the
merge-review-in-progress
rohennes
force-pushed
the
OCPBUGS-45272
branch
from
2fbcd5f to
a427078
Compare
rohennes
force-pushed
the
OCPBUGS-45272
branch
from
a427078 to
236ea07
Compare
|
/label merge-review-needed |
openshift-ci
bot
added
the
merge-review-needed
|
@rohennes: all tests passed! Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
jeana-redhat
added
the
merge-review-in-progress
openshift-ci
bot
removed
merge-review-in-progress
|
@rohennes: Jira Issue OCPBUGS-45272: All pull requests linked via external trackers have merged: Jira Issue OCPBUGS-45272 has been moved to the MODIFIED state. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
Fix included in accepted release 4.19.0-0.nightly-2025-04-02-065200 |
|
Fix included in accepted release 4.19.0-0.nightly-2025-04-02-170034 |
|
Fix included in accepted release 4.19.0-0.nightly-2025-04-04-023411 |
|
Fix included in accepted release 4.19.0-0.nightly-2025-04-04-170728 |
7 participants
OCPBUGS-45272: KI for CNI plugin, 4.18 GA, from Telco team.
Version(s):
4.18
Issue:
https://issues.redhat.com/browse/TELCODOCS-2070
Link to docs preview:
https://88543--ocpdocs-pr.netlify.app/openshift-enterprise/latest/release_notes/ocp-4-18-release-notes.html#ocp-4-18-known-issues_release-notes
Additional info:
Also just corrected the link in a previous KI I added. It now points to the 4.18 version of the bug.