On 08/08/14 11:04, Matthew Booth wrote: > On 07/08/14 18:54, Kevin L. Mitchell wrote: >> On Thu, 2014-08-07 at 17:46 +0100, Matthew Booth wrote: >>>> In any case, the operative point is that CONF.<attribute> must >>> always be >>>> evaluated inside run-time code, never at module load time. >>> >>> ...unless you call register_opts() safely, which is what I'm >>> proposing. >> >> No, calling register_opts() at a different point only fixes the import >> issue you originally complained about; it does not fix the problem that >> the configuration option is evaluated at the wrong time. The example >> code you included in your original email evaluates the configuration >> option at module load time, BEFORE the configuration has been loaded, >> which means that the argument default will be the default of the >> configuration option, rather than the configured value of the >> configuration option. Configuration options must be evaluated at >> RUN-TIME, after configuration is loaded; they must not be evaluated at >> LOAD-TIME, which is what your original code does. > > Ah, thanks, Kevin. The pertinent information is that the config has not > been loaded at module import time, and you'll therefore always get a > default.
Ironically, the specific instance which prompted this investigation[1] is in a driver. As drivers are imported dynamically after the config has been loaded, using a config variable in import context will actually work as intended. Relying on that behaviour seems pretty nasty to me, though. We could probably do with a guideline on this. I did a quick scan of Nova and found 12 instances which aren't in a driver which appear to be broken due to this at first glance, resulting in 11 config variables whose specified values appear to be ignored. Bug here: https://bugs.launchpad.net/nova/+bug/1354403 Matt [1] https://review.openstack.org/#/c/104145/14/nova/virt/vmwareapi/vmware_images.py -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev