Re: [PATCH 3/6] libmultipath: add overrides section to multipath.conf

[Sebastian Herbszt <herbszt@gmx.de>]

Christophe Varoqui wrote:
> I have no strong opinion on this one : I feel like the complexity of the
> parameter inheritance system is already quite complicated ... but this
> addition of a new layer would likely and safely be ignored by users who
> don't need it. Those who need it are surely ready to pay the price.
> 
> Does someone have objection to my applying this patch ?
> 
> Best regards,
> Christophe
> 
> 
> 
> On Wed, Nov 19, 2014 at 7:17 AM, Benjamin Marzinski <bmarzins@redhat.com>
> wrote:
> 
> > Sometimes users want to be able to set a configuration value for all their
> > devices (for instance, they may want all devices to set no_path_retry to
> > fail). The builtin device configurations make this tricky, since users need
> > to change each device configuration individually. To avoid that, this patch
> > adds a new section to multipath.conf, "overrides".  This section has all of
> > the attributes that are in both the devices and defaults section.
> > Attributes set in the overrides section have a higher priority that those
> > in the devices section. With this section added, the multipath
> > configuration order now goes:
> >
> > multipaths > overrides > devices > defaults
> >
> > I also made want_user_friendly_names print out where the configuration came
> > from, and I made made select_hwhandler and select_selector always strdup
> > the string, instead of only on the defaults.  Since multipathd will update
> > the device strings from the kernel anyway, the old way just added
> > complexity without saving any memory.
> >
> > To store the overrides configuration, I used a hwentry structure. We may
> > want to make a new overrides structure, so that we set any of the defaults
> > values in overrides.  That way, users could skip using defaults and just
> > use overrides if they wanted. However, this would take some additional
> > changes to make sure that all the defaults options can undefined, which
> > they can't currently be.
> >

What's the current precedence of the configuration sections? I don't think
the manual pages document this (sufficiently). I guess the precedence is:

multipaths > devices > defaults

But where do the built-in device configurations fit in? It seems those are
somehow merged with the user supplied entries from the configuration file.

Would changing the precedence to

multipaths > devices > defaults > built-in devices

fix the issue at hand?

Sebastian