-
Notifications
You must be signed in to change notification settings - Fork 331
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
Drainer supports customized kubelet probe check #1977
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1977 +/- ##
=======================================
Coverage 69.06% 69.07%
=======================================
Files 210 210
Lines 8796 8798 +2
=======================================
+ Hits 6075 6077 +2
Misses 2451 2451
Partials 270 270
Continue to review full report at Codecov.
|
/cc @Harwayne |
/assign @vagababov |
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've just got nits
/assign mattmoor
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.
A few nits, but I'll leave to Matt to approve.
/lgtm
may be you still need the return after you report failure. |
Nah, that doesn't seem right.... |
/retest |
network/handlers/drain.go
Outdated
// CheckOption is the optional checker | ||
// for kubelet probe to perform when the handler is not in Drain status. | ||
CheckOption CheckOption |
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.
// CheckOption is the optional checker | |
// for kubelet probe to perform when the handler is not in Drain status. | |
CheckOption CheckOption | |
// HealthCheck is an optional health check that is performed until the drain signal is received. | |
// When unspecified, a "200 OK" is returned, otherwise this function is invoked. | |
HealthCheck http.HandlerFunc |
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.
done
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.
Personally, I am in favor of custom name too. Do you mind if I change back to CheckOption
and keep the comment you suggested?
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 don't understand the value we're getting from the type alias? inlined, I know it's a well known handler interface I need to implement. outlined I need to look it up before doing the same.
We're not defining our own methods on the type alias, or "constants" we expect to be passed as values.
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.
Thanks, that sounds reasonable to me. I'll keep the current change you suggested, and remove the hold.
I kind of liked custom name, but 🤷 |
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.
/lgtm
/approve
/hold
Holding for discussion around the type alias
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: grac3gao, mattmoor 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 |
I am not going to fight for it. For me the alias was preferable, since tomorrow if we decide to change the signature (e.g. to add context) it's just signature and call-sites, now it's more work. |
/unhold |
Changes