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

Itamar Heim iheim at redhat.com
Thu Nov 29 00:37:48 UTC 2012


On 11/28/2012 04:59 PM, Ryan Harper wrote:
> * 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?
>

isn't this what the ovirt-log-collector is for?



More information about the vdsm-devel mailing list