[ovirt-devel] multipath configuration

[Antoni Segura Puimedon]

----- Original Message -----
> From: "Federico Simoncelli" <fsimonce at redhat.com>
> To: "Antoni Segura Puimedon" <asegurap at redhat.com>
> Cc: "Nir Soffer" <nsoffer at redhat.com>, devel at ovirt.org
> Sent: Friday, June 27, 2014 3:10:51 PM
> Subject: Re: [ovirt-devel] multipath configuration
> 
> ----- Original Message -----
> > From: "Antoni Segura Puimedon" <asegurap at redhat.com>
> > To: "Nir Soffer" <nsoffer at redhat.com>
> > Cc: "Federico Simoncelli" <fsimonce at redhat.com>, devel at ovirt.org
> > Sent: Friday, June 27, 2014 2:57:59 PM
> > Subject: Re: [ovirt-devel] multipath configuration
> > 
> > ----- Original Message -----
> > > From: "Nir Soffer" <nsoffer at redhat.com>
> > > To: "Federico Simoncelli" <fsimonce at redhat.com>
> > > Cc: devel at ovirt.org
> > > Sent: Friday, June 27, 2014 2:12:50 PM
> > > Subject: Re: [ovirt-devel] multipath configuration
> > > 
> > > ----- 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
> > 
> > vdsm, the less the service file does the more likely we can have the same
> > systemd unit file for all the distros without init common adapters.
> 
> We need this check somewhere whether it is in the service file (maybe
> using ExecStartPre for cleanliness) or in the vdsm daemon the problem of
> supporting multiple distro remains.
> 
> > > > 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.
> > 
> > Sound good
> > 
> > > > 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.
> > 
> > Isn't it really necessary? When we do upgrades we know which configuration
> > we need in the new version and we could just replace the .conf file and
> > leave
> > the original .conf.rpmsave untouched. What am I missing?
> 
> If in a new version X we need to configure a new parameter in multipath.conf
> (that wasn't configured before X) we should be able to set it with vdsm-tool
> without replacing the entire file (that may contain customized entries).
> Same for a parameter that we may want to change.

I was afraid the answer would be this one of "customized entries". It would be
nice if there was a multipath.conf.d where we could have vdsm.conf and the
admin could customize "whatever.conf" :(

> 
> --
> Federico
>