5:59 a.m.
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?
Yoav K
7:13 a.m.
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=f1c3...
7:31 a.m.
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(a)redhat.com>
To: "Yoav Kleinberger" <ykleinbe(a)redhat.com>
Cc: devel(a)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=f1c3...
8:08 a.m.
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.
8:50 a.m.
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(a)redhat.com>
To: "Yoav Kleinberger" <ykleinbe(a)redhat.com>
Cc: devel(a)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.
9:17 a.m.
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(a)redhat.com>
To: "Yoav Kleinberger" <ykleinbe(a)redhat.com>
Cc: devel(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
9:20 a.m.
Maor can you please explain? I'm not familiar with this audit log
----- Original Message -----
From: "Maor Lipchuk" <mlipchuk(a)redhat.com>
To: "Yoav Kleinberger" <ykleinbe(a)redhat.com>, "Dan Kenigsberg"
<danken(a)redhat.com>
Cc: devel(a)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(a)redhat.com>
To: "Yoav Kleinberger" <ykleinbe(a)redhat.com>
Cc: devel(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
9:26 a.m.
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(a)redhat.com>
To: "Yoav Kleinberger" <ykleinbe(a)redhat.com>, "Dan Kenigsberg"
<danken(a)redhat.com>
Cc: devel(a)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(a)redhat.com>
> To: "Yoav Kleinberger" <ykleinbe(a)redhat.com>
> Cc: devel(a)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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
9:43 a.m.
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(a)redhat.com>
To: "Yoav Kleinberger" <ykleinbe(a)redhat.com>
Cc: "Dan Kenigsberg" <danken(a)redhat.com>, devel(a)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(a)redhat.com>
To: "Yoav Kleinberger" <ykleinbe(a)redhat.com>, "Dan Kenigsberg"
<danken(a)redhat.com>
Cc: devel(a)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(a)redhat.com>
> To: "Yoav Kleinberger" <ykleinbe(a)redhat.com>
> Cc: devel(a)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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
noon
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(a)redhat.com>
To: "Yoav Kleinberger" <ykleinbe(a)redhat.com>
Cc: "Dan Kenigsberg" <danken(a)redhat.com>, devel(a)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(a)redhat.com>
> To: "Yoav Kleinberger" <ykleinbe(a)redhat.com>, "Dan
Kenigsberg" <danken(a)redhat.com>
> Cc: devel(a)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(a)redhat.com>
>> To: "Yoav Kleinberger" <ykleinbe(a)redhat.com>
>> Cc: devel(a)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(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
1:47 a.m.
On May 13, 2014, at 19:00 , Maor Lipchuk <mlipchuk(a)redhat.com> wrote:
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}
Why do you want to invent a new message when there is one already? And rather put more
useful info there
Pretty much as Dan suggests, though I'd be careful about direct passthrough of stack
trace to UI.
I'd rather invest into review of these messages and adding the info we think can be
useful, it may be libvirt's error code for some cases, but very often something else.
The flows are complex and a particular message for one vdsm verb doesn't necessarily
make sense on its own.
Thanks,
michal
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(a)redhat.com>
> To: "Yoav Kleinberger" <ykleinbe(a)redhat.com>
> Cc: "Dan Kenigsberg" <danken(a)redhat.com>, devel(a)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(a)redhat.com>
>> To: "Yoav Kleinberger" <ykleinbe(a)redhat.com>, "Dan
Kenigsberg" <danken(a)redhat.com>
>> Cc: devel(a)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(a)redhat.com>
>>> To: "Yoav Kleinberger" <ykleinbe(a)redhat.com>
>>> Cc: devel(a)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(a)ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>
>
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
4013
days inactive
4014
days old
10 comments
4 participants
participants (4)
-
Dan Kenigsberg -
Maor Lipchuk -
Michal Skrivanek -
Yoav Kleinberger