Re: [ovirt-devel] multipath configuration

From: "Antoni Segura Puimedon" <asegurap(a)redhat.com&gt; To: "Nir Soffer" <nsoffer(a)redhat.com&gt; Cc: "Federico Simoncelli" <fsimonce(a)redhat.com&gt;, devel(a)ovirt.org Sent: Friday, June 27, 2014 2:57:59 PM Subject: Re: [ovirt-devel] multipath configuration ----- Original Message ----- > From: "Nir Soffer" <nsoffer(a)redhat.com&gt; > To: "Federico Simoncelli" <fsimonce(a)redhat.com&gt; > Cc: devel(a)ovirt.org > Sent: Friday, June 27, 2014 2:12:50 PM > Subject: Re: [ovirt-devel] multipath configuration > > ----- Original Message ----- > > From: "Federico Simoncelli" <fsimonce(a)redhat.com&gt; > > To: "Dan Kenigsberg" <danken(a)redhat.com&gt; > > Cc: devel(a)ovirt.org > > Sent: Friday, June 27, 2014 3:03:56 PM > > Subject: Re: [ovirt-devel] multipath configuration > > > > ----- Original Message ----- > > > From: "Dan Kenigsberg" <danken(a)redhat.com&gt; > > > To: "Yeela Kaplan" <ykaplan(a)redhat.com&gt; > > > Cc: devel(a)ovirt.org, "Federico Simoncelli" <fsimonce(a)redhat.com&gt;, > > > "Allon > > > Mureinik" <amureini(a)redhat.com&gt; > > > 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.

> > 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?