10:45 p.m.
----- Original Message -----
From: "Dan Kenigsberg" <danken(a)redhat.com>
To: "Alon Bar-Lev" <alonbl(a)redhat.com>
Cc: "VDSM Project Development" <vdsm-devel(a)lists.fedorahosted.org>,
"engine-devel" <engine-devel(a)ovirt.org>, "users"
<users(a)ovirt.org>
Sent: Wednesday, November 28, 2012 10:39:42 PM
Subject: Re: [vdsm] [ATTENTION] vdsm-bootstrap/host deployment (pre-3.2)
On Wed, Nov 28, 2012 at 02:57:17PM -0500, Alon Bar-Lev wrote:
>
> > > No... we need it as compatibility with older engines...
> > > We keep minimum changes there for legacy, until end-of-life.
> >
> > Is there an EoL statement for oVirt-3.1?
> > We can make sure that oVirt-3.2's vdsm installs properly with
> > ovirt-3.1's vdsm-bootstrap, or even require that Engine must be
> > upgraded
> > to ovirt-3.2 before upgrading any of the hosts. Is it too harsh
> > to
> > our
> > vast install base? users(a)ovirt.org, please chime in!
> >
>
> I tried to find such, but the more I dig I find that we need to
> support old legacy.
Why, exactly? Fedora gives no such guarntees (heck, I'm stuck with an
unupgradable F16). Should we be any better than our (currently
single)
platform?
We should start and detach from specific distro procedures.
> > > > >
> > > > > * legacy-removed: change machine width core file
> > > > > # echo /var/lib/vdsm/core > /proc/sys/kernel/core_pattern
> > > >
> > > > Yeah, qemu-kvm and libvirtd are much more stable than in the
> > > > old
> > > > days,
> > > > but wouldn't we want to keep a means to collect the corpses
> > > > of
> > > > dead
> > > > processes from hypervisors? It has helped us nail down nasty
> > > > bugs,
> > > > even
> > > > in Python.
> > >
> > > It does not mean it should be at /var/lib/vdsm ... :)
> >
> > I don't get the joke :-(. If you mind the location, we can think
> > of
> > somewhere else to put the core dumps. Would it be hard to
> > reinstate a
> > parallel feature in otopi?
>
> I usually do not make any jokes...
> A global system setting should not go into package specific
> location.
> Usually core dumps are off by default, I like this approach as
> unattended system may fast consume all disk space because of
> dumps.
If a host fills up with dumps so quickly, it's a sign that it should
not
be used for production, and that someone should look into the cores.
(P.S. we have a logrotate rule for them in vdsm)
There should be a vdsm-debug-aids (or similar) to perform such changes.
Again, I don't think vdsm should (by default) modify any system width parameter such
as this.
But I will happy to hear more views.
> If sysadmin manually enables dumps, he may do this at a location of
> his own choice.
Note that we've just swapped hats: you're arguing for letting a local
admin log in and mess with system configuration, and I'm for keeping
a
centralized feature for storing and collecting core dumps.
As problems like crashes are investigated per case and reproduction scenario.
But again, I may be wrong and we should have VDSM API command to start/stop storing dumps
and manage this via its master...
> If we want to automatically enable dumps I guess it should go to
> /var/lib/core or similar.