lxd icon indicating copy to clipboard operation
lxd copied to clipboard

lxd libraries don't expose facilities to set log level

Open lmlg opened this issue 1 year ago • 13 comments

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.

lmlg avatar Feb 08 '24 16:02 lmlg

Please can you indicate which libraries you are referring to?

tomponline avatar Feb 08 '24 16:02 tomponline

Sorry about the confusion. I mean these: https://github.com/canonical/lxd/tree/main/shared/logger

lmlg avatar Feb 08 '24 16:02 lmlg

Please can you explain a bit more about what you're trying to do? Thanks

tomponline avatar Feb 08 '24 16:02 tomponline

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.

lmlg avatar Feb 08 '24 16:02 lmlg

@masnax please can you review this and come up with suggestion(s) on how we should proceed with logging in micro* packages.

tomponline avatar Feb 12 '24 16:02 tomponline

@masnax @lmlg perhaps micro* repositories should switch to using slog from Go https://go.dev/blog/slog

tomponline avatar Feb 12 '24 17:02 tomponline

@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).

lmlg avatar Feb 14 '24 19:02 lmlg

@masnax any progress with this?

tomponline avatar Feb 21 '24 13:02 tomponline

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.

masnax avatar Feb 22 '24 23:02 masnax

They are all only distributed by snaps so we control the Go version, 1.21 should be fine.

tomponline avatar Feb 23 '24 08:02 tomponline

@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?

tomponline avatar Feb 23 '24 08:02 tomponline

@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.

masnax avatar Feb 23 '24 18:02 masnax

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.

tomponline avatar Feb 26 '24 08:02 tomponline