Open Stack

On Fri, Sep 18, 2015 at 12:32 PM, Chris Friesen <chris.friesen at windriver.com
> wrote:

> On 09/18/2015 12:11 PM, John Griffith wrote:
>
>>
>>
>> On Fri, Sep 18, 2015 at 11:31 AM, Chris Friesen <
>> chris.friesen at windriver.com
>> <mailto: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>
>>         <mailto: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.
>>
>
> That's what I proposed.
>
> If you specify anything in the driver-specific portion of the config file,
> that takes priority over everything.  If you specify something in the
> DEFAULT portion of the config file, then that takes priority over the
> in-code defaults.  If you specify a default value in the driver-specific
> code, that takes priority over any defaults specified in the global/generic
> code.
>
>
> 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
>
​Ahh... ok, yeah; sorry, I interpreted that differently when I read it.
Thanks for clarifying.

So the good news is we most definitely agree there, and that I've got
something that gets us at least part way there.  Now, to just figure out
how to determine if the value in the driver section was set explicitly or
is just parsing out the default value in the opt declaration.

Thanks!!
John​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150918/3976fc54/attachment.html>