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

Ryan Harper ryanh at us.ibm.com
Wed Nov 28 21:59:29 UTC 2012


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

After many of years handling crappy bug reports that don't include the
data needed for debugging, such as log files and other settings, and
spending weeks going back and forth with the submitter on collecting
what and where and how to collect it,  I'm confident that having
something that can programtically enable debugging on-demand and
providing a way to collect the relative data (logs, cores, etc) would
make a dramatic improvement when handing these support issues.

I'm also a firm believer in lowering the barriers for consumption.

IIUC, a side-band tool is going to require additional
configuration/authenitication; and will ultimately need to access the
API anyhow to determine various information about the specific VM.

With that in mind, why wouldn't we want to look at a first-class debug
API mode which can be used remotely and programatically?

A better question is, what are the drawbacks to having it in-band?

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



More information about the vdsm-devel mailing list