Open Stack

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 <clint at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130701/4c08343a/attachment.html>