Description of problem: There is currently no way to modify the lvm configuration on a specific host without modifiying lvm.conf first due to the current default config. This is bad for configuration management systems (Chef, Salt, Ansible, ...) because changing the lvm configuration needs to modify lvm.conf which overrides the distro default config then with a template provided by the config-mgmt-system. Enabling hosttags by default could the situation because config-mgmt-systems can simply drop a file in /etc/lvm/lvm_$(uname -n).conf without modifying /etc/lvm/lvm.conf first. But that might have unwanted side-effects. This was already discussed a bit on irc with agk (Alasdair Kergon). The proposal there was to add a new config option that splits the config-file from the activation bits.
(In reply to Thomas Bechtold from comment #0) > Description of problem: > > There is currently no way to modify the lvm configuration on a > specific host without modifiying lvm.conf first due to the current > default config. Note: there are also "profiles" - you can use --profile/commandprofile/metadataprofile options and LVM_COMMAND_PROFILE environment variable, but they're only for selected settings so it also depends on what configuration options you're planning to change from defaults and for which LVM commands. There's some info on these in man lvm.conf. There's also --config command line option ("direct config override on command line"). The way all configuration is merged together is described in that man page. Currently, it's only "direct config override on command line" (the --config) and tag config (the hosttags) which provide full configuration override.
I'd say the whole purpose of configure file is to be able to specify local changes different from 'distro' defaults. There is not much difference in putting secondary overlay on top of 'distro' config on top of lvm2 upstream default config. It's probably worth to say - some portion of 'lvm.conf' defaults are configurable (if some really used & important one are missing - it could be improved). So distro should be building lvm2 with 'best fit' defaults - then distro should install empty lvm.conf. Now comes some software - which needs to 'change' defaults - so it will set them in lvm.conf. If there is another 'different' software - it would also need to modify lvm.conf in some way. Lvm might possibly improve support for changing settings (just like git does) so user would be able to call command to change settings with all the proper locking around (like we already have lvmdump for display)
Hm. I still don't get how I can override a config option without the need to modify the provided config file from the distro. If I need to modify the config file, I need to maintain a template (in the config-mgmt system) and update that template whenever something changes upstream in the config.
(In reply to Zdenek Kabelac from comment #2) > I'd say the whole purpose of configure file is to be able to specify local > changes different from 'distro' defaults. > > There is not much difference in putting secondary overlay on top of > 'distro' config on top of lvm2 upstream default config. > > It's probably worth to say - some portion of 'lvm.conf' defaults are > configurable (if some really used & important one are missing - it could be > improved). > > So distro should be building lvm2 with 'best fit' defaults - then distro > should install empty lvm.conf. > > Now comes some software - which needs to 'change' defaults - so it will set > them in lvm.conf. > > If there is another 'different' software - it would also need to modify > lvm.conf in some way. And the "different" software is then the problem. How would you edit lvm.conf without loosing the changes that the "first" software did? Having /etc/lvm/lvm.conf.d/100-software-one.conf and /etc/lvm/lvm.conf.d/200-software-two.conf would solve this. Each software could just edit its own config file and lvm would merge the config snippets (in the provided order) > > Lvm might possibly improve support for changing settings (just like git > does) so user would be able to call command to change settings with all the > proper locking around (like we already have lvmdump for display) That would also be a possibility