action #6148
closedShow dependency failure in UI
Added by nadvornik about 9 years ago. Updated about 9 years ago.
Description
Currently UI shows no difference between job not started because of dependencies and incomplete job.
This should be fixed by adding new job result.
Files
| current.png (13.7 KB) current.png | nadvornik, 2015-02-19 14:40 | ||
| proposal.png (15.3 KB) proposal.png | nadvornik, 2015-02-19 14:41 | ||
| proposal-no-incomplete.png (13.4 KB) proposal-no-incomplete.png | ancorgs, 2015-02-20 11:47 |
Updated by nadvornik about 9 years ago
- File current.png current.png added
- File proposal.png proposal.png added
After the discussion https://github.com/os-autoinst/openQA/pull/183 I think that job states needs a bigger change.
This is the current situation:
CANCELLED is not final state, job_restart on CANCELLED job changes it back to SCHEDULED. Therefore seting result of cancelled job does not make sense.
job_restart on other states (except SCHEDULED) duplicates the job.
My proposal:
There will be two final states, CANCELLED for job that were never assigned to a worker and DONE for jobs assigned to a worker, that have logs, start time, etc.
Then we can use result in both these states to store details. More values can be added as needed.
job_restart will always duplicate the job and eventually tell the worker to cancel the current one.
Updated by lnussel about 9 years ago
Somehow I still can't get used to the idea of using result for
CANCELLED. It's not a strong opposition but somehow it feels dirty.
A cancelled job doesn't actually have any result after all. We'd
store a reason rather than a result. Same argument applies to having
OBSOLETED and CANCELLED_BY_USER as 'result' for DONE.
I'm still in fond of using a table for job history/journal and
document events like 'cancelled by user' or 'obsoleted by iso xyz'
as free form text there.
But then INCOMPLETE is actually not a result either. hmm...
Do we actually need formal information about the reason why jobs didn't produce a result in any overview page?
Updated by ancorgs about 9 years ago
I also dislike mixing states with cancellation reasons. If we forget about historical reasons and try to look at the problem with fresh eyes, this is probably more straightforward
There is no such thing as "incomplete" in this proposal. Can somebody remind me why is relevant/different from, for example, cancelled_by_user? I honestly forgot.
Updated by coolo about 9 years ago
The operator wants to ignore jobs that were obsoleted by new builds, but wants to restart tests were the worker crashed or went down. This is clearly not a state but a result though.
Updated by ancorgs about 9 years ago
Ah, ok. Then add "incomplete" to the list of results in the image I attached and I think it makes sense and covers all the situations.
Updated by nadvornik about 9 years ago
In my proposal there is a clear difference between job that were assigned to a worker and jobs that were cancelled before running. I think we should keep this separation as it simplifies the code in scheduler and ui.
Using separate fields for result and cancelled_by is possible but IMHO it is redundant, various cancellation reasons are a kind of result.
Updated by ancorgs about 9 years ago
I know the proposal it's already implemented. Fine. But I'm still curious. Just for the record: why is that separation relevant for the code in the scheduler and the UI?
Updated by nadvornik about 9 years ago
For example, the discussion at https://github.com/os-autoinst/openQA/pull/183 started because of setting start and end times for job that never ran.
Updated by coolo about 9 years ago
- Category set to 122
- Target version changed from Sprint 14 to Sprint 15
Updated by coolo about 9 years ago
- Parent task deleted (
#4600)
decoupling from mm, it has not really much to do with it - it's a general problem
Updated by coolo about 9 years ago
will you continue working on this? The states are now in database and the filtering kind of works, but the way the reason is displayed in result view is very suboptimal
Updated by nadvornik about 9 years ago
yes,
it needs at least show parent result on test result page and improve job list.
Updated by coolo about 9 years ago
for this sprint I would concentrate on the result page only and ignore the job list. What's much more important IMO is upstreaming the chains and the MM tests, so we can see the problems live and gather experiences. So far you're the only one to have these problems.