From 28d35ef0a673c0b1dd83a8f25178e23dc30ffce9 Mon Sep 17 00:00:00 2001 From: Martin Polanka Date: Tue, 3 Jan 2017 10:54:14 +0100 Subject: [PATCH] Directories of job on worker --- Rewritten-docs.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Rewritten-docs.md b/Rewritten-docs.md index 8028dbf..5dfdb83 100644 --- a/Rewritten-docs.md +++ b/Rewritten-docs.md @@ -645,6 +645,8 @@ At this point we have worker with two internal parts listening one and execution Another division of tasks is by task-type field in configuration. This field can have four values: initiation, execution, evaluation and inner. All was discussed and described above in configuration analysis. What is important to worker is how to behave if execution of task with some particular type fails. There are two possible situations execution fails due to bad user solution or due to some internal error. If execution fails on internal error solution cannot be declared overally as failed. User should not be punished for bad configuration or some network error. This is where task types are usefull. Generally initiation, execution and evaluation are tasks which are somehow executing code which was given by users who submitted solution of exercise. If this kinds of tasks fail it is probably connected with bad user solution and can be evaluated. But if some inner task fails solution should be re-executed, in best case scenario on different worker. That is why if inner task fails it is sent back to broker which will reassign job to another worker. More on this subject should be discussed in broker assigning algorithms section. +There is also question about working directory or directories of job, which directories should be used and what for. There is one simple answer on this every job will have only one specified directory which will contain every file with which worker will work in the scope of whole job execution. This is of course nonsense there has to be some logical division. The least which must be done are two folders one for internal temporary files and second one for evaluation. The directory for temporary files is enough to comprehend all kind of internal work with filesystem but only one directory for whole evaluation is somehow not enough. Users solutions are downloaded in form of zip archives so why these should be present during execution or why the results and files which should be uploaded back to fileserver should be cherry picked from the one big directory? The answer is of course another logical division into subfolders. The solution which was chosen at the end is to have folders for downloaded archive, decompressed solution, evaluation directory in which user solution is executed and then folders for temporary files and for results and generally files which should be uploaded back to fileserver with solution results. This division proved to be flexible and detailed enough, everything is in logical units and where it is supposed to be which means that searching through this system should be easy. In addition solutions of users do not have access to unnecessary files which is better for overall security of whole ReCodEx. + @todo: maybe describe folders within execution and what they can be used for? @todo: how to solve problem with specific worker environment, mention internal job variables