[patches] [cfg 1/1] cfg: Add constraints on box.cfg params

Konstantin Osipov kostja at tarantool.org
Mon Mar 5 21:32:58 MSK 2018


* Ilya Markov <imarkov at tarantool.org> [18/03/05 20:05]:
> >Can we change the default log_nonblock to nil, which means the
> >default is derived from log type, true for pipe/syslog, false
> >for file/stdout?
> >
> 
> Yes, we can. So this conversion from nil to default depending on type
> must be executed in lua or in box_check_config()?

There is no conversion. 

> >This would spare us from the useless warning. The patch will go to
> >2.x after that.
> Do you mean the patch with raising errors?

Yes and no. Yes, it will go to 2.0. Yes, it will raise errors on
broken configuration (a user has explicitly set two incompatible
values for log and log_nonblock, which I expect to be never the
case, since users very rarely set log_nonblock explicitly).

No, it will not break things that much.

> >What was the issue with moving the check for valid combinations
> >to box_check_config()? 
> >
> 
> It may be not so easy as in lua to add new cases. It requires
> add new `if`s for each case.  It may look ugly.

We don't have to come up with a general solution, we can have
say_check_config() which involves the say parser and then checks
the parser results (log_type) for compatibility with log_nonblock.

> >How does the check work when log_nonblock or some other
> >combination becomes invalid after initial configuration, e.g. in
> >this scenario:
> > box.cfg{}
> >box.cfg{log_nonblock=true}?
> 
> It would not fail as parameter `log` is not specified.

That's bad. It should fail, since logging is by default going to a
file, and we can't support nonblocking writes to a file.

> >After giving this some thought, the only reason we're doing it here 
> >is that we failed to refactor say.c and separate log string parser api 
> >so that it can be called independently from  box_check_config. Am
> >I right?
> >
> 
> For checking loggers it's ok to implement it in box_check_config.
> But if there are more constraints, it may be inconvenient.


> >
> ><cut> a lot of changes which will become unnecessary if we change
> >log_nonblock default after moving this problem to 2.0.
> >
> >-- 
> >Konstantin Osipov, Moscow, Russia,  +7 903 626 22 32
> > http://tarantool.org -  www.twitter.com/kostja_osipov
> 
> 
> -- 
> Thank you,
> Ilya Markov

-- 
Konstantin Osipov, Moscow, Russia, +7 903 626 22 32
http://tarantool.org - www.twitter.com/kostja_osipov



More information about the Tarantool-patches mailing list