[MXS-722] Implement a --config-test to check that configuration is correct Created: 2016-05-13  Updated: 2017-12-01  Resolved: 2016-05-18

Status: Closed
Project: MariaDB MaxScale
Component/s: Core
Affects Version/s: 1.4.3
Fix Version/s: 2.0.0

Type: New Feature Priority: Major
Reporter: Claudio Nanni Assignee: markus makela
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Relates
relates to MXS-66 MaxScale should refuse to load module... Closed
relates to MXS-100 /etc/init.d/maxscale configtest Closed
Sprint: 2016-10

 Description   

It would be good do have a configuration sanity check in the form:

$ maxscale --config-test

or

$ /etc/init.d/maxscale configtest

It could be implemented in the following way:

When MaxScale starts with such option should collect all options(in an array) from all modules (which should expose/register them), each option could be a structure of the type [optname, array

{opttype, allowed_values}

].

Not sure that the internal array for each option is needed, but using such structures allows to use multiple types(with their type and range check) for options that can be set to more than one type, e.g.:

address= [ip | hostname]

something= 0,1,ON,OFF

Meaningful error messages could be:

Error: Unknown option 'tipe' at row 12

Error: Value '999' for option 'threads' is out of range

Error: Value '192.168.1.' for option 'address' is not valid, expected IP or HOSTNAME (this example is tricky as the mistyped IP could also be an hostname).



 Comments   
Comment by markus makela [ 2016-05-18 ]

Added a --config-check option which tests if MaxScale would start successfully with the provided configuration. The log messages are printed to stdout instead of being written to the log files.

This option does not change the way modules start which means that if a module will connect to a service or create files, even a configuration check will do that. The only difference between a normal start and a configuration check is the printing to stdout and exiting after a successful start.

Generated at Thu Feb 08 04:01:26 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.