nm-cloud-setup usually runs via a timer and a dispatcher script. So it runs a *lot*, and by default it must not generate too much logging.


> But _LOGW() is not called in nm-cloud-setup and a few places called _LOGE().
> 
> I am suggesting the default NM_CLOUD_SETUP_LOG level to INFO as NetworkManager or print as warn or error when error occurs.

That nm-cloud-setup currently logs nothing with level WARN, merely means that no information so far was deemed to have that priority.

It does not mean, that the default level should change. What we currently log at INFO level, seems too verbose to enable by default.


> Actual results:
> No information to indicate what is the problem when no provider detected
> 
> Expected results:
> Give useful information when the application runs into exceptions.

Maybe we could log a warning, if any providers are enabled but none detected.

That still doesn't tell you, "what" is the problem, which would require TRACE logs.

(In reply to Thomas Haller from comment #1)
> nm-cloud-setup usually runs via a timer and a dispatcher script. So it runs
> a *lot*, and by default it must not generate too much logging.
> 
> 
> > But _LOGW() is not called in nm-cloud-setup and a few places called _LOGE().
> > 
> > I am suggesting the default NM_CLOUD_SETUP_LOG level to INFO as NetworkManager or print as warn or error when error occurs.
> 
> That nm-cloud-setup currently logs nothing with level WARN, merely means
> that no information so far was deemed to have that priority.
> 
> It does not mean, that the default level should change. What we currently
> log at INFO level, seems too verbose to enable by default.
> 
It make sense. Thanks
> 
> > Actual results:
> > No information to indicate what is the problem when no provider detected
> > 
> > Expected results:
> > Give useful information when the application runs into exceptions.
> 
> Maybe we could log a warning, if any providers are enabled but none detected.
Agree, with the proper warn/error message, the user will realize the service has problems.
As the example in this case, we just know the nm-cloud-service started, but it does not work actually because error hit.

> 
> That still doesn't tell you, "what" is the problem, which would require
> TRACE logs.

Yes, TRACE log is helpful for further investigation.

I still think, it makes sense that the default level is WARN. While we log some messages at INFO level, they seem too verbose as a default. If the default level would change to INFO, most of those messages should be downgraded to DEBUG. That is not obviously better. I am thus hesitant to change the default level from WARN to INFO.

Logging is anyway subject to constant tweaking. There are conflicting goals of providing enough information to understand what's relevant, vs. not being too verbose. So we can any the time reason whether a log line should be added/modified/dropped (or it's severity changed).

In this particular case, it would seem that logging a warning when no provider was detected would be sufficient. That would be done by 

  https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1659

Indeed, when NM enables any providers but fails to detect any, that seems a condition worthy to warn. A user probably shouldn't enable nm-cloud-setup in such an non-cloud environment or there is an actual problem. Both cases warrants a warning.


Otherwise, I think we should discuss very specific circumstances, where individual logging lines should be tweaked.

I think what's done with https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1659 is sufficient.

What we log is in general not well-defined, and there are conflicting requirements.

In this case, it seems the user was surprised why the plugin was not detected, while being enabled.
The change would log a warning in that case, so I think the problem is solved.


It's in general better to look at a very specific scenario, where the logging was confusing/incomplete, and try to address that. Instead of questioning the whole logging system (that the default is WARN instead of INFO). While we can discuss to default to INFO level instead of WARN, the current default level is chosen intentionally, and it's not clearly wrong. Meaning, I think it's right and should not change.


Moving forward to ON_QA.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (NetworkManager bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:6585