[SSSD] Discussion of debug log levels

[Stephen Gallagher]

We've put this off for far too long, but I think we need to decide on a
formal specification of what the various log levels mean in SSSD (and
then open a ticket to go through them all clean them up).

We didn't do this in the past because we had expected that this would be
handled when we eventually integrated with the ELAPI (Event-Logging API)
project. Unfortunately, that project stalled upstream and its future is
unknown.

So I think we need to document the exact purpose of each log level and
publish this information so that consumers of the SSSD can have a good
understanding of what level they should set (or leave running in
production).

I'll give my first suggestions, and then I'll listen to criticism :)


First, I think we need to break the debug levels up into three ranges,
roughly corresponding to error messages, informational messages and
developer messages.

So I propose that error messages should be 0-3
0: Fatal failures. Anything that would prevent SSSD from starting up or
causes it to cease running. (Example: sssd.conf fails to parse)
1: Critical failures. An error that doesn't kill the SSSD, but one that
indicates that at least one major feature is not going to work properly
(Example: Kerberos keytab does not have a valid principal for
SASL/GSSAPI LDAP)
2: Serious failures. An error announcing that a particular request or
operation has failed. (Example: DP returns PAM_SYSTEM_ERR)
3. Minor failures. These are the errors that would percolate down to
cause the operation failure of 2. (Example: The above PAM_SYSTEM_ERR was
due to the krb5_child returning an unexpected error)

Informational messages should be 4-6
4. Configuration settings (E.g. the dp_option loading)
5. Function data (E.g. LDAP search request data, Dynamic DNS message)
6. Tracing messages for functions (Example: received DBUS method call
"ping")

Developer messages should be 7-9
7. Contents of function-internal variables that may be interesting
8. ???
9. Extremely low-level tracing information (Example: adding/removing
D-BUS watches)