-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
✨ Add nodeVolumeDetachTimeout property to Machine #6413
✨ Add nodeVolumeDetachTimeout property to Machine #6413
Conversation
Hi @furkatgofurov7. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
/hold |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
6a80f0b
to
bf36f49
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Q: for node draining, we have the machine.cluster.x-k8s.io/exclude-node-draining annotation that allows us to skip the process entirely. Should we have something similar for volumeDetach?
/hold cancel |
/ok-to-test |
@fabriziopandini great idea, I was not aware of that annotation, since it could simplify the logic a lot and not affect the current behavior. I will make changes accordingly hopefully soon (sorry for the late reply btw, I am on vacation now) |
bf36f49
to
1a64aeb
Compare
1a0f416
to
fd85fbe
Compare
@fabriziopandini I have updated the PR accordingly to add exclude volumeDetach annotation, PTAL. I am also investigating verify main test failure |
I can not reproduce this test failure locally ( /test pull-cluster-api-verify-main |
fd85fbe
to
02d905c
Compare
566ba4e
to
60b3ef4
Compare
I can take care of doing the work in Cluster.Topology. |
/lgtm |
/cc @sbueringer @enxebre hi folks, if you could take another look and help to merge this, thanks! |
/lgtm Giving Alberto some time to take a look as well |
a543dd6
to
3514f1b
Compare
Sure, anyways I had to rebase it after bac8e27 and it got removed again 😀 |
/lgtm |
Oh, I just noticed that commits are not squashed 😅 |
3514f1b
to
a27f71c
Compare
@fabriziopandini done 😃 |
/lgtm |
/approve @furkatgofurov7 Thx for all your work and patience on this! |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: sbueringer 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 |
// After node draining is completed, and if isNodeVolumeDetachingAllowed returns True, make sure all | ||
// volumes are detached before proceeding to delete the Node. | ||
if r.isNodeVolumeDetachingAllowed(m) { | ||
log.Info("Waiting for node volumes to be detached", "Node", klog.KRef("", m.Status.NodeRef.Name)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This log message duplicates the one shown in line 374. Would be good to remove one of them. If we keep this one, we should add a second log entry when volumes are detached. Otherwise it makes debugging harder - caused a lot of confusion for us just now.
I can move this to an issue if necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be good if you can either move it to an issue or open a PR if you want to
What this PR does / why we need it:
nodeVolumeDetachTimeout
to the machine and other CRDs, which can be used to wait for volume detachment to happen within the timeout limitExcludeWaitForNodeVolumeDetachAnnotation
to be able to skipshouldWaitForNodeVolumes
check entirely if neededshouldWaitForNodeVolumes
from node drain logic (isNodeDrainAllowed
) and adds new check only for volume related checks calledisNodeVolumeDetachingAllowed
to to keep a cleaner separation for APInodeVolumeDetachTimeout
and annotationExcludeWaitForNodeVolumeDetachAnnotation
as a breaking changes in the provider's migration v1.2 to v1.3 documentRenamesVolumeDetachSucceededCondition
toVolumeDetachFinishedCondition
so it is clearer for the user, because we have to markVolumeDetachSucceededCondition
as True whenvolumeDetachTimeoutExceeded
condition met even though in fact volumes are not detached. For that reason, I renamed it toVolumeDetachFinishedCondition
(open to suggestions on this) to make it a bit generic and less confusing for the user.AddsVolumeDetachTimedOutCondition
to indicate volume detaching timeout exceededAddsWaitingForVolumeDetachTimeoutReason
to indicate the reason for detach timeoutWhich issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes #6285