Contest services¶
These contest services are the infrastructure for visualizing, scheduling and running matches and tournaments between the champions. They are one of the most important parts of the final infrastructure and should be prioritized more than non-core services.
Concours¶
Concours is the main contest website available at http://concours/
. It
allows people to upload champions and maps, schedule champion compilations, and
schedule maps. Staff users can also use it to schedule tournaments.
Concours is usually installed on the web
machine, running as
concours.service
. The on-disk champion and match data is stored in
/var/prologin/concours_shared
. Users are automatically synchronized
from UDB with udbsync_django@concours
.
Note
Concours is a contest service. It won’t be available to users until the contest gets enabled in the Ansible inventory. See Switching in and out of contest mode.
API¶
Concours has a REST API available at http://concours/api
. It can be used by
contestants to script their interaction with the website.
Masternode¶
Masternode is the scheduler node of a distributed task queue that runs on all the user machines. Its goal is to retrieve pending tasks to compile champions and run matches from the Concours website, find an available node to run the task and send the required task data to the “Workernodes”. Once the task is completed, the Workernode sends back the result to Masternode, which saves it in the database.
Masternode has to be setup on the same machine as Concours, as it requires
access to /var/prologin/concours_shared
to retrieve and save the champion
data. It runs as masternode.service
on web
.
You can check that Masternode is properly working by going to the master status page on http://concours/status. It will tell you whether Masternode is accessible, and list the Workernodes that are currently attached to it.
Workernode¶
Workernode is the service that runs on all the user machines. It uses isolate and camisole <https://camisole.prologin.org/> as isolation backends, to make sure that the contestants’ code is run safely without annoying the machine users.
Workernode runs as workernode.service
. Workers that cannot be reached from
the Masternode are automatically dropped from the pool. It is possible to
configure the number of “slots” allocated to each worker to throttle
parallelism in the ansible configuration, as well as the time, memory and other
resource constraints.
Year-specific customizations¶
Each year we create a new multiplayer game to be used in the final. We usually need to add customizations for the game of the year, either aesthetic (custom CSS for the theme of the game) or practical (map validation scripts, game configuration, …).
Configuration¶
TODO: Document how to set the number of players, whether to use maps, etc.
Theme¶
TODO: Document how to deploy and set the static path of the game theme.
Replay¶
TODO: Document how to deploy the Javascript replayer script.
Map preview¶
TODO: Document how to deploy the Javascript map previewing script.
Map validity checks¶
TODO: Document how to deploy the map checking script to ensure uploaded maps are valid. This might become obsolete if this issue is solved: https://github.com/prologin/stechec2/issues/136
Running tournaments¶
TODO