Prepend config vars with service name?

[patrickbenkoetter]

Should we prepend configuration variables with the service's name they relate to?

I'm asking because I fear without the specific context we might run into communication problems when we support users on mailing lists etc. as they may mention storage and it is not automatically clear which service they relate to. If we had e.g. collectd_storage and fetcher_storage or collectd_log_level, fetcher_log_level and reportd_log_level the relation would be unique and unmistakably clear.

I know longer var names are clumsy to type, but - personally - I believe we would benefit overall.

[mschiff]

"Discussions" would be a better place for such questions ;-)

But back on topic:
Let me ask: Would you also propose for software like postifix to have the names of all config options prepended with "main_" or "master_"? There will be many more examples like this.

I think repeating the filename in the name of every option that it belongs to would be very uncommon. It would be counterintuitive and add no real value.

If we would rename them as you suggest, I think this would defeat the purpose of having seperate config files in the first place so we could then also just merge the different config files into one big file.

But I personally would prefer the current approach.

[BLohner]

I think postfix´s configuration with many config variables being prefixed by "qmgr_", "smtp_", "smtpd_" etc... might have been one inspiration for this issue.

In an earlier versions we had such prefixes because everyting ws in one config object, so we needed to distinguish between "receiver_loglevel", "fetcher_loglevel" and "reporter_loglevel". Then with the split up in separate config objects this was deemd no longer necessary. However: the environment varaibles still do have and need a prefix so one can use one environment to configure all three components.

How the optiosn are named is indpeendent from in how many different configuration files they are used.
It is already now possible to use separate configuratipon files or to have one configuration file for all components, because we use sections in the ini-style configuration file.

It would just seem a bit redundant why all variables in the "reporterd" section are prefixed with "reporterd".

The advantage would be clarity about which variable a bug report is talking and confusions about which of the three loglevels or logfiles was configured in which way will be less likely when the config option has the full name due to the prefix.

The prefix already exists for the environment variables, it owuld eb easy to have the prefix for command line and configuration file just as well, and it would lead to more consistency with the environment variables.

[mschiff]

The advantage would be clarity about which variable a bug report is talking and confusions about which of the three loglevels or logfiles was configured in which way will be less likely when the config option has the full name due to the prefix.

Then create a template for issues where one needs to specify the daemon an issue is about

[andreasschulze]

Should we prepend configuration variables with the service's name they relate to?

at least if a user use environment variables only (as I do / docker use-case) most (all?) variables already contain a servicename