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@xxxxxx> wrote:
What's the current precedence of the configuration sections? I don't thinkChristophe 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@xxxxxxxxxx>
> 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.
> >
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
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
