VRE Backend API and Scheduler
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Joshua Rubingh f683335c2f Update python libraries 4 months ago
VRE Update python libraries 4 months ago
doc Split up documentation and add SurfConext 8 months ago
docker Split up documentation and add SurfConext 8 months ago
nginx Favicon test 8 months ago
.dockerignore Speedup docker builds 9 months ago
.drone.yml Update unit testing and remove relative imports 4 months ago
.gitignore Add source language for Weblate 8 months ago
.pep8 Python pep8 format 1 year ago
DOCKER.md Split up documentation and add SurfConext 8 months ago
LICENSE Split up code 2 years ago
README.md Update 'README.md' 6 months ago
SECURITY.md Split up documentation and add SurfConext 8 months ago
clouds.yaml.example Split up documentation and add SurfConext 8 months ago
docker-compose.yaml Speedup docker builds 9 months ago
docker-compose.yaml.example Split up documentation and add SurfConext 8 months ago
run_scheduler.sh Update documentation 12 months ago


Research Workspace Broker

Build Status Translation status

Research Workspaces Broker is the hart of the Research Workspace. This is an API that is handling all the actions and requests from either a web interface of direct API.

This API is part of the Research workspace created by the Rijksuniversiteit Groningen.

This API is responsible for:

  • Backend for the web interface to the researchers
  • Inviting other researchers to your project
  • Handles the creation of virtual workspaces (VRW / Openstack)

More to come ...


The Broker is made with the Django Framework in combination with Django Rest Framework. The installation is pretty straight forward. After this the code is at location Broker and during the setup we assume that this is the root folder where you are in.

For a full Docker setup, look at DOCKER.md

  • The Broker depends on Redis and Postgres. These can be installed using docker-compose, or by installing the services directly on to your system.
docker-compose up
  • Then Checkout the GIT repository:
git clone https://git.web.rug.nl/VRE/Broker.git
  • Create a Python3 virtual environment by using venv (or virtualenvwrapper)
cd Broker
python3 -m venv [env_name]
  • Activate the Python3 virtual environment:
source [env_name]/bin/activate
  • Install all the required Python3 modules:
pip install -r VRE/requirements.txt
pip install -r VRE/requirements-dev.txt
  • Create a .env config file and adjust the Environment settings. At least enable Debug in development :
cp VRE/VRE/env.example VRE/VRE/.env
  • Create the database structure and load some needed data
VRE/manage.py migrate
VRE/manage.py loaddata virtual_machine_initial_data
VRE/manage.py loaddata university_initial_data
  • Create a super user (admin) to login to the admin part of the API
VRE/manage.py createsuperuser
  • Start the Django application
VRE/manage.py runserver

Now you can enter the Django Admin at http://localhost:8000/admin/. If do not see any styles on the page, make sure you have enabled Debug or setup static files for Django

The API can be found at http://localhost:8000/api/swagger/ or http://localhost:8000/api/redoc/

Environment settings

In order to get the API running, you need to specify some settings. This is done by creating environment variables with values that are read out by Django during startup. For this you can use a .env file or by manually setting bash environment variables. And example env file can be found at VRE/VRE/env.example which can be used as a template.

The location of the env file should be VRE/VRE/.env

more information can be found here


All variables have a short explanation above them what they do or used for.

# A uniquely secret key
# https://docs.djangoproject.com/en/dev/ref/settings/#secret-key

# Disable debug in production
# https://docs.djangoproject.com/en/dev/ref/settings/#debug

# Allowed hosts that Django does server. Use comma separated list Take care when NGINX is proxying in front of Django
# https://docs.djangoproject.com/en/dev/ref/settings/#allowed-hosts

# All internal IPS for Django. Use comma separated list
# https://docs.djangoproject.com/en/dev/ref/settings/#internal-ips

# Enter the database url connection. Enter all parts even the port numbers: https://github.com/jacobian/dj-database-url
# By default a local sqlite3 database is used.

# The location on disk where the static files will be placed during deployment. Setting is required
# https://docs.djangoproject.com/en/dev/ref/settings/#static-root

