-
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
🐛 Set unhealthyLimitKey for logging always #5110
Conversation
cc @JoelSpeed |
Is there any way we can add a test for this that would panic if we ever regress? |
var unhealthyLimitKey, unhealthyLimitValue interface{} | ||
if m.Spec.UnhealthyRange == nil { | ||
unhealthyLimitKey = "max unhealthy" | ||
unhealthyLimitValue = m.Spec.MaxUnhealthy | ||
} else { | ||
unhealthyLimitKey = "unhealthy range" | ||
unhealthyLimitValue = *m.Spec.UnhealthyRange | ||
} |
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.
Do we have to optimize here? Could we just call the logger twice in two ifs
below? We could potentially use a switch case if readability is a concern.
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'm not sure I follow, I updated to call the logger twice. PTAL.
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 definitely makes it easier to follow what's actually happening
I wonder if it's worth moving some of these strings to some consts?
Without this the controller is panicking as the logger expect every key to be a string
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
/retest |
@vincepri PTAL |
message = fmt.Sprintf("Remediation is not allowed, the number of not started or unhealthy machines does not fall within the range (total: %v, unhealthy: %v, unhealthyRange: %v)", | ||
totalTargets, | ||
len(unhealthy), | ||
*m.Spec.UnhealthyRange) | ||
} | ||
|
||
logger.V(3).Info( |
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.
It seems like we could keep a single log call here, as well as below without needing to add an if/else block. The values can just be set in variables as they were, then only have one call out to the logger. The only thing missing from the existing code was to make sure the key was set to something if remediationAllowed
.
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 for feedback @stmcginnis. Is this suggesting just the opposite to #5110 (comment)? @vincepri
Seems @JoelSpeed finds it more readable with the if/else #5110 (review)
I don't really have any strong opinion as far as we stop the controller from panicking.
@stmcginnis @JoelSpeed @vincepri please let me know if you want to merge it as it is or make any specific change. Feedback seems to go in both directions atm.
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 have a really strong opinion on this, but having seen both, I think I prefer the way it is now. While it's more code, it's also more explicit about what's happening and I personally find it easier to follow this way.
Also, thinking about how the logging works, with this approach the log line will include the actual line numbers of the log calls and might make it easier to trace the logging and which if-statements were entered, as opposed with today where you have to work out the values that were substituted and then work out where they were set
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: vincepri 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 |
/retest |
1 similar comment
/retest |
To pick kubernetes-sigs/cluster-api#5110 in capi and use capa 0.7.0 release image. Will drop this when plumbing these images through our pipeline.
To pick kubernetes-sigs/cluster-api#5110 in capi and use capa 0.7.0 release image. Will drop this when plumbing these images through our pipeline.
To pick kubernetes-sigs/cluster-api#5110 in capi and use capa 0.7.0 release image. Will drop this when plumbing these images through our pipeline.
To pick kubernetes-sigs/cluster-api#5110 in capi and use capa 0.7.0 release image. Will drop this when plumbing these images through our pipeline.
What this PR does / why we need it:
Without this the controller is panicking as the logger expect every key to be a string.
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes #