-
Notifications
You must be signed in to change notification settings - Fork 99
pkg/operator/controller cleanup #178
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
Merged
openshift-merge-robot
merged 2 commits into
openshift:master
from
sgreene570:controller-update-boolean-improvements
Jun 13, 2020
Merged
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
What do you think about changing this to
return haveCR, current, nil, and similar for the otherensureFoomethods? I think it would be semantically more correct (intension instead of extension) and resilient to refactoring. The following example from a recent change you made comes to mind: https://github.com/openshift/cluster-ingress-operator/blob/9edc269df6f9c346509e0e8dc6b647262fdf5a4f/pkg/operator/controller/ingress/load_balancer_service.go#L85-L87Using the variable (the intension) instead of a literal value (the extension of the variable) should work in all cases, and then
ensureLoadBalancerServicedoesn't need to be an exceptional case (or to put it another way, sticking to the pattern wouldn't introduce a defect in cases likeensureLoadBalancerServiceif the pattern werereturn haveFoo, current, nil). Disclaimer: I may be overthinking this.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.
While your proposed change is definitely more semantically correct, I think the current approach is fine.
ensureLoadBalancerServicewill always have some minor defect from theensureFoopattern because it is fundamentally different than the otherensureFoofunctions (ensureLoadBalancerServiceis the onlyensureFoofunction whoseFoomay not be needed at all).Also, whenever
ensureFooreturnsfalsefor it's first return value, the second return value is alwaysnil, notcurrent, even thoughcurrentwill evaluate tonil.To me, returning
true, current, nilis slightly easier to read and understand.trueimplies thatcurrentis notnil.haveFooon the other hand does not. Do you think it would be reasonable to continue using the extension case here, or do you feel very strongly about switching to the intension case?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.
The following
ensureFoomethods, all in cluster-ingress-operator, may determine that noFoois needed:ensureLoadBalancerServiceensureWildcardDNSRecordensureNodePortServiceensureRsyslogConfigMapensureRouterPodDisruptionBudgetSo this is a frequent case.
True, if the Boolean return value is false, then the pointer return value must be nil (so if you return
false, that implies that returning an explicitnilvalue is semantically correct, and perhaps it is more readable to do so), and if the Boolean is true, then the pointer must be non-nil (so if you returntrue, that implies that you must returncurrent). However, that does not imply that returningcurrentimplies that it is non-nil (that is, returningcurrentdoes not imply that you must returntrue); if the Boolean value is unknown, then the pointer value is unknown, but they are still entangled (they're either true and non-nil or false and nil, respectively). I would object to logic that assigned inconsistent values tohaveFooandcurrent, even within the internal logic of the method.I disagree that
trueimplies non-nil, but readability is subjective, and if my argument has not persuaded you, then I'll defer to your judgment.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 definitely see where you are coming from, and I think there are valid points on both sides of the coin. I am going to suggest we continue following the current pattern of returning
true, current nilfor the sake readability.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.
Fair enough. Thanks!
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 minor correction to my earlier comment:
I wrote that in error. I definitely agree that
trueimplies non-nil.Uh oh!
There was an error while loading. Please reload this page.
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.
Looks like
ensureLoadBalancerServiceandensureWildcardDNSRecorddo not make use of thewantFoovariable used in the otherensureFoomethods in that list. At first glance, adding awantFoovariable toensureLoadBalancerServicewould remove the need to return an unknownhaveLB. If we draft another PR to add thewantFoovariable to the methods that are missing it, we could unify on returningtrue, current, nilacross both operators. Thoughts?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.
Oh, snap! This change was wrong—sorry I missed the problem during review: openshift/cluster-ingress-operator@408e341#diff-812ac76222452adcda3e374d185812bbL44-R50
ensureWildcardDNSRecordneeds to check whetherdesiredWildcardRecordactually returns a record. Ideally,desiredWildcardRecordshould have a Boolean return value added, and we should use that where we previously haddesired != nil. (Sidenote:desiredWildcardRecord's godoc needs to be corrected; it hasensureWildcardDNSRecordwhere it should havedesiredWildcardRecord.)We should also add a Boolean return value to
desiredLoadBalancerServiceand use it inensureLoadBalancerService, yeah.In general, I favor having every
desiredFooreturn a Boolean "wants" value, analogously to howensureFooreturns a Boolean "has" value, but if you want to add it only todesiredLoadBalancerServiceanddesiredWildcardRecord, which definitely should have it, that would be fine.Thanks for catching that!
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.
My mistake for accidentally removing those important conditions! I can correct cluster-ingress-operator#408 by adding the mentioned Boolean return values next week. 👍 Thanks!
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.
Refactoring some of these things has been more cumbersome than I anticipated. Thanks for the assistance @Miciah ! 😁