I think I had a different takeaway from that thread. My understanding was that people were agreeing with you that CLI args *should* have highest precedence and override everything else.
The talk about permanence confuses me, unless we mean that more permanent values are overridden by less permanent ones. I was also confused by the ordering in this list, though when I read more carefully it seems to agree with me: > - Default value in source code > - Overridden by value in config file > - Overridden by value in environment variable > - Overridden by value given as command line option I'd like to rewrite that list as - Value given as a command line option - Failing that, value in environment variable - Failing that, value in config file - Failing that, default value in source code which I believe to be completely equivalent to Monty's original formulation. On Mon, Jul 1, 2013 at 2:52 PM, Clint Byrum <cl...@fewbar.com> wrote: > Last week I went to use oslo.config in a utility I am writing called > os-collect-config[1]... > > While running unit tests on the main() method that is used for the CLI, > I was surprised to find that my unit tests were picking up values from > a config file I had created just as a test. The tests can be fixed to > disable config file lookups, but what was more troublesome was that the > config file was overriding values I was passing in as sys.argv. > > I have read the thread[2] which suggest that CLI should defer to config > file because config files are somehow less permanent than the CLI. > > I am writing today to challenge that notion, and also to suggest that even > if that is the case, it is inappropriate to have oslo.config operate in > such a profoundly different manner than basically any other config library > or system software in general use. CLI options are _for config files_ > and if packagers are shipping configurations in systemd unit files, > upstart jobs, or sysvinits, they are doing so to control the concerns > of that particular invocation of whatever command they are running, > and not to configure the software entirely. > > CLI args are by definition ephemeral, even if somebody might make them > "permanent" in their system, I doubt any packager would then expect that > these CLI args would be overridden by any config files. This default is > just wrong, and needs to be fixed. > > [1] https://github.com/SpamapS/os-collect-config.git > [2] > http://lists.openstack.org/pipermail/openstack-dev/2013-May/008691.html > > Clint Byrum > HP Cloud Services > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev