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