[openstack-dev] [oslo] interesting problem with config filter
ihrachys at redhat.com
Wed Dec 10 16:16:39 UTC 2014
-----BEGIN PGP SIGNED MESSAGE-----
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  from them about the way we’re using config filters in
> oslo.concurrency specifically, but the issue applies to their use
> 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
+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
> 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.
>  https://bugs.launchpad.net/oslo.config/+bug/1399897
> _______________________________________________ OpenStack-dev
> mailing list OpenStack-dev at lists.openstack.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
-----END PGP SIGNATURE-----
More information about the OpenStack-dev