-
Notifications
You must be signed in to change notification settings - Fork 38.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
unmount timeout should NOT trigger detach (by trigger detach there is a potential data loose) #69168
Comments
/sig storage |
Hi. I think I see the problem with this. Can I volunteer to work on a fix? New to the k8s codebase |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Rotten issues close after 30d of inactivity. Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
@fejta-bot: Closing this issue. 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 kubernetes/test-infra repository. |
/remove-lifecycle rotten |
/reopen |
@kmova: You can't reopen an issue/PR unless you authored it or you are a collaborator. 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 kubernetes/test-infra repository. |
What happened:
Stop a POD with PV, will trigger unmount flow in k8s. And the current flow is to trigger detach of the PV if the unmount operation reached to timeout (called maxWaitForUnmountDuration, which BTW is not configurable #68086).
I think that this is a bug - k8s should not send detach to PV if the unmount operation is stuck and reached to timeout maxWaitForUnmountDuration. Because there is a small chance of data loose here, because there is a chance that the unmount operation didn't unmount the device on the node, and some data still preserve in the filesystem cache.
What you expected to happen:
K8s should not send detach to the PV if the unmount of PV reached to timeout maxWaitForUnmountDuration. Instead it should just fail the unmount and just retry again the unmount.
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
We had a discussion about how k8s discover a crashed node and release the PODs on it (HERE ->
#65392 (comment))
Is some way this current issue is related(complimentary) to this one.
Environment:
every k8s version.
The text was updated successfully, but these errors were encountered: