Keep user multipath configuration upon upgrade

[benjamreis]

All files matchin custom.*\.conf will be kept upon upgrade.

See: xapi-project/sm#600

[stormi]

Would be better with a word of context: since PR xapi-project/sm#600, there is text in the multipath/custom.conf file which says:

# Changes made to this file will not be overwritten by future system updates.
# They will also be retained through system upgrades to newer releases.

And it was agreed upon that we would make it become true in the installer.

The current PR does this.

[stormi]

Here we need to choose between either saving the whole directory, or just custom.conf. Saving the whole directory may be a perk when/if vendors start taking the habit of dropping a file of theirs into this directory when needed.

On the other hand, if we want to keep the liberty of packaging configuration files in /etc/multipath/conf.d, then it may be safer to just add etc/multipath/conf.d/custom.conf to the list.

[ydirson]

I'd say vendors should deploy such files using a RPM anyway, no?

[ydirson]

what about saving custom*.conf to give users more flexibility and still avoid issues with proper RPMs?

[benjamreis]

Hi, we reduced to a specific regex to only save custom config files to avoid conflic with RPM installed files.

What do you guys think? :)

[alexbrett]

From the sm PR, it seems we state in multipath.conf:

# For custom multipath configuration, create a separate .conf file in the
# /etc/multipath/conf.d/ directory.

However, this change only preserves files that match custom*.conf, which is not quite the same. If people have found the custom.conf file they may see the text in that which says it'll be preserved, but if they have only looked at multipath.conf, and then created e.g. /etc/multipath/conf.d/my_new_file.conf, they might still expect that to be preserved based on the text in multipath.conf.

As such it seems to me the text in multipath.conf should either say e.g. create a separate .conf file in the /etc/multipath/conf.d/ directory. Note filenames beginning with the name custom, will be preserved during system updates/upgrades (or something worded slightly better to that effect), or we should preserve everything, otherwise we risk confusing people?

[ydirson]

@alexbrett the question would be, would it be valid for eg. an OEM to install files there though a RPM? That's a typical use for the "conf.d" idiom, besides letting user modifications not interfere with system updates.
If we consider that for this particular case it makes no sense (I'm myself not familiar enough with the matter), then fine. But we could also decide to restrict the liberty given in multipath.conf (which incidently people may already have used, making this path maybe harder to choose...)

[ydirson]

What do you decide? Would you rather simply keep *.conf?

[ydirson]

@alexbrett the question would be, would it be valid for eg. an OEM to install files there though a RPM? That's a typical use for the "conf.d" idiom, besides letting user modifications not interfere with system updates. If we consider that for this particular case it makes no sense (I'm myself not familiar enough with the matter), then fine. But we could also decide to restrict the liberty given in multipath.conf (which incidently people may already have used, making this path maybe harder to choose...)

Can we make this go forward with this?