4:24 p.m.
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[1]. It would have to be
modified to support multipth's sections.
This would effect libvirt.con, qemu.conf, qemu-sanlock.conf and others[2]
Thanks,
Mooli.
[1] 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.
[2] 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
installation.
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
approach.
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
elaborate?
Dan.
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel