Open Stack

As we’ve discussed a few times, we want to isolate applications from the configuration options defined by libraries. One way we have of doing that is the ConfigFilter class in oslo.config. When a regular ConfigOpts instance is wrapped with a filter, a library can register new options on the filter that are not visible to anything that doesn’t have the filter object. Unfortunately, the Neutron team has identified an issue with this approach. We have a bug report [1] from them about the way we’re using config filters in oslo.concurrency specifically, but the issue applies to their use everywhere. 

The neutron tests set the default for oslo.concurrency’s lock_path variable to “$state_path/lock”, and the state_path option is defined in their application. With the filter in place, interpolation of $state_path to generate the lock_path value fails because state_path is not known to the ConfigFilter instance.

The reverse would also happen (if the value of state_path was somehow defined to depend on lock_path), and that’s actually a bigger concern to me. A deployer should be able to use interpolation anywhere, and not worry about whether the options are in parts of the code that can see each other. The values are all in one file, as far as they know, and so interpolation should “just work”.

I see a few solutions:

1. Don’t use the config filter at all.
2. Make the config filter able to add new options and still see everything else that is already defined (only filter in one direction).
3. Leave things as they are, and make the error message better.

Because of the deployment implications of using the filter, I’m inclined to go with choice 1 or 2. However, choice 2 leaves open the possibility of a deployer wanting to use the value of an option defined by one filtered set of code when defining another. I don’t know how frequently that might come up, but it seems like the error would be very confusing, especially if both options are set in the same config file.

I think that leaves option 1, which means our plans for hiding options from applications need to be rethought.

Does anyone else see another solution that I’m missing?

Doug

[1] https://bugs.launchpad.net/oslo.config/+bug/1399897