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"
> <vdsm-devel@lists.fedorahosted.org>, "users" <us...@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.
> 
> 
> 1.
> 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
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to