UPSTREAM: 52864: dockershim: fine-tune network-ready handling on sandbox teardown and removal #16602
Conversation
…box teardown and removal If sandbox teardown results in an error, GC will periodically attempt to again remove the sandbox. Until the sandbox is removed, pod sandbox status calls will attempt to enter the pod's namespace and retrieve the pod IP, but the first teardown attempt may have already removed the network namespace, resulting in a pointless log error message that the network namespace doesn't exist, or that nsenter can't find eth0. The network-ready mechanism originally attempted to suppress those messages by ensuring that pod sandbox status skipped network checks when networking was already torn down, but unfortunately the ready value was cleared too early. Also, don't tear down the pod network multiple times if the first time we tore it down, it succeeded. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1434950
openshift-ci-robot
added
the
size/S
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: eparis The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these OWNERS Files:
You can indicate your approval by writing |
openshift-merge-robot
added
the
approved
|
/unassign |
|
/test all [submit-queue is verifying that this PR is safe to merge] |
|
Automatic merge from submit-queue (batch tested with PRs 16525, 16602, 16603). |
|
@dcbw: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. 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/test-infra repository. I understand the commands that are listed here. |
If sandbox teardown results in an error, GC will periodically attempt
to again remove the sandbox. Until the sandbox is removed, pod
sandbox status calls will attempt to enter the pod's namespace and
retrieve the pod IP, but the first teardown attempt may have already
removed the network namespace, resulting in a pointless log error
message that the network namespace doesn't exist, or that nsenter
can't find eth0.
The network-ready mechanism originally attempted to suppress those
messages by ensuring that pod sandbox status skipped network checks
when networking was already torn down, but unfortunately the ready
value was cleared too early.
Also, don't tear down the pod network multiple times if the first
time we tore it down, it succeeded.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1434950
@openshift/networking @eparis @knobunc