**Web app** is main part of whole project for users. It provides nice user interface and is the only part, that interacts with outside world directly. **Web API** contains almost all logic of the app including _user management and authentication_, _storing and versioning files_ (with help of **File server**), _counting and assigning points_ to users etc. **Broker** is essential part of whole architecture and can be marked as single point of failure. It maintains list of available **Workers**, receives submissions from the **Web API** and routes them further and reports progress of evaluations back to the **Web app**. **Worker** securely runs each received job and evaluate it's results. **Monitor** resends evaluation progress messages to the **Web app** in order to be presented to users.
**Web app** is main part of whole project for users. It provides nice user interface and is the only part, that interacts with outside world directly. **Web API** contains almost all logic of the app including _user management and authentication_, _storing and versioning files_ (with help of **File server**), _counting and assigning points_ to users etc. **Broker** is essential part of whole architecture and can be marked as single point of failure. It maintains list of available **Workers**, receives submissions from the **Web API** and routes them further and reports progress of evaluations back to the **Web app**. **Worker** securely runs each received job and evaluate it's results. **Monitor** resends evaluation progress messages to the **Web app** in order to be presented to users.
Almost whole communication goes through **Broker** and ZeroMQ messaging middleware. When **Web app** wants to execute submission then all datas are handed over to **Worker** through **Broker**, similar situation is with progress state which start in **Worker** goes through **Broker** then pass **Monitor** and end up in **Web app** (as WebSockets). Only part of communication, which does not include **Broker**, is communication with **File server** which is realized through HTTP commmunication. This communication can be initiated by **Web API** or by **Worker**, other services have no access to **File server**. Detailed view into communication is on separate page [[Communication]].
Almost whole communication goes through **Broker** and ZeroMQ messaging middleware. When **Web app** wants to execute submission then all datas are handed over to **Worker** through **Broker**, similar situation is with progress state which start in **Worker** goes through **Broker** then pass **Monitor** and end up in **Web app** (as WebSockets). Only part of communication, which does not include **Broker**, is communication with **File server** which is realized through HTTP commmunication. This communication can be initiated by **Web API** or by **Worker**, other services have no access to **File server**. Detailed view into communication is in separate section [Communication](#communication).
## Communication
## Communication
@ -83,7 +83,7 @@ Broker is server when communicating with worker. IP address and port are configu
Commands from broker to worker:
Commands from broker to worker:
- **eval** - evaluate a job. See **eval** command in [[Communication#main-communication]]
- **eval** - evaluate a job. See **eval** command in [Main communication](#main-communication) section
- **intro** - introduce yourself to the broker (with **init** command) - this is
- **intro** - introduce yourself to the broker (with **init** command) - this is
required when the broker loses track of the worker who sent the command.
required when the broker loses track of the worker who sent the command.
Possible reasons for such event are e.g. that one of the communicating sides
Possible reasons for such event are e.g. that one of the communicating sides
@ -95,8 +95,8 @@ Commands from worker to broker:
- **init** - introduce yourself to the broker. Useful on startup or after reestablishing lost connection. Requires at least 2 arguments:
- **init** - introduce yourself to the broker. Useful on startup or after reestablishing lost connection. Requires at least 2 arguments:
- `hwgroup` - hardware group of this worker
- `hwgroup` - hardware group of this worker
- `header` - additional header describing worker capabilities. Format must be `header_name=value`, every header shall be in a separate message frame. There is no maximum limit on number of headers.
- `header` - additional header describing worker capabilities. Format must be `header_name=value`, every header shall be in a separate message frame. There is no maximum limit on number of headers.
- **done** - job evaluation finished, see **done** command in [[Communication#main-communication]].
- **done** - job evaluation finished, see **done** command in [Main communication](#main-communication) section.
- **progress** - evaluation progress report, see **progress** command in [[Communication#progress-callback]]
- **progress** - evaluation progress report, see **progress** command in [Progress callback](#progress-callback) section
- **ping** - tell broker I'm alive, no arguments
- **ping** - tell broker I'm alive, no arguments
#### Heartbeating
#### Heartbeating
@ -166,7 +166,7 @@ discarded.
Commands from broker to monitor:
Commands from broker to monitor:
- **progress** - notification about progress with job evaluation. See [[Communication#progress-callback]] for more info.
- **progress** - notification about progress with job evaluation. See [Progress callback](#progress-callback) section for more info.
### Broker - Frontend communication
### Broker - Frontend communication
@ -195,7 +195,7 @@ Commands from broker to frontend (all are responses to **eval** command):
### File Server - Frontend communication
### File Server - Frontend communication
File server has a REST API for interaction with other parts of ReCodEx. Description communication with workers is in [[Communication#file-server-point-of-view]]. On top of that, there are other command for interaction with frontend:
File server has a REST API for interaction with other parts of ReCodEx. Description communication with workers is in [File server point of view](#file-server-point-of-view) section. On top of that, there are other command for interaction with frontend:
- **GET /results/\<id\>.\<ext\>** - download archive with evaluated results of job _id_
- **GET /results/\<id\>.\<ext\>** - download archive with evaluated results of job _id_
- **POST /submissions/\<id\>** - upload new submission with identifier _id_. Expects that the body of the POST request uses file paths as keys and the content of the files as values. On successful upload returns JSON `{ "archive_path": <archive_url>, "result_path": <result_url> }` in response body. From _archive_path_ can be the submission downloaded (by worker) and corresponding evaluation results shouldbe uploaded to _result_path_.
- **POST /submissions/\<id\>** - upload new submission with identifier _id_. Expects that the body of the POST request uses file paths as keys and the content of the files as values. On successful upload returns JSON `{ "archive_path": <archive_url>, "result_path": <result_url> }` in response body. From _archive_path_ can be the submission downloaded (by worker) and corresponding evaluation results shouldbe uploaded to _result_path_.
@ -239,7 +239,7 @@ Message JSON format is dictionary with keys:
## Assignments
## Assignments
Assignments are programming tasks that can be tested by a worker after a user
Assignments are programming tasks that can be tested by a worker after a user
submits their solution. An assignment is described by a YAML file that contains information on how to
submits their solution. An assignment is described by a YAML file that contains information on how to
build, run and test it. Following text requires knowledge of basic terminology used by ReCodEx. Please, check [separate page](Terminology).
build, run and test it.
### Basics
### Basics
Job is a set/list of tasks (it is generally a set, but order of tasks have some meaning). These tasks may have dependencies (arbitrary number), which needs to be observed. When recodex-worker processes job, it creates a task graph, where tasks are vertices and dependencies are edges (A -> B means that the task A is on the dependency list of task B) and creates its linear ordering. The graph must be acyclic (otherwise linear ordering will not exist) and the recodex-worker attempts to execute maximal number of tasks possible. Tasks without dependencies can be executed directly, other tasks are executed when all their dependencies have been successfully completed.
Job is a set/list of tasks (it is generally a set, but order of tasks have some meaning). These tasks may have dependencies (arbitrary number), which needs to be observed. When recodex-worker processes job, it creates a task graph, where tasks are vertices and dependencies are edges (A -> B means that the task A is on the dependency list of task B) and creates its linear ordering. The graph must be acyclic (otherwise linear ordering will not exist) and the recodex-worker attempts to execute maximal number of tasks possible. Tasks without dependencies can be executed directly, other tasks are executed when all their dependencies have been successfully completed.
@ -655,8 +655,7 @@ with the test and then runs it against different configurations of `msim`.
## Submission flow
## Submission flow
This article will describe in detail execution flow of submission from the point of submission into web application to the point of evaluation of results from execution. Only hot path is considered in following description.
It's assumed that readers understand [[Architecture]], [[Terminology]], [[Communication]] and [[Assignments Overview]]. This article will describe in detail execution flow of submission from the point of submission into web application to the point of evaluation of results from execution. Only hot path is considered in following description.
Martin Polanka
8 years ago