On Fri, Jun 27, 2014 at 09:10:51AM -0400, Federico Simoncelli wrote: > ----- Original Message ----- > > From: "Antoni Segura Puimedon" <asegu...@redhat.com> > > To: "Nir Soffer" <nsof...@redhat.com> > > Cc: "Federico Simoncelli" <fsimo...@redhat.com>, devel@ovirt.org > > Sent: Friday, June 27, 2014 2:57:59 PM > > Subject: Re: [ovirt-devel] multipath configuration > > > > ----- Original Message ----- > > > From: "Nir Soffer" <nsof...@redhat.com> > > > To: "Federico Simoncelli" <fsimo...@redhat.com> > > > Cc: devel@ovirt.org > > > Sent: Friday, June 27, 2014 2:12:50 PM > > > Subject: Re: [ovirt-devel] multipath configuration > > > > > > ----- Original Message ----- > > > > From: "Federico Simoncelli" <fsimo...@redhat.com> > > > > To: "Dan Kenigsberg" <dan...@redhat.com> > > > > Cc: devel@ovirt.org > > > > Sent: Friday, June 27, 2014 3:03:56 PM > > > > Subject: Re: [ovirt-devel] multipath configuration > > > > > > > > ----- Original Message ----- > > > > > From: "Dan Kenigsberg" <dan...@redhat.com> > > > > > To: "Yeela Kaplan" <ykap...@redhat.com> > > > > > Cc: devel@ovirt.org, "Federico Simoncelli" <fsimo...@redhat.com>, > > > > > "Allon > > > > > Mureinik" <amure...@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.
task_check_is_configured calls `vdsm-tool is-configured` on service start in all distros. Extending is-configured to check multipath.conf is the natural thing to do. > > > > > 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 2me2 - I like small steps. > > > > > > 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? Just for the record: we should not steal the rpmsave extension, but use .vdsmsave or whatever. > > 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. _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel