7:58 a.m.
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?
Thanks in advance,
Yeela
8:32 a.m.
Am 25.06.2014 15:58, schrieb Yeela Kaplan:
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?
Thanks in advance,
Yeela
I never looked into this, but as I read this
I have to shout out: this is a bad practice!
you should not just comment out old config and write
new config to the same file!
you should instead implement a proper rotation
algorithm, because you can than easily fall back
onto older configuration, plus you just got
your configuration in a simple version control system.
additional drawback from commenting stuff out:
imagine a setup with lots and lots of changes, you'll
need soon to strip some of the commented stuff out
of the file completly, because it will grow and grow.
in short: maintainability
please rotate config files, everywhere, so do not
apply this bad practice from libvirt conf, instead
fix libvirt conf.
thanks
--
Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator
Mittwald CM Service GmbH & Co. KG
Königsberger Straße 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Geschäftsführer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
8:48 a.m.
----- Original Message -----
From: "Sven Kieske" <S.Kieske(a)mittwald.de>
To: devel(a)ovirt.org
Sent: Wednesday, June 25, 2014 5:32:47 PM
Subject: Re: [ovirt-devel] multipath configuration
Am 25.06.2014 15:58, schrieb Yeela Kaplan:
> 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?
>
> Thanks in advance,
> Yeela
I never looked into this, but as I read this
I have to shout out: this is a bad practice!
you should not just comment out old config and write
new config to the same file!
you should instead implement a proper rotation
algorithm, because you can than easily fall back
onto older configuration, plus you just got
your configuration in a simple version control system.
How do you suggest to rotate configuration files?
Can you give an example project which does this right?
additional drawback from commenting stuff out:
imagine a setup with lots and lots of changes, you'll
need soon to strip some of the commented stuff out
of the file completly, because it will grow and grow.
in short: maintainability
please rotate config files, everywhere, so do not
apply this bad practice from libvirt conf, instead
fix libvirt conf.
thanks
--
Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator
Mittwald CM Service GmbH & Co. KG
Königsberger Straße 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Geschäftsführer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
9 a.m.
----- Original Message -----
From: "Nir Soffer" <nsoffer(a)redhat.com>
To: "Sven Kieske" <S.Kieske(a)mittwald.de>
Cc: devel(a)ovirt.org
Sent: Wednesday, June 25, 2014 4:48:40 PM
Subject: Re: [ovirt-devel] multipath configuration
----- Original Message -----
> From: "Sven Kieske" <S.Kieske(a)mittwald.de>
> To: devel(a)ovirt.org
> Sent: Wednesday, June 25, 2014 5:32:47 PM
> Subject: Re: [ovirt-devel] multipath configuration
>
> Am 25.06.2014 15:58, schrieb Yeela Kaplan:
> > 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?
> >
> > Thanks in advance,
> > Yeela
>
>
> I never looked into this, but as I read this
> I have to shout out: this is a bad practice!
>
> you should not just comment out old config and write
> new config to the same file!
>
> you should instead implement a proper rotation
> algorithm, because you can than easily fall back
> onto older configuration, plus you just got
> your configuration in a simple version control system.
How do you suggest to rotate configuration files?
Can you give an example project which does this right?
A cleaner way for doing this would be using augeas [1] (especially in
the libvirt configuration case). I don't know what's its current status
of support for the multipath configuration.
Anyway if we want to pursue the current method I think that parsing,
commenting and editing multipath.conf automatically is harder than
libvirt.conf (e.g. it contains sections, etc.)
[1] http://augeas.net
--
Federico
9:24 a.m.
Yes, in general augeas can be a solution to this, but I
also don't know about it's state regarding multipath support
but it could be worth investigating.
Am 25.06.2014 17:00, schrieb Federico Simoncelli:
A cleaner way for doing this would be using augeas [1] (especially
in
the libvirt configuration case). I don't know what's its current status
of support for the multipath configuration.
Anyway if we want to pursue the current method I think that parsing,
commenting and editing multipath.conf automatically is harder than
libvirt.conf (e.g. it contains sections, etc.)
[1] http://augeas.net
--
Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator
Mittwald CM Service GmbH & Co. KG
Königsberger Straße 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Geschäftsführer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
5:56 a.m.
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.
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.
We've taken the comment-out approach for libvirtd.conf, logrotate etc.,
but I must admit that moving that saving a copy of the original file is
simpler and cleaner. Note that we do not need to rotate more than one
file. On upgrade, we should overwrite our version of the multipath.conf
with our new favorite version. The original version should be kept just
in case we want to uninstall Vdsm and revert to the original.
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?
Dan.
7:24 a.m.
configfile.py was written as a utility to manage operations
vdsm does on config files. handling stuff like ovirt node persistence
and selinux management.
Consider using this for multipath. Currently it comments
and removes comments since it had to be backward compatible with
old code. I have no objection (can't speak for others though) to
replacing it's functionality with rotating[1]. It would have to be
modified to support multipth's sections.
This would effect libvirt.con, qemu.conf, qemu-sanlock.conf and others[2]
Thanks,
Mooli.
[1] we would have to think about upgrading from one method to the other:
one solution could be to remove vdsm's comments and then rotate.
[2] for a full list see configurator.py:LibvirtModuleConfigure.FILES
----- Original Message -----
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.
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.
We've taken the comment-out approach for libvirtd.conf, logrotate etc.,
but I must admit that moving that saving a copy of the original file is
simpler and cleaner. Note that we do not need to rotate more than one
file. On upgrade, we should overwrite our version of the multipath.conf
with our new favorite version. The original version should be kept just
in case we want to uninstall Vdsm and revert to the original.
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?
Dan.
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
6:03 a.m.
----- Original Message -----
From: "Dan Kenigsberg" <danken(a)redhat.com>
To: "Yeela Kaplan" <ykaplan(a)redhat.com>
Cc: devel(a)ovirt.org, "Federico Simoncelli" <fsimonce(a)redhat.com>,
"Allon Mureinik" <amureini(a)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.
--
Federico
6:12 a.m.
----- Original Message -----
From: "Federico Simoncelli" <fsimonce(a)redhat.com>
To: "Dan Kenigsberg" <danken(a)redhat.com>
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>
> To: "Yeela Kaplan" <ykaplan(a)redhat.com>
> Cc: devel(a)ovirt.org, "Federico Simoncelli" <fsimonce(a)redhat.com>,
"Allon
> Mureinik" <amureini(a)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
6:57 a.m.
----- Original Message -----
From: "Nir Soffer" <nsoffer(a)redhat.com>
To: "Federico Simoncelli" <fsimonce(a)redhat.com>
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>
> To: "Dan Kenigsberg" <danken(a)redhat.com>
> 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>
> > To: "Yeela Kaplan" <ykaplan(a)redhat.com>
> > Cc: devel(a)ovirt.org, "Federico Simoncelli"
<fsimonce(a)redhat.com>, "Allon
> > Mureinik" <amureini(a)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.
>
> 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?
+1
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
7:10 a.m.
----- Original Message -----
From: "Antoni Segura Puimedon" <asegurap(a)redhat.com>
To: "Nir Soffer" <nsoffer(a)redhat.com>
Cc: "Federico Simoncelli" <fsimonce(a)redhat.com>, 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>
> To: "Federico Simoncelli" <fsimonce(a)redhat.com>
> 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>
> > To: "Dan Kenigsberg" <danken(a)redhat.com>
> > 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>
> > > To: "Yeela Kaplan" <ykaplan(a)redhat.com>
> > > Cc: devel(a)ovirt.org, "Federico Simoncelli"
<fsimonce(a)redhat.com>,
> > > "Allon
> > > Mureinik" <amureini(a)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.
--
Federico
7:19 a.m.
----- Original Message -----
From: "Federico Simoncelli" <fsimonce(a)redhat.com>
To: "Antoni Segura Puimedon" <asegurap(a)redhat.com>
Cc: "Nir Soffer" <nsoffer(a)redhat.com>, devel(a)ovirt.org
Sent: Friday, June 27, 2014 3:10:51 PM
Subject: Re: [ovirt-devel] multipath configuration
----- Original Message -----
> From: "Antoni Segura Puimedon" <asegurap(a)redhat.com>
> To: "Nir Soffer" <nsoffer(a)redhat.com>
> Cc: "Federico Simoncelli" <fsimonce(a)redhat.com>, 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>
> > To: "Federico Simoncelli" <fsimonce(a)redhat.com>
> > 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>
> > > To: "Dan Kenigsberg" <danken(a)redhat.com>
> > > 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>
> > > > To: "Yeela Kaplan" <ykaplan(a)redhat.com>
> > > > Cc: devel(a)ovirt.org, "Federico Simoncelli"
<fsimonce(a)redhat.com>,
> > > > "Allon
> > > > Mureinik" <amureini(a)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
7:25 a.m.
----- Original Message -----
From: "Antoni Segura Puimedon" <asegurap(a)redhat.com>
To: "Federico Simoncelli" <fsimonce(a)redhat.com>
Cc: "Nir Soffer" <nsoffer(a)redhat.com>, devel(a)ovirt.org
Sent: Friday, June 27, 2014 3:19:38 PM
Subject: Re: [ovirt-devel] multipath configuration
----- Original Message -----
> From: "Federico Simoncelli" <fsimonce(a)redhat.com>
> To: "Antoni Segura Puimedon" <asegurap(a)redhat.com>
> Cc: "Nir Soffer" <nsoffer(a)redhat.com>, devel(a)ovirt.org
> Sent: Friday, June 27, 2014 3:10:51 PM
> Subject: Re: [ovirt-devel] multipath configuration
>
>
> 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" :(
Nice, we should file an RFE even though I hardly believe that we can
wait it to reach all the distros.
--
Federico
7:55 a.m.
Am 27.06.2014 15:25, schrieb Federico Simoncelli:
Nice, we should file an RFE even though I hardly believe that we
can
wait it to reach all the distros.
+1
--
Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator
Mittwald CM Service GmbH & Co. KG
Königsberger Straße 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Geschäftsführer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
8:25 a.m.
On Fri, Jun 27, 2014 at 09:10:51AM -0400, Federico Simoncelli wrote:
----- Original Message -----
> From: "Antoni Segura Puimedon" <asegurap(a)redhat.com>
> To: "Nir Soffer" <nsoffer(a)redhat.com>
> Cc: "Federico Simoncelli" <fsimonce(a)redhat.com>, 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>
> > To: "Federico Simoncelli" <fsimonce(a)redhat.com>
> > 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>
> > > To: "Dan Kenigsberg" <danken(a)redhat.com>
> > > 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>
> > > > To: "Yeela Kaplan" <ykaplan(a)redhat.com>
> > > > Cc: devel(a)ovirt.org, "Federico Simoncelli"
<fsimonce(a)redhat.com>,
> > > > "Allon
> > > > Mureinik" <amureini(a)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.
3588
days inactive
3590
days old
14 comments
7 participants
participants (7)
-
Antoni Segura Puimedon -
Dan Kenigsberg -
Federico Simoncelli -
Mooli Tayer -
Nir Soffer -
Sven Kieske -
Yeela Kaplan