[Freeipa-devel] user-friendly 'IPA internal error' message

[Petr Spacek]

On 23.4.2015 14:10, Simo Sorce wrote:
> On Thu, 2015-04-23 at 07:28 +0200, Jan Cholasta wrote:
>> Dne 22.4.2015 v 15:32 Simo Sorce napsal(a):
>>> On Wed, 2015-04-22 at 09:59 +0200, Jan Cholasta wrote:
>>>> Dne 22.4.2015 v 09:05 Petr Spacek napsal(a):
>>>>> Hello,
>>>>>
>>>>> looking at freeipa-users list, following kind of conversation is quite common:
>>>>>
>>>>> user: 'IPA reports an internal error, what should I do?'
>>>>> dev: 'see HTTPd error log on the IPA server'
>>>>> user: 'what server?'
>>>>> dev: 'enable debugging on client and see which server was contacted'
>>>>>
>>>>>
>>>>> Can we make InternalError more useful and eliminate this kind of ping-pong?
>>>>>
>>>>> Looking at sources:
>>>>> $ git grep 'class .*InternalError'
>>>>> ipalib/errors.py:class InternalError(PublicError):
>>>>> ipalib/errors.py:class ServerInternalError(PublicError):
>>>>>
>>>>> $ git grep ServerInternalError
>>>>> ipalib/errors.py:class ServerInternalError(PublicError):
>>>>> ipalib/errors.py:    >>> raise ServerInternalError(server='https://localhost')
>>>>> ipalib/errors.py:    ServerInternalError: an internal error has occurred on
>>>>> server at 'https://localhost'
>>>>>
>>>>> Apparently somebody was thinking about it in the past but ServerInternalError
>>>>> is not used anywhere.
>>>>>
>>>>> How hard would it be to translate InternalError on client side to
>>>>> ServerInternalError with appropriate server name?
>>>>>
>>>>> Can we extend InternalError with text like this?
>>>>> 'See httpd error log on server %s for more details.'
>>>>>
>>>>> Does it make sense? Should I open a ticket about this?
>>>>>
>>>>
>>>> It's a good idea.
>>>>
>>>> On a related note, I would also like the server to send tracebacks to
>>>> the client if debugging is enabled on the server.
>>>
>>> I am not too hot on this idea, unless there is a specific switch to
>>> allow sending tracebacks (default to off).
>>
>> Emphasis on "if debugging is enabled".
> 
> If I enable debugging on the server, I still may not want all clients to
> receive backtraces, especially if I am trying to resolve a problem in
> production.

Good point, I agree with Simo on this. It should be a separate switch.

-- 
Petr^2 Spacek