[dm-devel] [PATCH 3/6] libmultipath: add overrides section to multipath.conf

[Christophe Varoqui]

Hi,

the precedence chain is :

multipaths > user-specified per-device > default per-device > default

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.

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.

Best regards,
Christophe Varoqui
OpenSVC

On Mon, Jan 12, 2015 at 12:15 AM, Sebastian Herbszt <herbszt at gmx.de> wrote:

> 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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20150112/325b20ec/attachment.htm>