-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
logging: do not swallow subsystem logs #19188
logging: do not swallow subsystem logs #19188
Conversation
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.
High level, if we can catch some of those missing log cases, this is in an improvement and I'm all for it. I've dropped a few notes below just since I wasn't entirely clear on which cases should be using error wrapping vs. logging directly and whether you had an idea in mind about which to use depending on where in the calltree the code is.
Given the potential improvements to debuggability, I'm nominating this for 1.11 backport. |
@@ -242,7 +242,7 @@ func (d *Daemon) init() error { | |||
} | |||
|
|||
if err := d.Datapath().Loader().Reinitialize(d.ctx, d, d.mtuConfig.GetDeviceMTU(), d.Datapath(), d.l7Proxy); err != nil { | |||
return err | |||
return fmt.Errorf("failed while reinitializing datapath: %w", err) |
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 is good, though for something like Reinitialize
we may want to do another round of review inside there to evaluate the logging for each failure case and potentially disambiguate them, maybe even push the logging down if that allows the child function here to provide additional context for debugging.
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.
@joestringer it appears that the Reinitialize
method handles logging internally.
// Lock so that endpoints cannot be built while we are compile base programs.
o.GetCompilationLock().Lock()
defer o.GetCompilationLock().Unlock()
defer func() { firstInitialization = false }()
l.init(o.Datapath(), o.LocalConfig())
if err := l.writeNetdevHeader("./", o); err != nil {
log.WithError(err).Warn("Unable to write netdev header")
return err
}
for example.
So in our logs, Reinitialize will display a fair amount of log information before we pop out the stacked error here on line 245.
commit cilium#16861 introduced a normalization of error handling into the daemon/cmd package. by doing so we swallowed useful error logs. this commit adds the error logs back and adds a few additional fmt.Errorf wrappers where logging is not adequate Signed-off-by: Louis DeLosSantos <louis.delos@isovalent.com>
d7eec02
to
0abd290
Compare
alright @joestringer I think this one is ready to go. |
/test |
This pull request has been automatically marked as stale because it |
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.
Sorry, seems like I completely dropped the ball on this one. LGTM.
commit #16861 introduced a normalization of error handling into the
daemon/cmd package.
by doing so we swallowed useful error logs.
this commit adds the error logs back and adds a few additional
fmt.Errorf wrappers where logging is not adequate
Signed-off-by: Louis DeLosSantos louis.delos@isovalent.com