Re: [Tarantool-patches] [PATCH] lua/log: accept symbolic logging levels

[Alexander Turenko via Tarantool-patches <tarantool-patches@dev.tarantool.org>]

On Thu, May 27, 2021 at 10:53:32AM +0300, Cyrill Gorcunov wrote:
> On Thu, May 27, 2021 at 01:04:54AM +0300, Alexander Turenko wrote:
> > Sorry for the late response.
> > 
> > Looks nice! LGTM.
> > 
> > If you'll have a free time, it would be good to add a simple test case:
> > just to automatically verify it for regressions in a future.
> > 
> 
> Thanks! I force pushed an update where a test added (we can extend
> it in future).

> +-- Test symbolic names for loglevels
> +_, err = pcall(log.cfg, {level='fatal'})
> +test:ok(err == nil and log.cfg.level == 0, 'both got fatal')

Now I noticed one difference from box.cfg() behaviour:

 | tarantool> box.cfg{log_level = 'verbose'}
 | tarantool> box.cfg.log_level
 | ---
 | - verbose
 | ...

 | tarantool> log = require('log')
 | tarantool> log.cfg{level = 'verbose'}
 | tarantool> log.cfg.level
 | ---
 | - 6
 | ...

AFAIU, box.cfg.foo generally returns the same that a user provides in
box.cfg({foo = <...>}), without normalization.

The only exception from this rule, known to me, is convertion from a
number to a string for box.cfg.listen:

 | tarantool> box.cfg{listen = 3301}
 | tarantool> box.cfg.listen
 | ---
 | - '3301'
 | ...

I don't know, to be honest, whether the general rule was part of design
or becomes so unintentionally. However, when we add listening on zero
port ([1]), we added a real port into box.info.listen and didn't perform
normalization in box.cfg.listen.

Not a blocker, IMHO, but it worth to think about. I'll add Vlad into the
discussion. Maybe he knows more than me.

[1]: https://github.com/tarantool/tarantool/issues/4620

WBR, Alexander Turenko.