dockershim/sandbox: clean up pod network even if SetUpPod() failed #62874
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
k8s-ci-robot
added
release-note-none
|
/test pull-kubernetes-e2e-gce |
|
/test pull-kubernetes-local-e2e-containerized |
resouer
reviewed
Apr 19, 2018
| // TODO(random-liu): Do we need to teardown network here? | ||
| // Ensure network resources are cleaned up even if the plugin | ||
| // succeeded but an error happened between that success and here. | ||
| ds.network.TearDownPod(config.GetMetadata().Namespace, config.GetMetadata().Name, cID) |
There was a problem hiding this comment.
I am not sure if it's OK to skip error of TearDownPod here, maybe a warning at least?
dcbw
force-pushed
the
dockershim-SetUpPod-cleanup-on-failure
branch
from
6dddcd9 to
135a2f4
Compare
|
/retest |
|
/test pull-kubernetes-kubemark-e2e-gce |
1 similar comment
|
/test pull-kubernetes-kubemark-e2e-gce |
|
@resouer @danwinship PTAL, and if it's OK an lgtm would be awesome, thanks! |
danwinship
reviewed
Apr 23, 2018
| // Ensure network resources are cleaned up even if the plugin | ||
| // succeeded but an error happened between that success and here. | ||
| if err := ds.network.TearDownPod(config.GetMetadata().Namespace, config.GetMetadata().Name, cID); err != nil { | ||
| glog.Warningf("Failed to clean up sandbox container %q network for pod %q: %v", createResp.ID, config.Metadata.Name, err) |
There was a problem hiding this comment.
Hm... is this going to cause spurious warnings? (Since TearDownPod may not deal well with being called on an only-partially-SetUp pod)
Also, this warning will end up getting printed before the SetUpPod() result, which will make it look in the logs like the TearDownPod failure is the cause of the SetUpPod() failure, rather than a result of it. (Though I guess that's true of the StopContainer() code below too...)
There was a problem hiding this comment.
How about making the warning message more narrative? Like:
My original concern is: if we failed to ensure ns clean up, we should let users know, as there maybe garbage left behind.
There was a problem hiding this comment.
@danwinship better now? Uses NewAggregate() to combine errors in the correct order.
dcbw
force-pushed
the
dockershim-SetUpPod-cleanup-on-failure
branch
from
135a2f4 to
fa8c283
Compare
k8s-ci-robot
added
size/S
If the CNI network plugin completes successfully, but something fails between that success and dockerhsim's sandbox setup code, plugin resources may not be cleaned up. A non-trivial amount of code runs after the plugin itself exits and the CNI driver's SetUpPod() returns, and any error condition recognized by that code would cause this leakage. The Kubernetes CRI RunPodSandbox() request does not attempt to clean up on errors, since it cannot know how much (if any) networking was actually set up. It depends on the CRI implementation to do that cleanup for it. In the dockershim case, a SetUpPod() failure means networkReady is FALSE for the sandbox, and TearDownPod() will not be called later by garbage collection even though networking was configured, because dockershim can't know how far SetUpPod() got. Concrete examples include if the sandbox's container is somehow removed during during that time, or another OS error is encountered, or the plugin returns a malformed result to the CNI driver. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1532965
dcbw
force-pushed
the
dockershim-SetUpPod-cleanup-on-failure
branch
from
fa8c283 to
91321ef
Compare
|
/test pull-kubernetes-e2e-kops-aws |
|
/lgtm |
k8s-ci-robot
added
the
lgtm
|
/test pull-kubernetes-e2e-kops-aws |
|
/lgtm |
k8s-ci-robot
added
the
approved
|
/test pull-kubernetes-e2e-kops-aws |
|
@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. |
|
/lgtm Thanks for quick fix! |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: danwinship, dcbw, resouer, yujuhong The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/retest Review the full test history for this PR. Silence the bot with an |
|
Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions here. |
dcbw
added a commit
to dcbw/origin
that referenced
this pull request
May 1, 2018
…UpPod() failed If the CNI network plugin completes successfully, but something fails between that success and dockerhsim's sandbox setup code, plugin resources may not be cleaned up. A non-trivial amount of code runs after the plugin itself exits and the CNI driver's SetUpPod() returns, and any error condition recognized by that code would cause this leakage. The Kubernetes CRI RunPodSandbox() request does not attempt to clean up on errors, since it cannot know how much (if any) networking was actually set up. It depends on the CRI implementation to do that cleanup for it. In the dockershim case, a SetUpPod() failure means networkReady is FALSE for the sandbox, and TearDownPod() will not be called later by garbage collection even though networking was configured, because dockershim can't know how far SetUpPod() got. Concrete examples include if the sandbox's container is somehow removed during during that time, or another OS error is encountered, or the plugin returns a malformed result to the CNI driver. Upstream: kubernetes/kubernetes#62874 Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1532965
dcbw
added a commit
to dcbw/origin
that referenced
this pull request
May 1, 2018
…UpPod() failed If the CNI network plugin completes successfully, but something fails between that success and dockerhsim's sandbox setup code, plugin resources may not be cleaned up. A non-trivial amount of code runs after the plugin itself exits and the CNI driver's SetUpPod() returns, and any error condition recognized by that code would cause this leakage. The Kubernetes CRI RunPodSandbox() request does not attempt to clean up on errors, since it cannot know how much (if any) networking was actually set up. It depends on the CRI implementation to do that cleanup for it. In the dockershim case, a SetUpPod() failure means networkReady is FALSE for the sandbox, and TearDownPod() will not be called later by garbage collection even though networking was configured, because dockershim can't know how far SetUpPod() got. Concrete examples include if the sandbox's container is somehow removed during during that time, or another OS error is encountered, or the plugin returns a malformed result to the CNI driver. Upstream: kubernetes/kubernetes#62874 Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1532965 (cherry picked from commit 08bdb94)
openshift-publish-robot
pushed a commit
to openshift/kubernetes
that referenced
this pull request
May 7, 2018
…UpPod() failed If the CNI network plugin completes successfully, but something fails between that success and dockerhsim's sandbox setup code, plugin resources may not be cleaned up. A non-trivial amount of code runs after the plugin itself exits and the CNI driver's SetUpPod() returns, and any error condition recognized by that code would cause this leakage. The Kubernetes CRI RunPodSandbox() request does not attempt to clean up on errors, since it cannot know how much (if any) networking was actually set up. It depends on the CRI implementation to do that cleanup for it. In the dockershim case, a SetUpPod() failure means networkReady is FALSE for the sandbox, and TearDownPod() will not be called later by garbage collection even though networking was configured, because dockershim can't know how far SetUpPod() got. Concrete examples include if the sandbox's container is somehow removed during during that time, or another OS error is encountered, or the plugin returns a malformed result to the CNI driver. Upstream: kubernetes#62874 Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1532965 Origin-commit: 08bdb948741668e8d99923c89efc8f14990355b3
dcbw
added a commit
to dcbw/origin
that referenced
this pull request
May 9, 2018
…UpPod() failed If the CNI network plugin completes successfully, but something fails between that success and dockerhsim's sandbox setup code, plugin resources may not be cleaned up. A non-trivial amount of code runs after the plugin itself exits and the CNI driver's SetUpPod() returns, and any error condition recognized by that code would cause this leakage. The Kubernetes CRI RunPodSandbox() request does not attempt to clean up on errors, since it cannot know how much (if any) networking was actually set up. It depends on the CRI implementation to do that cleanup for it. In the dockershim case, a SetUpPod() failure means networkReady is FALSE for the sandbox, and TearDownPod() will not be called later by garbage collection even though networking was configured, because dockershim can't know how far SetUpPod() got. Concrete examples include if the sandbox's container is somehow removed during during that time, or another OS error is encountered, or the plugin returns a malformed result to the CNI driver. Upstream: kubernetes/kubernetes#62874 Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1532965
openshift-publish-robot
pushed a commit
to openshift/kubernetes
that referenced
this pull request
May 9, 2018
…UpPod() failed If the CNI network plugin completes successfully, but something fails between that success and dockerhsim's sandbox setup code, plugin resources may not be cleaned up. A non-trivial amount of code runs after the plugin itself exits and the CNI driver's SetUpPod() returns, and any error condition recognized by that code would cause this leakage. The Kubernetes CRI RunPodSandbox() request does not attempt to clean up on errors, since it cannot know how much (if any) networking was actually set up. It depends on the CRI implementation to do that cleanup for it. In the dockershim case, a SetUpPod() failure means networkReady is FALSE for the sandbox, and TearDownPod() will not be called later by garbage collection even though networking was configured, because dockershim can't know how far SetUpPod() got. Concrete examples include if the sandbox's container is somehow removed during during that time, or another OS error is encountered, or the plugin returns a malformed result to the CNI driver. Upstream: kubernetes#62874 Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1532965 Origin-commit: 2ad8991a3fed1c3ba84b8baf853f8bb8e2a2e6f5
liggitt
pushed a commit
to liggitt/kubernetes
that referenced
this pull request
May 11, 2018
…UpPod() failed If the CNI network plugin completes successfully, but something fails between that success and dockerhsim's sandbox setup code, plugin resources may not be cleaned up. A non-trivial amount of code runs after the plugin itself exits and the CNI driver's SetUpPod() returns, and any error condition recognized by that code would cause this leakage. The Kubernetes CRI RunPodSandbox() request does not attempt to clean up on errors, since it cannot know how much (if any) networking was actually set up. It depends on the CRI implementation to do that cleanup for it. In the dockershim case, a SetUpPod() failure means networkReady is FALSE for the sandbox, and TearDownPod() will not be called later by garbage collection even though networking was configured, because dockershim can't know how far SetUpPod() got. Concrete examples include if the sandbox's container is somehow removed during during that time, or another OS error is encountered, or the plugin returns a malformed result to the CNI driver. Upstream: kubernetes#62874 Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1532965
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If the CNI network plugin completes successfully, but something fails
between that success and dockerhsim's sandbox setup code, plugin resources
may not be cleaned up. A non-trivial amount of code runs after the
plugin itself exits and the CNI driver's SetUpPod() returns, and any error
condition recognized by that code would cause this leakage.
The Kubernetes CRI RunPodSandbox() request does not attempt to clean
up on errors, since it cannot know how much (if any) networking
was actually set up. It depends on the CRI implementation to do
that cleanup for it.
In the dockershim case, a SetUpPod() failure means networkReady is
FALSE for the sandbox, and TearDownPod() will not be called later by
garbage collection even though networking was configured, because
dockershim can't know how far SetUpPod() got.
Concrete examples include if the sandbox's container is somehow
removed during during that time, or another OS error is encountered,
or the plugin returns a malformed result to the CNI driver.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1532965