Open Stack

On Fri, Sep 18, 2015 at 11:31 AM, Chris Friesen <chris.friesen at 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.friesen at windriver.com
>> <mailto:chris.friesen at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150918/3cb5ceac/attachment.html>