[openstack-dev] [oslo] interesting problem with config filter

Ihar Hrachyshka ihrachys at redhat.com
Wed Dec 10 16:16:39 UTC 2014

Hash: SHA512

On 08/12/14 21:58, Doug Hellmann wrote:
> 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.

It's not just unit tests. It's also in generic /etc/neutron.conf file
installed with the rest of neutron:

There is nothing wrong in the way neutron sets it up, so I expect the
fix to go in either oslo.concurrency or oslo.config, whichever is

> 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”.

+1. It's not deployer's job to read code and determine which options
are substitution-aware and which are not.

> I see a few solutions:
> 1. Don’t use the config filter at all.

+1. And that's not just for oslo.concurrency case, but globally.

> 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?

I'm not an oslo guy, so I leave the resolution to you.

> Doug
> [1] https://bugs.launchpad.net/oslo.config/+bug/1399897 
> _______________________________________________ OpenStack-dev
> mailing list OpenStack-dev at lists.openstack.org 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)


More information about the OpenStack-dev mailing list