QA (public) » openQA Project (public)

We could simply

for page in exception not_found; do
    ln -s $(rpm -ql perl-Mojolicious | grep debug.html.ep) /etc/openqa/templates/${page}.html.ep
done

to show useful error pages in case we don't see security issues with potential leaking of internal config in the log files, e.g. for osd we could do this at least.

https://github.com/os-autoinst/openQA/pull/831 and https://github.com/os-autoinst/openQA/issues/842 have been provided already.

It looks like it would be nice if we provide a PR to upstream Mojolicious to have the route view in a separate template file or helper function so that we could render this as part of a custom page including the nice colors but w/o the debug content.

This is very bad style to mix user roles. You're not a 'user of openqa' - you're a developer. Users don't care why the app crashed - they only want it working. The log is for the developer then. Don't mix production mode and development mode - they are different modes for a reason.

coolo wrote:

This is very bad style to mix user roles.

That's your opinion.

Please see the goal of the "user" in the user story: "… to get the issues I encounter fixed fast".
An alternative might be for us to have better monitoring of the errors in the logfiles and react on them.
My idea was that a user could have some more information than just "this did not work" so that he could provide a helpful bug report. What Martchus provided as a proposal in https://github.com/os-autoinst/openQA/pull/831 is a custom template with a pointer where to provide bug reports. We could also not provide any details but just ask the user to write a bug report, tell which steps he did and exactly at which time (for developers to be able to crosscheck logfiles with a timestamp). WDYT?

I guess I have to agree here although my original intention was something else, especially regarding the internal server error pages. But I can agree to track this with better monitoring of log file content instead.