action #13196
closedhttps://openqa.opensuse.org/admin/needles does not seem to work
Added by okurz over 8 years ago. Updated about 8 years ago.
0%
Description
observation¶
going to https://openqa.opensuse.org/admin/needles the pull down menues "limit use" and "limit match" don't seem to have an effect. At least the difference between both are hard to understand. Also, trying to delete needles using the dialog did not seem to have any effect.
problem¶
Tests missing, nobody used it for long and it broke and nobody noticed?
suggestion¶
- first add tests
- then fix and improve
- add doc or help text on web UI
Updated by mkittler about 8 years ago
When using the filters the following error message is logged:
SQL::Abstract::puke(): [SQL::Abstract::ANON] Fatal: unexpected operator '>=' with undef operand at /home/martchus/repos/openQA/script/../lib/OpenQA/WebAPI/Controller/Admin/Needle.pm line 78
The cause is likely in Needle.pm (lines 34 to 77).
Updated by okurz about 8 years ago
another case of 'errors should be shown to the user not hidden in logfiles'
Updated by coolo about 8 years ago
and what is the user supposed to do with that SQL::Abstract? And btw, there are tests for this page - t/ui/21-admin-needles.t
Updated by okurz about 8 years ago
coolo wrote:
there are tests for this page - t/ui/21-admin-needles.t
yes but still it could be tests are missing.
Updated by okurz about 8 years ago
- Assignee set to dheidler
- Priority changed from Normal to Urgent
As we are seeing performance issues because of too many needles being loaded and evaluated and we will be running out of space pretty soon we should have access to this tool. The problem on a production database dump is actually that the server times out working on the response any time you change the values in the pull down menues (as can be seen in the browser error display).
Updated by okurz about 8 years ago
- Copied to coordination #13950: [epic][gsoc] Needle ENV tag assistant added
Updated by mkittler about 8 years ago
I looked into this again. The error message from my last comment only occurs when using SQLite and hence is not the cause of the issue.
Indeed the connection is just timing out. I wasn't able to reproduce a timeout, but very long response times. Not sure how to improve it except increasing the timeout to make it at least work again.
There might be tests missing, but I guess it is hard to add tests for the timeout problem.
Updated by mkittler about 8 years ago
- Status changed from New to Feedback
I still can not reproduce timeouts, just very long loading times and hence the UI seems 'to do nothing'.
I see two options to improve the situation:
Do the filtering completely on the client side. This works already very well for the text search. The initial loading time would remain long, but filtering would be responsive again. When using this option we must ensure that the initial request doesn't time out. Not sure where timeouts are specified and as I already said, I can not reproduce them. This way we would also get rid of the problems with SQLite.
Set filter by default. This would decrease the initial loading time but filtering would still be slow. When using this option there should be some indication that filtering is ongoing. Otherwise it looks like the filter does nothing (scheinbar).
Personally, I'd vote for the first option. Any further ideas? What do you think?
Updated by mkittler about 8 years ago
- Assignee changed from dheidler to mkittler
Updated by mkittler about 8 years ago
- Status changed from Feedback to In Progress
Coolo proposed use of 'Server-side processing': https://datatables.net/examples/data_sources/server_side.html
Asking the server is actually what we already do for filtering and those request are very slow. But if we would also do the paging on the server side (as shown in the demo linked above) the problem should be solved. So I'm following this approach now.
Updated by okurz@suse.de about 8 years ago
You learned your vocabulary well :-)
IMHO the simple things first, I.e. whatever is easier, I assume option 2. Could you maybe add a simple progress indicator by default, e.g. from fontawesome there is this pretty standard turning circles. Then, when the request finishes, the symbol is replaced/hidden. Does this work?
Updated by mkittler about 8 years ago
The server-side paging is not one of the options I initially proposed. I use the progress indication provided by DataTable rather than font awesome.
This should work already: https://github.com/os-autoinst/openQA/pull/918
Updated by mkittler about 8 years ago
PR has been deployed. Since I don't have admin access I can not verify whether it is working in production.
Updated by okurz about 8 years ago
It's not yet working in production on openqa.opensuse.org or something else broke. I get the page https://openqa.opensuse.org/response with the content "Internal server error
If you believe this is a bug you can open an issue."
Also https://openqa.suse.de/admin/needles still feels like the old one.
Oh, trying again on openqa.opensuse.org worked now.
Looking for the corresponding error message in o3:/var/log/openqa shows
[Fri Oct 7 15:41:25 2016] [31177:debug] GET "/response"
[Fri Oct 7 15:41:25 2016] [31177:debug] Routing to controller "OpenQA::WebAPI::Controller::Session" and action "response"
[Fri Oct 7 15:41:25 2016] [31177:error] Not an OpenID message at /usr/share/openqa/script/../lib/OpenQA/WebAPI/Auth/OpenID.pm line 116.
[Fri Oct 7 15:41:25 2016] [31177:debug] Template "exception.production.html.ep" not found
[Fri Oct 7 15:41:25 2016] [31177:debug] Rendering template "exception.html.ep"
[Fri Oct 7 15:41:25 2016] [31177:debug] Rendering template "layouts/error.html.ep"
[Fri Oct 7 15:41:25 2016] [31177:debug] 500 Internal Server Error (0.0362s, 27.624/s)
so something is working but not perfect somehow. I would set this to Feedback and see with time but IMHO you should try to think about point 3 of the suggestion regarding doc/help.
Updated by coolo about 8 years ago
the crash in /response is hardly Marius' fault
Updated by okurz@suse.de about 8 years ago
/response is only triggered on internal faults so I assumed the issues to be not fixed. I didn't blame Marius and definitely the Situation improved. I don't see a reason for opening another Ticket but we could if you prefer
Updated by coolo about 8 years ago
- Status changed from In Progress to Resolved
/response is triggered on login - I guess you just logged in to access this route. This is a completely different problem. If you can reproduce it, file an issue.
Updated by okurz about 8 years ago
You don't want some kind of help text, e.g. on hover?