This is by design and has been like this for quite some time, around the time when MaxScale 2.0 or 2.1 releases were done. This prevents conflicts when changes are done to the static configuration files for objects that were modified at runtime. It's not the smartest way of solving the problem but it is the most effective one as it eliminates the possibility of a configuration that is unable to survive a restart. It's also very simple to implement as you can simply dump the runtime configuration into a file instead of calculating a diff of the old and new parameters. For these reason I don't think this can be considered a bug and instead I'd label this as a New Feature (the old Improvement type would've suited this better).

If we want to change or improve the behavior, we'll probably be better off doing it in a major release as it involves a non-trivial amount of changes to implement. The configuration system is currently not capable of creating a diff of a configuration and it must be tweaked a bit to expose the set of values that changed.

Regardless of whether it's expected behavior or not, I think we could at least make it easier for users to spot why MaxScale acts the way it does. For example, if there is a static configuration and a dynamic one for an object in MaxScale and the static file was modified after the dynamic one was last updated, MaxScale could log a warning stating that there might be updates in the static file that will not be applied.

Thank you, Markus.

The issue is not with the dynamic configuration in general; it is clear how it works and it is OK. What you describe is fine for each custom section one may add, like routers, filters etc.

The issue is that changing one single parameter that belongs into the "maxscale" section makes maxctrl write all parameters from this section into the dynamic config using their default values. This is not transparent and confusing. If only one parameter from this section is changed, then only this one - with the changed value - should be written to the dynamic config. The dynamic config should work in "append mode", so when a given parameter is written there, it stays there.

The alternative I can think of - splitting the "maxscale" section into dozen or so smaller ones to maintain the current behavior for each section, e.g. one for logging, one for API etc. - seems to me more cumbersome and a bigger change than the one I suggested above.

Given that each section in the configuration is its own object, that is still expected behavior. Modifying it for the [maxscale] section means it must also be modified for all the other object types (routers, filters etc.) as they all use the same configuration system. As such, the current situation is that the whole configuration system works consistently for all objects in the configuration, including the "global" [maxscale] section, regardless of how confusing it is. If/when we decide to modify the behavior, it'll automatically apply to all object types.

For the new system, upgrading from older versions should provide consistent results as the old defaults would still be in use. The only problem is deprecated or removed parameters which require the dynamic file to be removed. For new installations, you'd only have the modified parameter stored in the file. This still suffers from all the problems of the previous one except that it is vulnerable to the problem of where two parameters can cause conflicts.

A simple example of these conflicts is the ssl_key parameter: it must always be defined with the ssl_cert parameter. The validation of the configuration is done based the final resulting configuration, not the intermediate parameter values passed to MaxScale in the update. If only the updated value of ssl_key is stored, then it is possible to break the configuration if ssl_cert and ssl_key are removed from the static file, leaving you with only the ssl_key that was defined at runtime. One option in this case is to ignore the runtime configuration and try to use only the static configuration. Even this doesn't guarantee that the object in question can be successfully created as you could have a broken config in the static file and in the dynamic file (due to it containing only the partial object definition).

One solution would be to leave it up to the end user to choose which method of storage is used: full, partial or none. This isn't ideal as it just shifts the problem to the end user without providing any real solutions.

Having discussed this issue over a number of days, the risk of creating a faulty configuration is not likely enough to warrant the problems the current approach of saving everything can have. We can change this in 6.3 so that configuration values that are currently set to their defaults are not saved into the automatically generated configuration files.

Turns out this requires more changes that are acceptable for a minor release like 6.3. Looks like it's only a handful of variables that caused the problems. Hard-coding them in adds about ten lines to the diff so it's probably worth doing for 6.3.