-
Notifications
You must be signed in to change notification settings - Fork 84
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 support for uncordoning nodes #84
Conversation
Codecov Report
@@ Coverage Diff @@
## master #84 +/- ##
==========================================
+ Coverage 74.18% 76.67% +2.49%
==========================================
Files 7 7
Lines 488 553 +65
==========================================
+ Hits 362 424 +62
+ Misses 116 115 -1
- Partials 10 14 +4
Continue to review full report at Codecov.
|
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 looks really lovely @cezarsa. I've merged a large MR ahead of yours. Would you be able to rebase and resolve the conflicts here?
expected: &core.Node{ObjectMeta: meta.ObjectMeta{Name: nodeName}}, | ||
}, | ||
{ | ||
name: "UncordonUnschedulableNodeWithMutator", |
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.
I was looking for a test case where a node remains unschedulable even if draino has no reason to uncordon it.
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.
...And I found it here: https://github.com/planetlabs/draino/pull/84/files#diff-45cd5412f9ec9294054951666bce4620R159
Thanks for taking a look at this. Rebased and conflicts solved. |
Following discussions in #27 (comment) it can be useful to draino to detect that a condition that triggered a node being cordoned is no longer present.
This PR introduces the ability for draino to track which conditions triggered the cordon+drain process in an annotation named
draino.planet.com/conditions
.Whenever this annotation is present draino will check if the conditions are still present in the node, if they are not present anymore draino will try to uncordon the node and possibly skip draining the node if it wasn't scheduled yet.
I'm marking this as a draft because I'm still going to write a few unit tests, but the functionality is mostly ready and I've been able to test it on a real cluster.One question, would the maintainers like for me to put this feature behind a flag (eg:
--allow-uncordon
)? I don't think it's dangerous to allow uncordoning but it can be unexpected for users upgrading draino.Fixes #27