On Fri, Sep 18, 2015 at 11:31 AM, Chris Friesen <chris.frie...@windriver.com > wrote:
> 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. > Hmm... well, on the bright side that might be easier to implement at least :). I guess I don't agree on the meaning of "DEFAULT", to me a "DEFAULT" section means, "these are the defaults if you don't specify something else", no? Your proposal seems really counter-intuitive to me. Anyway, I've come up with a way to read the DEFAULT section of CONF on init in the driver so that's good. The trick now though is when there's a difference in value between the driver section and the default section; knowing what was set explicitly and what wasn't. In other words I don't have any way of knowing for sure if the setting came from reading in the defaults in the declaration options or if it was explicitly set in the config file. Still working on it, but curious if anybody might know how to get around this little sticking point. Thanks, John > 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 > >
__________________________________________________________________________ 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
