Support XDG configuration locations
Today for users the configuration we search down till we find a config, first one wins:
~/.choriarc~/.mcollective- for windows:
c:\programdata\choria\etc\client.conf /etc/choria/client.conf/usr/local/etc/choria/client.conf/etc/puppetlabs/mcollective/client.cfg
We then merge:
choria.confin pwd and each ancestor directory
This is pretty crazy, but things are about to get worse as we have to consider:
- The registry will need a cache for DDL files
- Non CA based setups store ed25519 keys, jwt tokens etc
So we have to start thinking about data storage in client dirs etc
In linux world we have the XDG Base Directory Specification and I want to support this going forward as the way for user config.
So this means above list becomes:
- on *nix
~/.config/choria/choria.conf - on windows
C:\Users\username\AppData\LocalakaLocalAppDataor%LOCALAPPDATA% - for windows:
c:\programdata\choria\etc\client.conf /etc/choria/client.conf/usr/local/etc/choria/client.conf
We then merge:
choria.confin pwd and each ancestor directory
I will support old ones a bit but start warning about them I think.
For caches for registry we would then use XDG_CACHE_HOME aka ~/.cache/choria/registry by default and on windows LocalAppData\cache\choria\registry.
We can use the https://github.com/adrg/xdg package that includes the windows stuff as above.
Comments @smortex and @bastelfreak pls?
Hitlist here is basically:
util.UserConfig()should first check XDG paths- Various updated in
config.normalize()to check current setting and if not fall to XDG, mainly token and seed files - Add some helpers to
confkeyto resolve ie. we have~/foobut maybe something like{{CACHE}}/registrywould expand to~/.cache/choria/registry
LGTM!
On the top of my head, if some variable substitution (i.e. CACHE in your message above) is allowed maybe it can be useful to interpolate other configuration settings. A use case would be for example to have the cache registry configured once in ~/.config/choria/choria.conf and set to {{CACHE}}/registry-{{plugin.choria.srv_domain}}; and then the choria.conf in the current working directory does not have to override it for each config?
Interesting, certainly possible but would need to think about it, the configuration system is pretty overloaded with features already :)
I tend to solve that with project directories since your excellent choria.conf addition