Leaving only vdsm-devel.
----- Original Message -----
> From: "Ryan Harper" <ry...@us.ibm.com>
> To: "Alon Bar-Lev" <alo...@redhat.com>
> Cc: "Dan Kenigsberg" <dan...@redhat.com>, "engine-devel"
> <engine-de...@ovirt.org>, "VDSM Project Development"
> <email@example.com>, "users" <us...@ovirt.org>
> Sent: Wednesday, November 28, 2012 11:22:59 PM
> Subject: Re: [Engine-devel] [vdsm] [ATTENTION] vdsm-bootstrap/host deployment
> > >
> > > > 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 the this very idea; I was looking for a way to enable
> 'debugging' mode as well as a way to programatically collect
> info (which could include host stats, guest stats, logs and any core
> Certainly in such a scenario, being able to enable/disable varous
> features of a debugging mode could include whether to enable core
> as well as where to save them on the host.
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.
vdsm-devel mailing list