Improved error handling in LAVA dispatcher

Registered by Paul Larson on 2011-05-30

Headline:
LAVA dispatcher now tries to make as much progress in the test run as possible despite failures of previous actions, and keeps track of which actions passed or failed rather than just whether the whole test run completed or not.

User stories:
As a job submitter, I want to run my job as far as possible so that I know what the root cause if failed and see the test result and logs even if the job can not finish as normal.

Blueprint information

Status:
Complete
Approver:
Paul Larson
Priority:
Medium
Drafter:
Paul Larson
Direction:
Approved
Assignee:
Spring Zhang
Definition:
Approved
Series goal:
Accepted for linaro-11.11
Implementation:
Implemented
Milestone target:
milestone icon 2011.07
Started by
Spring Zhang on 2011-06-16
Completed by
Paul Larson on 2011-07-21

Sprints

Whiteboard

(?)

Work Items

Work items:
[qzhang] Map which failures types are critical, and which can be continued in the spec: DONE
[qzhang] Log errors whenever a failure of any type happens: DONE
[qzhang] Enhance exception and error class definition, provide enough information of exception: DONE
[qzhang] Pass on all non-critical errors, so that the error is logged, but execution of the next action continues: DONE
[qzhang] Skip to results submission on all critical failures: DONE
[qzhang] When the job fails to complete (due to critical error or timeout), save and submit metadata showing which lava action (including test name) was active when the failure occurred: DONE
[qzhang] Handle errors in results submission by logging, and by trying to submit a simple 'lava' result only: DONE
[qzhang] Add Android part error handler: DONE

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.