[ovirt-devel] improving VDSM error reporting

[Maor Lipchuk]

The specific verb is not that relevant.
it's already being done when using FAILED_HOT_SET_NUMBER_OF_CPUS,
VDS_INITIALIZING, RUN_VM_FAILED or STORAGE_DOMAIN_ERROR (and more)

For general purposes we can use a new audit log such as this:
RETUNED_VDSM_ERROR_MESSAGE=The error message returned by VDSM was:
${ErrorMessage}

Regards,
Maor

On 05/13/2014 05:43 PM, Yoav Kleinberger wrote:
> the specific example was CreateStorageDomain, not ConnectStorageDomain. 
> but anyhow, the problem is a general one: add some more information to the errors that engine gets from VDSM, without doing too much work. Some of these errors my fit well into "events", but some will not.
> 
> ----- Original Message -----
> From: "Maor Lipchuk" <mlipchuk at redhat.com>
> To: "Yoav Kleinberger" <ykleinbe at redhat.com>
> Cc: "Dan Kenigsberg" <danken at redhat.com>, devel at ovirt.org
> Sent: Tuesday, May 13, 2014 5:26:32 PM
> Subject: Re: [ovirt-devel] improving VDSM error reporting
> 
> The audit logs are presented in the events tab in the GUI, usually we
> print an audit log when we succeed/fail to execute a command and usually
> it is  more verbal then the CDA messages (Which presented in the dialog
> boxes).
> 
> Since ConnectStorageDomain is a VDS command which runs in the execute
> phase maybe it is more fitting to add an event log describing the error
> in more details.
> 
> Regards,
> Maor
> 
> On 05/13/2014 05:20 PM, Yoav Kleinberger wrote:
>> Maor can you please explain? I'm not familiar with this audit log
>>
>> ----- Original Message -----
>> From: "Maor Lipchuk" <mlipchuk at redhat.com>
>> To: "Yoav Kleinberger" <ykleinbe at redhat.com>, "Dan Kenigsberg" <danken at redhat.com>
>> Cc: devel at ovirt.org
>> Sent: Tuesday, May 13, 2014 5:17:02 PM
>> Subject: Re: [ovirt-devel] improving VDSM error reporting
>>
>> I would like to suggest another solution,
>> Why not let the audit log present the extra error description.
>> VDSM can override the existing error message before returning it to the
>> engine with the extra data.
>>
>> that way you will not have to add  new attributes to the existing API,
>> and the dialog messages will still be localized.
>>
>> regards,
>> Maor
>>
>> On 05/13/2014 04:50 PM, Yoav Kleinberger wrote:
>>> well, we can add the python text, and the UX team will decide under what circumstances to display it. At least for some users it will add information.
>>>
>>> ----- Original Message -----
>>> From: "Dan Kenigsberg" <danken at redhat.com>
>>> To: "Yoav Kleinberger" <ykleinbe at redhat.com>
>>> Cc: devel at ovirt.org
>>> Sent: Tuesday, May 13, 2014 4:08:47 PM
>>> Subject: Re: [ovirt-devel] improving VDSM error reporting
>>>
>>> On Tue, May 13, 2014 at 08:31:16AM -0400, Yoav Kleinberger wrote:
>>>> Hi Dan,
>>>> A few points:
>>>>
>>>> 1. I explained the problem using the existing "message" field. An old VDSM will have the "meaningless" messages, and when working with a new engine they will be displayed to the user.
>>>
>>> As I have shown, "message" is not completely meaningless as it is
>>> (though it certainly does not add much information beyond the error
>>> code). I don't suspect that Engine would show the extra "details" to
>>> just any user. UX folks like to keep the GUI clean and tidy, so only
>>> experienced users with the right credentials would see them. In some
>>> (most) cases, "message" would add no information beyond the error code
>>> and its localized string. But as time passes, we can add more and more
>>> "meat" to the message.
>>>
>>>> 2. The patch you attached generates the message inside the code for a specific circumstance. However, I want to handle unexpected errors that fly out of the code in a generic way, without needing to understand each and every case. 
>>>
>>> unexpected errors end up with code error 16 and message 'Unexpected
>>> exception'. Personally, I'd love to replace this message with a
>>> meaningful traceback.
>>>
>>> Dan.
>>> _______________________________________________
>>> Devel mailing list
>>> Devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>
>