On 09/18/2015 01:01 PM, John Griffith wrote: > On Fri, Sep 18, 2015 at 9:06 AM, Chris Friesen <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. >> >> 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. __________________________________________________________________________ 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