oslo.config reads options in a confusing and counter-intuitive order

[Monty Taylor]

The current behavior of oslo.config is to have config files override command line options. This is backwards and wrong. Directly given command line options should ALWAYS be the element which takes the most precedent. In fact, the typical and correct order that every piece of software follows and which every user expects is (order of least-precedence to most-precedence)

- Built-in defaults
- System config files
- User config files (if that is a thing that makes sense)
- Environment variables
- Command line options

Swapping the order of any of these things makes the software massively unusable, because it means the presense of a file in /etc will override an option given on the command line. This can have very dangerous unexpected effects (user expects to be spinning up a test instance, does not) and is very difficult to work around.

[Robert Collins (lifeless)]

In the list thread on this the relative difficulty of editing the command line for systemd was advanced as a reason to alter the order. I think this was responded to on-list, but for the record - the most predictable way to solve this is to change the systemd config file so that it has no options, and then users can change the config file for everything.

[Andrew Forrest (forrest-r)]

In fact, since the user can only override option values by using a configuration file they MUST either

1) supply values in their user-supplied config file for ALL options listed in the original system configuration file; or,
2) use an initial --config-file directive on the command line to force the processing of the original system configuration file before any --config-file directive pointing to a user-provided configuration file.

If this isn't done, the user runs the risk of having the value of some option that they haven't even specified changing.

This can arise if the default value for the option differs in the source code from that supplied in the system configuration file. (Easy to happen as an installation is tuned). Supplying a user-provided configuration file on the command line _suppresses_ processing of the system configuration file causing the option value to revert to the default provided in the source code even though it is mentioned on neither the command line nor the user-supplied configuration file.

I agree with Monty Taylor in that I find the order/rules for oslo.config processing inconvenient and surprising.

[Zhongyue Luo (zyluo)]

Does this patch solve your problem?

https://bugs.launchpad.net/oslo/+bug/1176817

The fix is included in oslo.config-1.2.0a3

  http://docs.openstack.org/developer/oslo.config/#a3

[Ben Nemec (bnemec)]

I'm marking this fixed based on Zhongyue's link. Please respond if this is not correct.

[Monty Taylor (mordred)]

Moving back to fix-committed ... oslo.config hasn't made a final release of 1.2. Once it does, then we'll move fix-committed bugs to fix-released.