<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 18, 2015 at 2:46 PM, Eric Harney <span dir="ltr"><<a href="mailto:eharney@redhat.com" target="_blank">eharney@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 09/18/2015 03:33 PM, John Griffith wrote:<br>
> On Fri, Sep 18, 2015 at 12:52 PM, Eric Harney <<a href="mailto:eharney@redhat.com">eharney@redhat.com</a>> wrote:<br>
><br>
>> On 09/18/2015 01:01 PM, John Griffith wrote:<br>
>>> On Fri, Sep 18, 2015 at 9:06 AM, Chris Friesen <<br>
>> <a href="mailto:chris.friesen@windriver.com">chris.friesen@windriver.com</a>><br>
>>> wrote:<br>
>>><br>
>>>> On 09/18/2015 06:57 AM, Eric Harney wrote:<br>
>>>><br>
>>>>> On 09/17/2015 06:06 PM, John Griffith wrote:<br>
>>>>><br>
>>>><br>
>>>> Having the "global conf" settings intermixed with the backend sections<br>
>>>>>> caused a number of issues when we first started working on this.<br>
>> That's<br>
>>>>>> part of why we require the "self.configuration" usage all over in the<br>
>>>>>> drivers. Each driver instantiation is it's own independent entity.<br>
>>>>>><br>
>>>>>><br>
>>>>> Yes, each driver instantiation is independent, but that would still be<br>
>>>>> the case if these settings inherited values set in [DEFAULT] when they<br>
>>>>> aren't set in the backend section.<br>
>>>>><br>
>>>><br>
>>>> Agreed. If I explicitly set something in the [DEFAULT] section, that<br>
>>>> should carry through and apply to all the backends unless overridden in<br>
>> the<br>
>>>> backend-specific section.<br>
>>>><br>
>>>> Chris<br>
>>>><br>
>>>><br>
>>> Meh I don't know about the "have to modify the code", the config file<br>
>> works<br>
>>> you just need to add that line to your driver section and configure the<br>
>>> backend correctly.<br>
>>><br>
>><br>
>> My point is that there doesn't seem to be a justification for "you just<br>
>> need to add that line to your driver section", which seems to counter<br>
>> what most people's expectation would be.<br>
>><br>
> There certainly is, I don't want to force the same options against all<br>
> backends. Perfect example is the issues with some distros in the past that<br>
> DID use global settings and stomp over any driver; which in turn broke<br>
> those that weren't compatible with that conf setting even though in the<br>
> driver section they overrode it.<br>
><br>
><br>
>><br>
>> People can and do fail to do that, because they assume that [DEFAULT]<br>
>> settings are treated as defaults.<br>
>><br>
><br>
> Bad assumption, we should probably document this until we fix it (making a<br>
> very large assumption that we'll ever agree on how to fix it).<br>
><br>
>><br>
>> To help people who make that assumption, yes, you have to modify the<br>
>> code, because the code supplies a default value that you cannot supply<br>
>> in the same way via config files.<br>
>><br>
><br>
> Or you could just fill out the config file properly:<br>
> [lvm-1]<br>
> iscsi_helper = lioadm<br>
><br>
> I didn't have to modify any code.<br>
> <br>
><br>
><br>
<br>
</div></div>In the use case I was describing, I'm shipping a package, as a<br>
distribution, with a default configuration file. The deployer (not me)<br>
is the only one that knows about config sections that they want for<br>
multi-backend. I don't think it's fair to require them to fill out<br>
things like iscsi_helper, because there is only one correct value for<br>
iscsi_helper on the platform I support, and defaulting to a different<br>
one is not useful.<br></blockquote><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">Ahh, ok; so back to one of the problems with OpenStack IMO, too many options/choices. Regardless though yes I can see where you're coming from now. In your case there is only one supported/correct option here so that creates a problem.</div></div><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline"></div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The fact that we don't inherit [DEFAULT] settings means that it is not<br>
possible for me to ship a package with the correct defaults without<br>
changing the hard-coded default value, in the code, to customize it for<br>
my platform. I want to set iscsi_helper = lioadm in a configuration file<br>
and have that be the default for any enabled_backend.<br></blockquote><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">Yes, now I see the case you're referring to, thanks! This is why I tried to grab you on IRC to make sure I actually followed what your particular case was.</div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
<br>
>><br>
>>> Regardless, I see your point (but I still certainly don't agree that it's<br>
>>> "blatantly wrong").<br>
>>><br>
>><br>
>> You can substitute "very confusing" for "blatantly wrong" but I think<br>
>> those are about the same thing when talking about usability issues with<br>
>> how to configure a service.<br>
>><br>
><br>
> Fair enough. Call it whatever you like.<br>
><br>
><br>
>><br>
>> Look at options like:<br>
>> - strict_ssh_host_key_policy<br>
>> - sio_verify_server_certificate<br>
>> - driver_ssl_cert_verify<br>
><br>
><br>
>> All of these default to False, and if turned on, enable protections<br>
>> against MITM attacks. All of them also fail to turn on for the relevant<br>
>> drivers if set in [DEFAULT]. These should, if set in DEFAULT when using<br>
>> multi-backend, issue a warning so the admin knows that they are not<br>
>> getting the intended security guarantees. Instead, nothing happens and<br>
>> Cinder and the storage works. Confusion is dangerous.<br>
>><br>
><br>
> Yeah, so is crappy documentation lack of understanding.<br>
><br>
><br>
<br>
</span>I can't make my customers read documentation and test them for<br>
understanding. I can make software that's more robust and less prone to<br>
misuse. Warning people with "hey, you're using multi-backend and have<br>
set this security-related option in a section where it will never have<br>
an effect in your deployment" is one way to do this that we could do today.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">I get it now; thanks.</div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
>><br>
>>> Bottom line "yes", ideally in the case of drivers we would check<br>
>>> global/default setting, and then override it if something was provided in<br>
>>> the driver specific setting, or if the driver itself set a different<br>
>>> default. That seems like the right way to be doing it anyway. I've<br>
>> looked<br>
>>> at that a bit this morning, the issue is that currently we don't even<br>
>> pass<br>
>>> any of those higher level conf settings in to the drivers init methods<br>
>>> anywhere. Need to figure out how to change that, then it should be a<br>
>>> relatively simple fix.<br>
>>><br>
>><br>
>> What I was getting at earlier though, is that I'm not really sure there<br>
>> is a simple fix. It may be simple to change the behavior to more<br>
>> predictable behavior, but doing that in a way that doesn't introduce<br>
>> upgrade problems for deployments relying on the current defaults seems<br>
>> difficult to me.<br>
>><br>
> Agreed, but honestly I'd like to at least try. Especially when people use<br>
> terms like "blatantly wrong" and "dangerous", kinda prompts one to think <br>
><br>
> that perhaps it should be looked at. If nothing else, we shouldn't have<br>
> driver settings in the DEFAULT section, we should just create a driver<br>
> section, but we still need to figure out how to deal with things outside of<br>
> the "general" section vs the backend stanza.<br>
><br>
<br>
</span>Yeah, it should be looked at, that's why I'm talking about all of this...<br>
<br>
Moving settings to a drivers section sounds like a good start but it<br>
doesn't fix the issue I'm talking about without also changing how the<br>
inheritance works.<br></blockquote><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">Right, the sort of thing you're talking about indeed needs more than that. As you may have already mentioned there's a more significant change needed to how how we parse / use config altogether.</div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> Also, I'd argue that the behavior your arguing for is MORE dangerous and<br>
> troublesome. The LIO being in the global CONF was a perfect example where<br>
> it broke third party devices on a specific distro because it assumed that<br>
> EVERYTHING on the system was using the lio methods and in that case you<br>
> really couldn't do anything but modify code.<br>
><br>
<br>
</span>I don't really know how to parse this, I was talking about dangerous<br>
software behavior, I think you're talking about dangerous code changes?<br>
<br>
When LIO originally landed, all we had was global conf, so I'm not sure<br>
what you're getting at. If the conf model was wrong for LIO, it was/is<br>
wrong for dozens of other driver-specific options too.<br>
<br>
If you're referring to <a href="https://bugs.launchpad.net/cinder/+bug/1400804" rel="noreferrer" target="_blank">https://bugs.launchpad.net/cinder/+bug/1400804</a> ,<br>
all I can really say about that is, yeah, that kind of thing was more<br>
likely to happen back then..? That seems orthogonal other than the fact<br>
that it's config-related code that I worked on once.<br></blockquote><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">Yes, that's one example of what I was considering in terms of the issues with just applying globals. Now that I understand your points a bit more clearly I understand this isn't quite the same thing.</div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I don't really follow what I'm supposed to conclude about my current<br>
proposal in that context...<br></blockquote><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">Nothing at this point :)</div></div><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline"></div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
> I've pinged you a number of times on IRC, maybe we can chat there a bit<br>
> real-time and see if we can work together on a solution?<br>
><br>
> Thanks,<br>
> John<br>
><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Sounds like a great topic for the Summit?</div><br></div></div>