<div dir="ltr">Hi,<div><br></div><div>the precedence chain is :</div><div><br></div><div>multipaths > user-specified per-device > default per-device > default</div><div><br></div><div>The issue adressed by Ben's patch would not be solved by your suggestion, as far as I can see. The proposed override section is just a way not repeat a per-device in each multipath (insane) or device (tedious) section.</div><div><br></div><div>I personnaly implement the tedious device configuration using a configuration manager (shameless plug: opensvc). But I can see the value of an override section for those not using a such config management tools.</div><div><br></div><div>Best regards,</div><div>Christophe Varoqui</div><div>OpenSVC</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 12, 2015 at 12:15 AM, Sebastian Herbszt <span dir="ltr"><<a href="mailto:herbszt@gmx.de" target="_blank">herbszt@gmx.de</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">Christophe Varoqui wrote:<br>
> I have no strong opinion on this one : I feel like the complexity of the<br>
> parameter inheritance system is already quite complicated ... but this<br>
> addition of a new layer would likely and safely be ignored by users who<br>
> don't need it. Those who need it are surely ready to pay the price.<br>
><br>
> Does someone have objection to my applying this patch ?<br>
><br>
> Best regards,<br>
> Christophe<br>
><br>
><br>
><br>
> On Wed, Nov 19, 2014 at 7:17 AM, Benjamin Marzinski <<a href="mailto:bmarzins@redhat.com">bmarzins@redhat.com</a>><br>
> wrote:<br>
><br>
> > Sometimes users want to be able to set a configuration value for all their<br>
> > devices (for instance, they may want all devices to set no_path_retry to<br>
> > fail). The builtin device configurations make this tricky, since users need<br>
> > to change each device configuration individually. To avoid that, this patch<br>
> > adds a new section to multipath.conf, "overrides".  This section has all of<br>
> > the attributes that are in both the devices and defaults section.<br>
> > Attributes set in the overrides section have a higher priority that those<br>
> > in the devices section. With this section added, the multipath<br>
> > configuration order now goes:<br>
> ><br>
> > multipaths > overrides > devices > defaults<br>
> ><br>
> > I also made want_user_friendly_names print out where the configuration came<br>
> > from, and I made made select_hwhandler and select_selector always strdup<br>
> > the string, instead of only on the defaults.  Since multipathd will update<br>
> > the device strings from the kernel anyway, the old way just added<br>
> > complexity without saving any memory.<br>
> ><br>
> > To store the overrides configuration, I used a hwentry structure. We may<br>
> > want to make a new overrides structure, so that we set any of the defaults<br>
> > values in overrides.  That way, users could skip using defaults and just<br>
> > use overrides if they wanted. However, this would take some additional<br>
> > changes to make sure that all the defaults options can undefined, which<br>
> > they can't currently be.<br>
> ><br>
<br>
</div></div>What's the current precedence of the configuration sections? I don't think<br>
the manual pages document this (sufficiently). I guess the precedence is:<br>
<br>
multipaths > devices > defaults<br>
<br>
But where do the built-in device configurations fit in? It seems those are<br>
somehow merged with the user supplied entries from the configuration file.<br>
<br>
Would changing the precedence to<br>
<br>
multipaths > devices > defaults > built-in devices<br>
<br>
fix the issue at hand?<br>
<span class="HOEnZb"><font color="#888888"><br>
Sebastian<br>
</font></span></blockquote></div><br></div>