[ovirt-devel] multipath configuration
mtayer at redhat.com
Thu Jun 26 13:24:15 UTC 2014
configfile.py was written as a utility to manage operations
vdsm does on config files. handling stuff like ovirt node persistence
and selinux management.
Consider using this for multipath. Currently it comments
and removes comments since it had to be backward compatible with
old code. I have no objection (can't speak for others though) to
replacing it's functionality with rotating. It would have to be
modified to support multipth's sections.
This would effect libvirt.con, qemu.conf, qemu-sanlock.conf and others
 we would have to think about upgrading from one method to the other:
one solution could be to remove vdsm's comments and then rotate.
 for a full list see configurator.py:LibvirtModuleConfigure.FILES
----- Original Message -----
> On Wed, Jun 25, 2014 at 09:58:52AM -0400, Yeela Kaplan wrote:
> > Hi,
> > Currently multipath.conf is being rotated each time we reconfigure it.
> > We'd like to change the behaviour for multipath.conf so that current
> > configuration will be commented out
> > and we'd stop rotating (in the same manner as libvirt conf works today).
> > Does anybody have any comment for/ against?
> I'd like to present the problem in a slightly different light.
> It is highly uncommon for a service to mangle the configuration files
> of another service. Administrator do not expect they complain (e.g. Bug
> 1076531 - vdsm overwrites multipath.conf at every startup)
> We used to have this problem with libvirtd.conf, but it has been
> aleviated by moving the configuration to vdsm-tool, which should do its
> thing when asked by the local admin, or once during automatic host
> We should do this with multipath.conf, too. And we should deprecate the
> RHEV trademark that is stuck there while at it.
> The only question is how. Should we place the old configuration in a
> rotated file (a-la .rpmsave) or should we place them in the same file,
> completely commented out.
> We've taken the comment-out approach for libvirtd.conf, logrotate etc.,
> but I must admit that moving that saving a copy of the original file is
> simpler and cleaner. Note that we do not need to rotate more than one
> file. On upgrade, we should overwrite our version of the multipath.conf
> with our new favorite version. The original version should be kept just
> in case we want to uninstall Vdsm and revert to the original.
> Another question is how we should write the configuration file: should
> we do it as simple text, or should we take a smarter augeas-based
> In my opinion, as long as we want to dump our own conf file, there is
> not motivation for augeas. If, on the other hand, we would like to
> replace only a section of the file, it should come into play.
> Is this what you have in mind for multipath.conf, Federico? Could you
> Devel mailing list
> Devel at ovirt.org
More information about the Devel