lxd libraries don't expose facilities to set log level
Required information
- Distribution: Ubuntu
- Distribution version: 22.04
- The output of "lxc info" or if that fails:
- Kernel version: 6.5.0-14-generic
- LXC version: 5.20
- LXD version: 5.20
- Storage backend in use: Any
Issue description
The LXD libraries don't expose any facility to set (or get) the log level of its logger implementation. LXD uses logrus' logger internally, which implements these interfaces, but it's not possible to access them either because they don't export the underlying logger. As such, any project that uses LXD's libraries and wants to set the log level needs to resort to rather ugly hacks.
Steps to reproduce
Importing the LXD libraries and trying to access the logrus logger results in an error since it isn't exported. LXD's libraries don't have any interfaces to control the log level either.
Please can you indicate which libraries you are referring to?
Sorry about the confusion. I mean these: https://github.com/canonical/lxd/tree/main/shared/logger
Please can you explain a bit more about what you're trying to do? Thanks
Yes, of course.
The microceph project currently leverages LXD libraries to simplify deployment and make use of a comprehensive code base. One issue we've seen in embedded deployments is the fact that storage may be constrained quite a bit and so we'd like to control the log level to circumvent such restrictions. However, the LXD logger doesn't provide us with any way to do this and so we had to resort to a rather ugly hack to get around this limitation. See here for more details.
@masnax please can you review this and come up with suggestion(s) on how we should proceed with logging in micro* packages.
@masnax @lmlg perhaps micro* repositories should switch to using slog from Go https://go.dev/blog/slog
@masnax @lmlg perhaps micro* repositories should switch to using slog from Go https://go.dev/blog/slog
I personally don't think a library switch is needed. In our case, it would suffice to have interfaces to get/set the log level (something that the logrus logger already does).
@masnax any progress with this?
I think it's a good idea to allow dynamically changing the log level just for the added flexibility in LXD. LXD does have lxc monitor but setting the log level to debug for the daemon itself still requires a restart so this could help with that.
As for no longer relying on LXD for logging in microcluster projects, it would be a bit of a re-implementation with a more modern package but it would be a good litmus test for eventually using slog with LXD.
I believe slog requires go 1.21 so if these projects still need to support an earlier go version for an LTS track or something, then they'd likely still rely on LXD's logger, so adding the capability here makes sense.
So I think the approach here will be to add the capability of setting the log level in LXD, but then also moving upstream microcluster to slog.
They are all only distributed by snaps so we control the Go version, 1.21 should be fine.
@masnax any reason not to just switch to slog and avoid needing to dependent on LXD's logger (we will probably switch to slog too eventually), but for something as general as a logger I'm not seeing the value in depending on LXD's one, am I missing something?
@masnax any reason not to just switch to slog and avoid needing to dependent on LXD's logger (we will probably switch to slog too eventually), but for something as general as a logger I'm not seeing the value in depending on LXD's one, am I missing something?
To clarify, I am going to move microcluster to slog. I just also think having this in LXD is useful for LXD.
The initlal reason we used LXD's logger was to avoid reimplementing one for each LXD-adjacent project. All the micro-apps were designed with LXD in mind, so using the same utilities keeps the code looking consistent, and keeps the output consistently formatted too.
The initlal reason we used LXD's logger was to avoid reimplementing one for each LXD-adjacent project. All the micro-apps were designed with LXD in mind, so using the same utilities keeps the code looking consistent, and keeps the output consistently formatted too.
Yeah I agree, I expect we'll move to slog too.