[ovirt-devel] improving VDSM error reporting

[Yoav Kleinberger]

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.
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. 

----- 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 3:13:16 PM
Subject: Re: [ovirt-devel] improving VDSM error reporting

On Tue, May 13, 2014 at 06:59:33AM -0400, Yoav Kleinberger wrote:
> Hi all,
> 
> This idea was born from this bug: https://bugzilla.redhat.com/730619 
> 
> If, for example, creating a new storage domain 
> fails because there's no space left, the user gets:
> 
>             "Error creating a storage domain"
> 
> which is not very helpful, since the real problem (no space) is not reported.
> 
>             "Error creating a storage domain"
> 
>             [i] No space left on device
> 
> Where [i] is some widget the user can open to see details, 
> or other element the UX team find acceptable.
> 
> Nir Soffer and I believe a good solution is the following:
> 
> 1. Currently VDSM sends a dictionary  {'status': {'code': code, 'message': msg}}. 
>    The code is some number that Engine recognizes and has a localized
>    message for. The msg parameter is ignored by Engine, and contains
>    a default, not informative, string like "Error creating a storage domain"
> 
> 2. We suggest adding a new key to this dictionary, call it "details", 
>    which will contain the string representation of the actual exception thrown
>    in Python (in this case, OSError with the string "[Errno 28] No space left
>    on device"
> 
> 3. The Engine will look for this key, and display the string inside a "details" 
>    section which will be added to the current dialog box. The user gets the
>    usual error indication, but has a small "details" icon, which he can click
>    to see more information.
> 
> The advantages are:
> 1. Simple to implement
> 2. Will improve the situation for any error thrown from Python 
>    - the user will get a clearer message.
> 3. New VDSM with old Engine is not a problem, the engine will not 
>    look for this key at all
> 4. New Engine with old VDSM is also easy to handle: the engine will not 
>    display "details" if this key is absent.
> 
> Disadvatage is that the "details" will be non-localized, but this is 
> natural for technical details. 
> 
> Why not use the existing "msg" field? because a new engine with an old VDSM
> will display uninformative, duplicate messages for all errors (the current msg
> field is simply a duplicate of the engine error name).
> 
> What do you think?

As far as I recall, Engine used to log the textual "message" somewhere
(though not very prominently). What is the benefit of adding the
"details" element over filling "message" with meaningful information,
and making sure that Engine lets the strong-hearted users look into it?

In some cases, 'message' already carries meaningful information (under
some definition of meaningful, Cf. [1]), and I'd be pleased to see it
exposed (if it isn't already).

Dan.

[1] http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=blob;f=vdsm/virt/vm.py;h=f1c36f87d4b492bc7a078d77b0e4036c378cdc74;hb=fc976ea73b305f0f0d93dccae3b0f95701ee273b#l2961