On 09/18/2015 11:01 AM, John Griffith wrote:
On Fri, Sep 18, 2015 at 9:06 AM, Chris Friesen <chris.frie...@windriver.com <mailto:chris.frie...@windriver.com>> wrote: On 09/18/2015 06:57 AM, Eric Harney wrote: On 09/17/2015 06:06 PM, John Griffith wrote: Having the "global conf" settings intermixed with the backend sections caused a number of issues when we first started working on this. That's part of why we require the "self.configuration" usage all over in the drivers. Each driver instantiation is it's own independent entity. Yes, each driver instantiation is independent, but that would still be the case if these settings inherited values set in [DEFAULT] when they aren't set in the backend section. Agreed. If I explicitly set something in the [DEFAULT] section, that should carry through and apply to all the backends unless overridden in the backend-specific section.
Bottom line "yes", ideally in the case of drivers we would check global/default setting, and then override it if something was provided in the driver specific setting, or if the driver itself set a different default. That seems like the right way to be doing it anyway. I've looked at that a bit this morning, the issue is that currently we don't even pass any of those higher level conf settings in to the drivers init methods anywhere. Need to figure out how to change that, then it should be a relatively simple fix.
Actually, I think it should be slightly different. If I set a variable in the global/default section of the config file, then that should override any defaults in the code for a driver.
So the order of descending precedence would go: 1) setting specified in driver-specific section of config file 2) setting specified in global/default section of config file 3) setting specified in driver-specific code 4) setting specified in global/default code (not sure if this exists) Chris __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
