[Tarantool-patches] [PATCH] lua/log: accept symbolic logging levels
Alexander Turenko
alexander.turenko at tarantool.org
Thu May 27 12:04:31 MSK 2021
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.
More information about the Tarantool-patches
mailing list