You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 8, 2022. It is now read-only.
If you look at this code snippet and now that stdout and stderr of plugins are remapped to snapd it seems reasonable to assume that errors occurring in plugins should be logged as errors in snapd so that user gets notified about them using proper logging level at snapd startup
The text was updated successfully, but these errors were encountered:
@obourdon as we discussed there are PROs and CONs for capturing the plugins stderr as either DEBUG or ERROR. I'm leaning towards staying conservative meaning that when someone wants to debug a plugin they will run snapd in debug mode to effectively surface whatever log messages the plugin might be logging (on stderr).
In the future we can decide if we want to extend the contract snapd establishes with plugins. For instance, I can imagine a plugin exposing to snapd, during the initial handshake, that it supports a strict implementation of structured logging such that snapd could interpret the plugins logs as it receives them and uses the same level when it prints it to snaps consolidated log (snaps stderr by default) however this will come at a cost (complexity and cycles).
I agree with @obourdon; errors should log as Error, not Debug that's how log level works. Due to Snap consolidated log(all together) and the complication @jcooklin mentioned, we need to put more thoughts into this.
If you look at this code snippet and now that stdout and stderr of plugins are remapped to snapd it seems reasonable to assume that errors occurring in plugins should be logged as errors in snapd so that user gets notified about them using proper logging level at snapd startup
The text was updated successfully, but these errors were encountered: