[Users] [Engine-devel] [vdsm] [ATTENTION] vdsm-bootstrap/host deployment (pre-3.2)

[Ryan Harper]

* Alon Bar-Lev <alonbl at redhat.com> [2012-11-28 14:47]:
> 
> 
> ----- Original Message -----
> > From: "Dan Kenigsberg" <danken at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > Cc: "VDSM Project Development" <vdsm-devel at lists.fedorahosted.org>, "engine-devel" <engine-devel at ovirt.org>, "users"
> > <users at 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 at 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...

I very much like this idea.  There was a thread a while back
discussing[1] the this very idea; I was looking for a way to enable
'debugging' mode as well as a way to programatically collect debugging
info (which could include host stats, guest stats, logs and any core
files).

Certainly in such a scenario, being able to enable/disable varous
features of a debugging mode could include whether to enable core dumps
as well as where to save them on the host.


1. http://comments.gmane.org/gmane.comp.emulators.ovirt.vdsm.devel/1387


-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh at us.ibm.com