Leaving only vdsm-devel.
----- Original Message -----
From: "Ryan Harper" ryanh@us.ibm.com To: "Alon Bar-Lev" alonbl@redhat.com Cc: "Dan Kenigsberg" danken@redhat.com, "engine-devel" engine-devel@ovirt.org, "VDSM Project Development" vdsm-devel@lists.fedorahosted.org, "users" users@ovirt.org Sent: Wednesday, November 28, 2012 11:22:59 PM Subject: Re: [Engine-devel] [vdsm] [ATTENTION] vdsm-bootstrap/host deployment (pre-3.2)
<snip>
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.
http://comments.gmane.org/gmane.comp.emulators.ovirt.vdsm.devel/1387
Yes, I read this, however, I am unsure that debug and low level collections should be implemented as in-band interface and not side-band.
Alon