Another database product we use (not a mysql variant) has a similar idea implemented by way of a required command line flag when making a dynamic change: -m for in-memory-only and -f for also updating the configuration file to reflect the change. A backup copy of the file is created, too, so no worry about overwriting.

MaxScale already warns if runtime changes have been made to an object found in the static configuration file:

2021-02-23 08:28:19   warning: Found static and runtime configurations for [RW-Split-Router], ignoring static configuration. Move the runtime changes into the static configuration file and remove the generated file in '/home/markusjm/build-2.5/lib/maxscale/maxscale.cnf.d' to remove this warning.

Whether persisted changes are read is already configurable with the load_persisted_configs parameter.

As for updating the actual static configuration file, in most cases MaxScale itself doesn't have write access to the configuration file it is used with which means an alternative method to persist changes must still exist.

I'm not sure a message buried in the log file is sufficient. By the way, in my version, at least (2.4.15), it shows up not as a warning but as a notice.

Is there a downside to requiring that the MaxScale config file be owned by the user that runs the "maxscale" process? The only issue I can see is that the config file can include passwords, but whatever process runs MaxScale already has read access to the file (or it wouldn't be able to start at all), so that security issue is moot.

On my system:

$ ls -la /etc/maxscale.cnf
rw------ 1 maxscale maxscale 1129 Oct 29 15:54 /etc/maxscale.cnf

Could do a similar requirement for /etc/maxscale.cnf.d and its contents.

The load_persisted_configs parameter is good to know.

Perhaps a maxctrl command to generate a new configuration file (in a new location or name) based on currently-running MaxScale configuration? Then when, e.g., support asks for MaxScale configuration file, instead of asking for the file, they ask for that command to be run and its output. (Which is less unwieldy than a series of maxctrl show commands)

I'd add that whether or not to persist a change may vary from one change to the next. So an all-or-nothing parameter, while welcome, may still be insufficient.

You can generate a configuration file from the current setup with maxscale --export-config=/path/to/new-config.cnf. You'll require read access to the files so you need to run it as sudo maxscale --user=maxscale --export-config=....

I don't think the file has to be owned by MaxScale, it just needs read access to it. As for write access, I believe that it's just customary to not provide write access to the configuration for a program that reads it. There's no technical limitation that prevents MaxScale from modifying it.

There's a bit of a security issue with the maxscale --export-config command: It creates the file with 644 permissions, including the passwords.

That's something that could be changed, read and write access for both user and group seems like the correct thing. I've opened MXS-3415 for it.

Another thought occurs to me: How about also printing a warning when a dynamic change is applied? e.g.,

Warning: New setting [whatever] written to [file]; check setting of load_persisted_configs

Something like that.

It seems most of what's been discussed in this issue already exists in one form or another:

• The whole persistent configuration mechanism can be disabled with load_persisted_configs=false
• The complete configuration can be exported with --export-config
• MaxScale warns whenever it loads persisted configurations

The only thing that aren't there:

• A complete log of all modifications done to MaxScale (helps figure out who changed and what)
• Visual markers for knowing if the current runtime configuration is different from the one defined by the static configuration files
• A way to conditionally persist changes

A complete log of all REST API actions would be useful for both auditing purposes as well as figuring out what changed and when. I've opened MXS-3827 for this.

One could argue that the line between static and runtime configurations has blurred with the addition of the GUI which makes the whole configuration process dynamic. Showing whether a change has been made could still be valuable information for the cases where the static configuration defines the desired setup and runtime changes are done to react to changes in the environment. We could start off by adding a simple boolean flag to tell whether the object was modified either via the REST API or by being loaded from a dynamically generated file. A more advanced version would tell where each change originated from, either from a static config or via a dynamic change.

Conditionally persisting changes would be doable but it would either be technically complex or result in what I consider less than optimal behavior. As some parameters in MaxScale can depend on other parameters (e.g. ssl_key and ssl_cert depend on each other), conflicting configurations must not be generated. This is also the reason why a complete state snapshot is stored on disk: storing just the parameter alone allows the combination of runtime changes and static configurations to generate an invalid configuration.

Simply skipping the persist step would allow a parameter to be modified without it being persisted on disk but the next time a parameter would be persisted, even the changes that weren't persisted would get stored on disk. Since it's possible to opt-out of the whole persisted configuration mechanism while still allowing the modified configuration to be stored and optionally enabled later on, this method doesn't seem particularly useful to me. It might be of limited use if you would configure maxctrl to always skip the persist step unless manually instructed to do so (the addition of ~/maxctrl.cnf makes this possible).

The second option is to keep two values for each configuration parameter and store only the latest persisted value for each. This would require adding additional logic into the configuration processing code that makes sure that both the runtime and the persisted configurations would result in a sane configuration. This would be a more complex thing to implement as the configuration system in MaxScale is quite modular and the "subclasses" of the configurations usually impose their own restrictions on what is valid and what isn't. This would also make the logic of the configuration persistence even more confusing as you'd essentially have two configurations. At this point I'd argue that it would be simpler to disable the loading of persisted configurations and to manually amend "important" changes to the static configuration once they have been done at runtime, similarly to how it's been done with MariaDB for ages.

From the customer perspective, I would add that consistency in behavior between MariaDB and MaxScale as pertains to dynamically-made changes would be highly desirable. I'd also note that other products I use that allow one to persist dynamically-made changes will automatically generate a new configuration file (keeping a backup of the old one) so that there's no separate, hidden "supplemental" configuration file to worry about.

I think we can make the life of the MaxScale administrators easier by returning more information to the client program whenever a change that causes an overriding configuration to be created. This warning can also be logged so that it is visible in the log as well.

One improvement that can also be done is to show which file an object was loaded from. This should also help identify when an object was created at runtime or when it is read from a static file.

6.3.0 will now let the user know immediately when they modify something that's defined in the static config. The file from which an object is loaded is also shown in the maxctrl show server output which should help reduce confusion.

I still think it would be highly useful to have a command line option for maxctrl that explicitly tells it to persist (or not persist) the change on a one-off basis.