-
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
🌱 Propagate timeout fields from MachineSet to Machine during Machine deletion #10589
🌱 Propagate timeout fields from MachineSet to Machine during Machine deletion #10589
Conversation
Thanks @davidvossel change makes sense to me. Smoother deletion is actually one of the supporting use cases for inplace propagation. Let's include some unit tests. |
9dfb847
to
7e05934
Compare
@enxebre i extended the existing unit test to cover the case of updating a deleting machine. |
7e05934
to
b69cea4
Compare
/lgtm |
LGTM label has been added. Git tree hash: 44936fae936d0eab3c39b86c432c24c5e199979d
|
…ine deletion Signed-off-by: David Vossel <[email protected]>
b69cea4
to
da2b7c8
Compare
/lgtm |
LGTM label has been added. Git tree hash: a7820897401d291e168e73cfc2ea745d5f2c8d87
|
All good from my side. I would open a follow-up issue once this PR is merged to track further work to get this behavior across all MD workflows (e.g. MD rollout, deletion). /approve /hold Otherwise let's merge in a few days |
[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 |
/lgtm |
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.
Could we update the PR title to more reflect what is happening?
E.g.
🌱 Allow inplace update of fields related to deletion during MachineSet scale to 0
(as of that lgtm)
I renamed slightly differently. The scenarios are not distinct and this is also part of fixing the other cases |
Thx folks! /hold cancel I'll open the follow-up issue tomorrow |
Here's the follow-up issue: #10753 |
Fixes #10588
/area machine
What this PR does / why we need it:
Machine's default to nodeDrainTimeout: 0s, which blocks indefinitely if a pod can't be evicted. We can't change the nodeDrainTimeout in-place from the MachineDeployment or MachineSet after a machine is marked for deletion.
This results in a machine that wedged forever but can't be updated using the top level objects that own the machine.
To fix this, this PR allows fields related to machine deletion to be updated in place even when the machine is marked for deletion.
NOTE - I did not add unit tests yet for this PR. I want confirmation this is an acceptable approve before investing time into testing.