-----BEGIN PGP SIGNED MESSAGE----- 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: https://github.com/openstack/neutron/blob/master/etc/neutron.conf#L23 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 achievable. > > 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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUiHHnAAoJEC5aWaUY1u57DOsH/i+FY46YWH2lSguYPS5h+Ciu S/fwzamKrcF6Y2pipl+j55CiIyIejlnXwE+UV90k4gM9G6vl4T6u1w6N9dus67pu 6kWHty4eDGHGIuj0iGWIWUNPN6ChHNmhxoFadvZKCBWULeTvh3DL/Ply4MYx4bqF MbtpAE5Qh2OUUO977kSjcULZtgrIYeInKd5tdZkLmXf0PQnMKU9rEwa8DNZL24Ro sBZ6GKDXfa4vqk5alFiWoqxW/MUoi6Ngxm2T0OJZy20L6BL5n8sT96rinAbtGzo5 CELu91D6UeFR/rry2bI6DIS7rPN4BHCsSTZ1cXK/wxLHTqaSP50qj2phZ7zGbVA= =IuLJ -----END PGP SIGNATURE----- _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
