Project

General

Profile

Actions

action #6148

closed

Show dependency failure in UI

Added by nadvornik about 9 years ago. Updated about 9 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Feature requests
Target version:
Start date:
2015-02-03
Due date:
% Done:

0%

Estimated time:

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

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:
current

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:
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.

Actions #2

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?

Actions #3

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
without-incomplete

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.

Actions #4

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.

Actions #5

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.

Actions #6

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.

Actions #7

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?

Actions #8

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.

Actions #9

Updated by coolo about 9 years ago

  • Category set to 122
  • Target version changed from Sprint 14 to Sprint 15
Actions #10

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

Actions #11

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

Actions #12

Updated by nadvornik about 9 years ago

yes,
it needs at least show parent result on test result page and improve job list.

Actions #13

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.

Actions #14

Updated by coolo about 9 years ago

  • Status changed from New to Resolved

then let's close this

Actions

Also available in: Atom PDF