[ovirt-devel] multipath configuration

[Nir Soffer]

----- Original Message -----
> From: "Federico Simoncelli" <fsimonce at redhat.com>
> To: "Dan Kenigsberg" <danken at redhat.com>
> Cc: devel at ovirt.org
> Sent: Friday, June 27, 2014 3:03:56 PM
> Subject: Re: [ovirt-devel] multipath configuration
> 
> ----- Original Message -----
> > From: "Dan Kenigsberg" <danken at redhat.com>
> > To: "Yeela Kaplan" <ykaplan at redhat.com>
> > Cc: devel at ovirt.org, "Federico Simoncelli" <fsimonce at redhat.com>, "Allon
> > Mureinik" <amureini at redhat.com>
> > Sent: Thursday, June 26, 2014 1:56:32 PM
> > Subject: Re: multipath configuration
> > 
> > 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.
> 
> +2
> 
> > 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.
> 
> That is an all-or-nothing approach. VDSM probably relies only on few
> config entries. One thing is for sure, VDSM should be able to detect if
> the relevant multipath configs are not properly set and refuse to start.
> For the discovery of these values (read) we could use augeas.
> 
> If the sysadmin already uses the correct parameters we may not even
> touch the file at all.
> 
> > 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?
> 
> My approach would be:
> 
> 1. vdsm (or its service file) should discover if multipath.conf is
>    configured properly and eventually refuse to start
> 
> 2. vdsm-tool being able to configure multipath.conf (only the required
>    entries), this would be very much similar to what we do with libvirt.
>    If we want to use augeas it is just an implementation detail.
> 
> 3. vdsm-tool being able to install/replace entire multipath.conf in
>    case it wasn't already configured (or in case you want to force the
>    default strict configuration, e.g. during initial automated
>    deployment?)
> 
> It is always polite to backup the previous config in .rpmsave.
> 
> Point 1 implicitly allows the sysadmin to change multipath.conf, which
> could be harder to support (he could use conflicting entries) but anyway
> it gives the flexibility to customize multipath.conf if needed (which
> is something that we already have).
> 
> Point 1 and 2 seem just "read" and "write" of the same parameters,
> which could be cleanly done with augeas (if the support is good).
> 
> We could begin with points 1 and 3 (easier to tackle) and re-evaluate
> 2 later.
> Anyway we have an hard requirement for point 2 during upgrades when we
> need to configure a new key/section or edit an old one.

+1