You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Worker is configured with the Backend API URL and credentials. For now, as we envision having only a single worker, we can have the worker's configuration (List of countries supported) done in the DB directly.
Worker communicates with the Backend via the Backend API.
Polling Backend API periodically is very reliable and transparent. In addition, we may have a zmq based push system that allows for instant operations on backend scheduling.
The worker is composed of a main manager that is mostly this poll loop awaiting test requests. Once a request arrive, the worker informs the backend that it is processing it.
Then it starts the actual test process:
informs the network container to reconfigure for requested country
ensures that this succeeded
starts the network-blind test container (which reports results to filesystem) and awaits its completion.
Once the tester has completed, results are read and submitted to the API (and deleted from disk?).
Worker is back on its loop.
Communication between the manager container and the tester one be done docker exec.
Alternative is to use filesystem: tester to store its output into a well known file onto a shared volume/mount. We used both methods on zimfarm, reliably.
The text was updated successfully, but these errors were encountered:
Worker is configured with the Backend API URL and credentials. For now, as we envision having only a single worker, we can have the worker's configuration (List of countries supported) done in the DB directly.
Worker communicates with the Backend via the Backend API.
Polling Backend API periodically is very reliable and transparent. In addition, we may have a zmq based push system that allows for instant operations on backend scheduling.
The worker is composed of a main manager that is mostly this poll loop awaiting test requests. Once a request arrive, the worker informs the backend that it is processing it.
Then it starts the actual test process:
Once the tester has completed, results are read and submitted to the API (and deleted from disk?).
Worker is back on its loop.
Communication between the manager container and the tester one be done
docker exec
.Alternative is to use filesystem: tester to store its output into a well known file onto a shared volume/mount. We used both methods on zimfarm, reliably.
The text was updated successfully, but these errors were encountered: