log.cfg{modules = ...} isn't equivalent to box.cfg{log_modules = ...}

[Gumix]

#7672 allows to specify a log level for each module individually, however there is some inconsistency:

• box.cfg{log_level_modules={...}} overrides the existing list of modules in log.cfg, while
• log.cfg{level_modules={...}} appends the specified modules to the existing list.

Also it's not possible to remove a single module from the config by setting it to box.NULL.

gh_3211_per_module_log_level_test.lua contains the corresponding test-cases under TODO.

@nshy:

I would also check that resetting works if we first call log.cfg and then box.cfg (first box.cfg call, reset here smth from level_modules). I bet it will not work now. Unfortunately it is not easy to test with server:exec as it calls box.cfg on start.

The fix of this issue requires thorough changes in merge_cfg(), etc.

[Totktonada]

Please, glance on #8610 as well.

[locker]

• box.cfg{log_level_modules={...}} overrides the existing list of modules in log.cfg, while
• log.cfg{level_modules={...}} appends the specified modules to the existing list.

I think that we should make log.cfg{modules = ...} behavior the same as box.cfg{log_modules = ...} not the other way around, i.e. reset the configuration to the new one, not merge it with the existing config.

Rationale:

• This would be consistent with other box.cfg options taking tables (listen, replication, wal_ext, audit_spaces, metrics).
• Config table merging may be done at the upper level if necessary (in the config registry) so it's better to keep box.cfg simple.
• If we merge the new log_modules table with the old one in box.cfg then to reset the config, the user would either have to call box.cfg twice (first box.cfg{log_modules = box.NULL} then box.cfg{log_modules = ...}) or read the box.cfg table and then set all its values to box.NULL. Both ways aren't very convenient.

[locker]

The current behavior of log.cfg (merging the new modules table with the old one) isn't explicitly documented. The documentation for log.cfg.modules refers to box.cfg.log_modules and all code snippets use box.cfg.log_modules. So I think we can consider the current behavior of log.cfg a bug and fix it both in 2.11 and 3.0.