Re: [ovirt-devel] multipath configuration

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

> > 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 _______________________________________________ Devel mailing list Devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/devel