Skip to content

pkg/scaffold: fixing main printVersion #752

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
merged 1 commit into from
Nov 16, 2018

Conversation

joelanford
Copy link
Member

Description of the change:
Modifying the cmd/manager/main.go template so that the call to printVersion() occurs after the logger has been set.

Motivation for the change:
printVersion() does not currently print the version information.

If we're concerned that moving printVersion() beyond the very first call in main() will cause problems, we can also just use fmt.Printf() in printVersion() instead of using the logger.

@joelanford joelanford requested a review from estroz November 15, 2018 22:44
@openshift-ci-robot openshift-ci-robot added the size/S Denotes a PR that changes 10-29 lines, ignoring generated files. label Nov 15, 2018
@hasbro17
Copy link
Contributor

we can also just use fmt.Printf() in printVersion() instead of using the logger.

Another issue is if someone gets rid of logf.SetLogger(logf.ZapLogger(false)) if they want to replace logr with their own logger, then they'd need to change the statements in printVerison() too or else the output would be silent (as it is right now).
That's not too hard to do but I guess fmt.Printf() would always print that info.

@joelanford
Copy link
Member Author

Another issue is if someone gets rid of logf.SetLogger(logf.ZapLogger(false)) if they want to replace logr with their own logger

We could solve that by putting the log initialization back in main() and passing a logr.Logger to printVersion(). Then if a user got rid of the logr initialization, they would be forced to address that parameter.

I personally lean towards using the logr.Logger interface just to keep everything consistent.

The one argument I have for using something else is that it's possible for the logr initialization to fail, in which case we wouldn't be able to log the printVersion() stuff. Those logs are helpful for operator developers to troubleshoot issues, but none of those logs actually identify the operator binary itself (that would be something nice to add though), so I don't think its a problem in this case.

@estroz
Copy link
Member

estroz commented Nov 16, 2018

@hasbro17 as long as they have their log package aliased as log, printVersion() will work as intended with these changes. If they do not, the compiler will complain.

Copy link
Member

@estroz estroz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Contributor

@hasbro17 hasbro17 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah agreed. I don't think it's unreasonable to assume that users will change the log alias if they decide to remove logr and its initialization entirely.

LGTM

@joelanford joelanford merged commit 1a56adc into operator-framework:master Nov 16, 2018
@joelanford joelanford deleted the print-version branch November 16, 2018 19:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
size/S Denotes a PR that changes 10-29 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants