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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to