The magic behaviour of 'logging level all LEVEL'

[Vadim Yanitskiy]

Hi Pau, Neels, and all,

It seems, the reason of my misunderstanding was that confusing
'all' keyword. I have been interpretting it as 'default', but
actually it is far from this meaning...

> So after my proposal (from my last email):
> ...
> logging level (all|default|<category>) (unset|<loglevel>)
> ...
> Agree?

Yep, finally I am ;)

In order to have a clean commit history, I suggest the following
algorithm (one high level point represents one single change):

1. Introduce 'unset' keyword first;
2. Introduce 'default' logging category ('logging level default'):
2.1. Modify the 'logging level' command (by adding 'default');
2.2. Correct memory allocation in log_vty_command_string();
2.3. Write *exactly 'default'* (not 'all') to the configuration;
3. Fix the behaviour of 'default' (i.e. target's) logging category:
3.1. In other words, correct the loging in should_log_to_target();
4. Correct the behaviour of 'logging level all LEVEL';
5. Testing coverage ;)
6. <New features> ...

> And same as my last comment, you are changing a decade old vty command.
> Last time I did this it was the wrong choice.

Regarding to changing the behaviour of 'logging level all LEVEL'
command, I think we need to make this step. Let's have a look
at OsmoHLR configuration, shipped as an example:

log stderr
  ! ...
  ! Set *default* log level 'debug' for stderr
  logging level all debug
  logging level linp error

What would we get now (before merging the patch set)?

The 'debug' becomes default, but since the logging is broken,
the hardcoded values will be used for all categories,
excluding 'linp'. The 'all' remains confusing...

If one saves the current configuration, the result would be:

log stderr
  ! ...
  ! Set *default* log level 'debug' for stderr
  logging level all debug
  logging level linp error
  logging level foo <hardcoded>
  logging level bar <hardcoded>
  ! all other categories...

What would we get after this patch set?

The first command is now interpreted as it should be interpreted.
So, we have no 'default' logging level (i.e. it becomes 'unset'),
all categories, excluding 'linp', are set to 'debug'.

If one saves the current configuration now, the result would be
similar, i.e. it will also dump all possible categories, but
instead of <hardcoded> values 'debug' would be used:

log stderr
  ! ...
  ! Set *default* log level 'debug' for stderr
  logging level default debug
  logging level linp error
  logging level foo debug
  logging level bar debug
  ! all other categories...

How to avoid this after merging the patch set?

Update the configuration examples, replacing 'all' by 'default'.
Either, doing 'logging level all unset' before saving to file.

This way one would get the original configuration untouched,
i.e. without dumping all possible categories...


Then we can think about new features, and this is what do I
think about some of them (described by Neels):

> A.1. A command to reset all to hardcoded defaults?

I like the idea of Neels about resetting the logging levels.
Additionally to the hardcoded logging settings, would be great
to have a possibility to reset to the logging settings from
the current configuration...

I assume the following syntax for that:

  logging level (all|default|<category>) reset

> C) Temporarily reducing the logging
> D) Temporarily increasing the logging
> E) Remove temporary logging to go back
>    to the "normal" logging landscape.

Regarding to the 'temporary' staff, I think one can interpret
the current ('running') modified configuration as 'temporary'.
You're free to change everything, and if you like the current
logging configuration - you can write it to a file. Otherwise,
your idea about resetting fits here just fine, so one would be
able to restore the current configuration from file at runtime.

> F) ... silence all messages ... unless they match
>    the context filter: logging filter imsi 123456789123456
> ...
> 3) enable / disable individual filters
> 4) disable all filters

I think it's useful feature. I didn't even know about this :)
Another interesting idea is to introduce a RegExp based filter
(if not yet), like we have in the talloc context
introspection command. Examples:

  logging filter regexp (failed|unable|couldn't)
  logging filter regexp ^BTS[0-9]+

BTW: I also find 'logging filter all 1' confusing ;)

With best regards,
Vadim Yanitskiy.