master
Teyras 9 years ago
parent 8ca5e20f5b
commit 21319a5264

@ -51,7 +51,8 @@ Configuration of the job which is passed to worker is generated from two parts:
Final configuration for worker is computer generated from those two configs. Final configuration for worker is computer generated from those two configs.
* **Configuration example** #### Configuration example
``` ```
--- # only one document which contains job, aka. list of tasks and some general infos --- # only one document which contains job, aka. list of tasks and some general infos
submission: # information about this particular submission submission: # information about this particular submission
@ -108,21 +109,8 @@ tasks:
parallel: false # time and memory limits are merged from all potential processes/threads parallel: false # time and memory limits are merged from all potential processes/threads
disk-usage: 5 # MB disk-usage: 5 # MB
environ-variable: environ-variable:
- var: ISOLATE_BOX ISOLATE_BOX: "/box"
value: "/box" ISOLATE_TMP: "/tmp"
- var: ISOLATE_TMP
value: "/tmp"
results:
exitcode: 0
status: RE # two letter status code
exitsig: 1
time: 5 # in seconds
time-wall: 5 # in seconds
memory: 50000 # in KB
killed:
message: "Time limit exceeded" # status message
...
``` ```
### Parameters And Results ### Parameters And Results
@ -135,6 +123,20 @@ Input parameters have two sources, some defaults are present in the configuratio
Parameters are only read by the tasks (they can be used in task parameters). Some simple syntax needs to be used for evaluation of parameter expressions -- e.g., ("${params.tests[1].memoryLimit}"). _Parameters should be stored in worker's global namespace. Task configuration can make references to this structure. Validity should be checked before executing first task from the job. In this structure is only writable section "results" - here are written achieved memory and time limits of each task. Whole structure is send to WebApp with all logs._ Parameters are only read by the tasks (they can be used in task parameters). Some simple syntax needs to be used for evaluation of parameter expressions -- e.g., ("${params.tests[1].memoryLimit}"). _Parameters should be stored in worker's global namespace. Task configuration can make references to this structure. Validity should be checked before executing first task from the job. In this structure is only writable section "results" - here are written achieved memory and time limits of each task. Whole structure is send to WebApp with all logs._
_**TODO:** analysis required -- how complex expressions do we really need_ _**TODO:** analysis required -- how complex expressions do we really need_
#### Example result file
```
results:
exitcode: 0
status: RE # two letter status code
exitsig: 1
time: 5 # in seconds
time-wall: 5 # in seconds
memory: 50000 # in KB
killed:
message: "Time limit exceeded" # status message
```
### Logs ### Logs
There is one general (mandatory) log, where the job progress is logged. Each row corresponds to one task and it holds only the task name, task exit code (or some other indication whether the task ended OK or not), and optionally things like consumed memory and time. There is one general (mandatory) log, where the job progress is logged. Each row corresponds to one task and it holds only the task name, task exit code (or some other indication whether the task ended OK or not), and optionally things like consumed memory and time.

Loading…
Cancel
Save