Configuration policy

[erikbosch]

The various KUKSA.val components as of today (Broker, Server, Kuksa-client, dbcfeeder, ...) today use quite different approaches to configuration. They typically support a combination of config-file, command line arguments and env-variables, but it is not consistently implemented and precedence is not always well defined and may differ. Supporting all 3 options (cli-argument, env-variable, config file) makes code somehwat complex as we then need to consider order of precedence

Would it be an idea to try agree on a general concept? And in the long run - or at least for new components - try to use the same principle for all.

Some ideas:

Config file "only"

No env-variables, as few cli-arguments as possible, typically only help, version and --config. Use a config file for the rest

[SebastianSchildt]

Having a unified concept would be good.

Normally I am not a fan of environment variables, but those are a pretty common concept in the container landscape. Although a pattern might be, that the containers have some extra scripting to inject those into config files.

[argerus]

Supporting all 3 options (cli-argument, env-variable, config file) makes code somehwat complex as we then need to consider order of precedence

This might be true, but I think the more important question to ask is whether using our applications would get easier by any proposed change.

We implement the configuration handling once (and maybe we should look into more reuse between different applications), but users of our applications will configure them countless of times.

Some ideas:

Config file "only"

No env-variables, as few cli-arguments as possible, typically only help, version and --config. >Use a config file for the rest

Removing support for both environment variables and command line arguments would definitely make our applications harder to configure in a lot of use cases.

Although a pattern might be, that the containers have some extra scripting to inject those into config files.

Yeah, definitely not easier than the current situation. Editing a file is a lot more effort than either supplying a command line argument or an environment variable (and more permanent). And as Sebastian also points out, it's pretty much standard practice to inject configuration using environment variables in container environments.

However, config files are a great way to be able to configure default values. But it's only great if it's also easy to also override them.

Regarding priority, I think it's pretty well defined what every "posix sysadmin" would expect.

From highest to lowest:

• command line arguments (overrides everything else)
• environment variables
• local config file
• system config file (i.e. in /etc/)
• default values

[erikbosch]

I have no problem with the "triple" approach. But do we want it for all possible configurations, or do we consider it OK to have cli-argument + env-variable only for configs we see as likely that someone wants to change or for all.

Especially for topics like tls-config and can see a risk that we will have quite a lot of configurations supported in the future.

[argerus]

I have no problem with the "triple" approach. But do we want it for all possible configurations, or do we consider it OK to have cli-argument + env-variable only for configs we see as likely that someone wants to change or for all.

The problem is determining what a user wants to be able to change easily. But sure, that's a possibility.

Another way to look at it, is that if we make it easy (in our code) to support arg+env+config for an option, it would not be any harder to support all three.

[SebastianSchildt]

I agree with the priority shared by John. That should also hold true if we decide to skip any of those options

I am not so sure, which options we should support to what degree especially around config/environment/commandline arguments.

Pretty clear to me

• default values (as in compiled in code and used, if nothing else is found).
• config file: We should have this. I don't think it is crucial at this point to have local/system config where the former extends/overrides the latter. Especially since a lot of our deployments are in containers anyway.

For command line arguments, there seem to be different patterns. You could - of course - enable everything in commandline, but I guess at one point it is hard to handle also for users (e.g. don't we all love these programs where -h gives three screens full of text). I did look into how other "server-like" things are doing it, e.g.

• dovecot: https://linux.die.net/man/1/dovecot that has basically only config file, a bit like Erik lined out above
• nginx: https://linux.die.net/man/8/nginx seems to be able to do anything, but basically just putting snippets of config in the command line. That is surely "easy", and likely easy to implement, but not very "discoverable" and personally I don't like the optics of it

Definitely there are other examples, I dod not find a good example of something that has "real" commandline arguments for everything.

For environments variables, as I said, I am not sure, IF we have them, should effort be spent to "parse them in main code", also keeping in mind afair there are maybe not as good libs for parsing/type checking as you get when parsing "real" command line arguments or a config file.

An extreme example of the "Use environment variables to control a container environment" is docker-mailserver. This is the .env file example https://github.com/docker-mailserver/docker-mailserver/blob/master/mailserver.env (So basically everything you could "by hand" give via -e in docker). Obviously Postfix, Dovecot, ClamAV etc.are not all controlled directly by this, instead this contains a lot of scripting converting those env variables to whatever config (file) a given component uses.

Of course whether supporting ENV directly or "wrapping" them via scripts, it needs to be coded anyway if desired.

If you ask me right now (but I will read more comments :) ) it feels to me one would want

• commandline arguments for a FEW common things
• config files
• (default values)

And maybe add env support for some things in containers, although question would be how far to go here. ("scope of cmd lne args? scope of config? in-between? Is that maybe confusing?)

My view is a bit split between a user (who would like ALL THE THINGS) and dev (how much can/do we want to implement/test) )

Also, while I think our providers for example should "feel" largely the same, I could see us making a different decision for databroker.

[sophokles73]

If you ask me right now (but I will read more comments :) ) it feels to me one would want

• commandline arguments for a FEW common things
• config files
• (default values)

sounds reasonable to me but also supporting environment variables for the (few) supported command line args would make it much easier to use the stuff in containers ....