-
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
MHC should surface unhealthy machines even if maxUnhealthy has been reached #3163
Comments
/milestone Next |
@vincepri: The label(s) 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. |
/priority important-longterm |
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. |
/remove-lifecycle stale |
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. |
/lifecycle frozen |
/close |
@vincepri: 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. |
User Story
As an operator I would like to be able to see what machines are unhealthy in my cluster even when I have configured a
maxUnhealthy
limit on my MHC and it has been triggered, so that I can have help manually determining the problems.Detailed Description
Right now when
maxUnhealthy
is hit we log a message and emit an event on the MachineHealthCheck object. Since we are introducing conditions and there's a lot of overlap with events, we can possibly replace the event or at least supplement it.Anything else you would like to add:
We need to agree what the condition should be. @fabriziopandini proposed using
OwnerRemediated=false, Reason= RemediationRestricted
but that seems a little kludgy to me./kind feature
xref #3108
The text was updated successfully, but these errors were encountered: