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.
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
Modify output method of loggingT to handle Logger/InfoLogger correctly #118
Modify output method of loggingT to handle Logger/InfoLogger correctly #118
Changes from all commits
d2e1629
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 should technically never be possible to get into a state where
log
== nil, l.logr != nil ands == errorLog
right? Because there is noError
method on an InfoLogger. I ask because otherwise there is a risk we drop errors here 😄This logic looks right to me :) just trying to validate my own assumptions!
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 @munnerz .
Yes, that is underlying idea of this line. Ideally, it should not happen.
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.
Makes sense. If
l.logr == nil
,log != nil
ands
is notinfoLog
, it seems like log messages will be silently dropped. I'm not sure if this is a feasible situation to be in, but with the previous code we'd always log unconditionally iflog != nil
. Is there a reason for thes == infoLog
check on this line?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.
Yes, as you said, if
l.logr == nil
,log != nil
ands
is notinfoLog
, log messages will be dropped.I read
logr
package'sREADME
and thought it's good approach thatklog
only handlesinfoLog
orerrorLog
whenlogr.InfoLogger
orlogr.Logger
is used. Because user oflogr.InfoLogger
&logr.Logger
only expects Info or Error, I think.So, future development of
klog
should care about thislogr
's idea.As I wrote in
klog_test.go
, currently this commit doesn't hurtklog
package's code. And there is no public method/function with which user can specifyseverity
value ofoutput
method.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.
Because user of logr.InfoLogger & logr.Logger only expects Info or Error, I think.
There are log levels in between (e.g. warning) that do not have direct equivalents in a logr world (as logr only has levels). The thinking is to treat any un-levelled log message that specifies a non-info level severity as an Info message and pass along the
severity
as a 'key/value' in the log line (i.e.severity=warn
) (except for Errors, which are always passed to the root Logger via the Error method). The reason this severity k/v pair wasn't added whenSetLogger
was originally added can be seen here: #20 (comment)Mostly there wasn't clear consensus as to what 'keys' should be used and what the onus is on implementors of the
logr
interface wrt setting these keys so other consumers can consume them reliably 😄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 understand why k/v isn't added. It's hard problem, until some set of standard keys is established.
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.
the above branching looks mostly correct to me, but i pinged the #klog channel of k8s slack for more reviewers.
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!