# Enter the default timezone for the visitors when it is not known.
# https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-TIME_ZONE

# Email settings
# https://docs.djangoproject.com/en/dev/ref/settings/#email-host

# Email user name
# https://docs.djangoproject.com/en/dev/ref/settings/#email-host-user

# Email password
# https://docs.djangoproject.com/en/dev/ref/settings/#email-host-password

# Email server port number to use. Default is 25
# https://docs.djangoproject.com/en/dev/ref/settings/#email-port

# Does the email server supports TLS?
# https://docs.djangoproject.com/en/dev/ref/settings/#email-use-tls

DEFAULT_FROM_EMAIL=Do not reply<no-reply@rug.nl>

# The sender address. This needs to be one of the allowed domains due to SPF checks
# The code will use a reply-to header to make sure that replies goes to the researcher and not this address
EMAIL_FROM_ADDRESS=Do not reply<no-reply@rug.nl>

# The Redis server is used for background tasks. Enter the variables below. Leave password empty if authentication is not enabled.
# The hostname or IP where the Redis server is running. Default is localhost

# The Redis port number on which the server is running. Default is 6379

# The Redis password when authentication is enabled

# The amount of connections to be made inside a connection pool.  Default is 10

# Enter the full path to the Webbased file uploading without the Study ID part. The Study ID will be added to this url based on the visitor.

# Enter the full url to the NGINX service that is in front of the TUSD service. By default that is http://localhost:1090

# Which file extensions are **NOT** allowed to be uploaded. By default the extensions exe,com,bat,lnk,sh are not allowed

# Sentry settings
# Enter the full Sentry DSN string. This should contain a key and a project

Background scheduler

For some actions we need a background scheduler system. This system is relaying on Redis, so make sure you have Redis installed. The scheduler can be start with the command:


This will load the Python3 virtual environment and start the background scheduler. Keep the console open.


We use NGINX as a proxy in front of the API. This is not mandatory, but can be handy when you have a busy api.

SurfConext login

In order to login, SurfConext is used. This will required a setup at SurfConext. And a ini file with the SurfConext credentials. There is an example file called surfnet_conext_secrets.ini.example which can be used as a template. Copy that file to surfnet_conext_secrets.ini at the same location and fill the values given by Surfnet

# Authentication settings
# https://mozilla-django-oidc.readthedocs.io/en/stable/installation.html
# The Client ID which is the Entity ID in SurfConext
# The Client secret that is created with the Entity ID. This will be shown only once
# The encryption algorithm. Default is RS256
# The following urls should be loaded automatically when PR039 is merged: https://github.com/mozilla/mozilla-django-oidc/pull/309 For now, we have to manually add those urls
# The source is at: https://connect.surfconext.nl/.well-known/openid-configuration (production)
# The source is at: https://connect.test.surfconext.nl/.well-known/openid-configuration (testing)
# This is the 'authorization_endpoint' url
# This is the 'token_endpoint' url
# This is the 'userinfo_endpoint' url
# This is the 'jwks_uri' url. Needed due to the `OIDC_RP_SIGN_ALGO` choice

VRW Integration

In order to use the VRW (Virtual Research Workspace) you need to configure a special user that is allowed to make the API calls for VRW updates.


Openstack Integration

For OpenStack integration we need a clouds.yaml file where the API credentials are stored and the API entrypoint.

This file needs to be stored at the root of the VRE Broker project next to this README.md file. Else the cloud.yaml file will not be found and therefore OpenStack calls will fail.

When this integrations is setup, it is possible to create virtual machines on the Openstack platform

Example config

Here you can see an example cloud.yaml file. The name hpc at line 2 is mandatory for the RUG Openstack setup.

      auth_url: [API_ENTRY_POINT]
      application_credential_id: "[API_CREDENTIALS]"
      application_credential_secret: "[API_CREDENTIALS_SECRET]"
    region_name: "RegionOne"
    interface: "public"
    identity_api_version: 3
    auth_type: "v3applicationcredential"