Improved error handling in LAVA dispatcher
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:
-
2011.07
- Started by
- Spring Zhang
- Completed by
- Paul Larson
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.
