----- Original Message -----
> From: "Ryan Harper" <ry...@us.ibm.com>
> To: "Alon Bar-Lev" <alo...@redhat.com>
> Cc: "Ryan Harper" <ry...@us.ibm.com>, "Dan Kenigsberg" <dan...@redhat.com>, 
> "VDSM Project Development"
> <vdsm-devel@lists.fedorahosted.org>
> Sent: Wednesday, November 28, 2012 11:59:29 PM
> Subject: Re: [Engine-devel] [vdsm] [ATTENTION] vdsm-bootstrap/host deployment 
> (pre-3.2)
> 
> * Alon Bar-Lev <alo...@redhat.com> [2012-11-28 15:33]:
> > 
> > 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.
> 
> 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?

You took it too far... :)

The problem with *THE* API is that there is a contract for forward/backward 
stability.

From my experience having first class API for production is good as long as it 
is not being dragged for other purposes.

You can always have second class API for debugging.

The advantage of this is that the second class API is much more flexible and 
can serve "strange"/none standard (not fully compliant entities.

It does not mean you don't reuse your code and/or authentication...

Having said that... I think that most of this can be done via simple SSH and 
proper command-line tool at host side, which is very simple to use and 
implement.

But I did not intend to (re)open the discussion about the debug API :)

Regrds,
Alon
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to