Open Stack

On 09/18/2015 01:01 PM, John Griffith wrote:
> On Fri, Sep 18, 2015 at 9:06 AM, Chris Friesen <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.
>>
>> Chris
>>
>>
> Meh I don't know about the "have to modify the code", the config file works
> you just need to add that line to your driver section and configure the
> backend correctly.
> 

My point is that there doesn't seem to be a justification for "you just
need to add that line to your driver section", which seems to counter
what most people's expectation would be.

People can and do fail to do that, because they assume that [DEFAULT]
settings are treated as defaults.

To help people who make that assumption, yes, you have to modify the
code, because the code supplies a default value that you cannot supply
in the same way via config files.

> Regardless, I see your point (but I still certainly don't agree that it's
> "blatantly wrong").
> 

You can substitute "very confusing" for "blatantly wrong" but I think
those are about the same thing when talking about usability issues with
how to configure a service.

Look at options like:
 - strict_ssh_host_key_policy
 - sio_verify_server_certificate
 - driver_ssl_cert_verify

All of these default to False, and if turned on, enable protections
against MITM attacks.  All of them also fail to turn on for the relevant
drivers if set in [DEFAULT].  These should, if set in DEFAULT when using
multi-backend, issue a warning so the admin knows that they are not
getting the intended security guarantees.  Instead, nothing happens and
Cinder and the storage works.  Confusion is dangerous.

> 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.
> 

What I was getting at earlier though, is that I'm not really sure there
is a simple fix.  It may be simple to change the behavior to more
predictable behavior, but doing that in a way that doesn't introduce
upgrade problems for deployments relying on the current defaults seems
difficult to me.