Newer
Older
# Table of Contents
1. [Overview](#overview)
2. [Autosubmit Big Picture](#autosubmit-big-picture)
3. [General Knowledge Requirements](#general-knowledge-requirements)
4. [Deployment](#deployment)
## Overview
Autosubmit API is a package that consumes the information generated by Autosubmit and serves it as an API.
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
## Autosubmit Big Picture
In this image you can see the flow of information in the **Autosubmit environment**.
* **Autosubmit**: Machines running Autosubmit.
* **Remote Platforms**: Platforms (HPCs in most cases) to which Autosubmit connects to run jobs.
* **Experiment Database**: Starting from Autosubmit `3.13.0`, each experiment generates a set of databases that save important (reusable) information about it. We have the `historical database`, `graph database`, `structures database`.
* **File System**: The file system where the experiment files are stored.
* **Data Process Workers**: **Autosubmit API** implements a set of workers that periodically collect information from the experiments or complement that information. In the current **BSC** implementation, these workers are running no `bscesweb04` under `webadmin` user.
* **Main Database**: **Autosubmit API** uses a centralized database to keep track of important experiment information. The **workers** fill this information. **Autosubmit** also writes into this database.
* **Autosubmit API**: See [Autosubmit API](https://earth.bsc.es/gitlab/es/autosubmit_api). Currently, under **BSC** implementation, this API is running on `bscesweb04` under `webadmin` user. This API exposes a set of requests that **Autosubmit GUI** consumes and serves to the users through the front end.
* **Autosubmit GUI**: This project.
* **Authentication Server**: **BSC Central Authentication Service**.
* **Users**: Users that access the GUI through their web browsers from any device. The current implementation requires that an user generates a token using the Authentication server once every 5 days.
## General Knowledge Requirements
* Python 2.7
* Object Oriented Programming
* Flask
* Gunicorn
* Unit testing
## Deployment
Our local implementation is currently on `bscesweb04` under the user `webadmin`, make sure you have access to that server and that particular user. Once you have logged in to that machine under that user, follow these steps to start the API:
1. Activate the virtual environment: `source /srv/www/htdocs/AutosubmitAPI/venv27/bin/activate`.
1. Once the virtual environment is active, you can uninstall and install `autosubmit_api` using `pip` to verify it is updated.
2. Make sure `gunicorn` is not running: `pstree -ap | grep gunicorn`. This method may not be as effective to identify the API service if more than one `gunicorn` instance is running for different services, but so far it is the easy way to do it. If the process is running and you want to start over, `kill -9` it.
3. To start `gunicorn` for `autosubmit_api` execute: `gunicorn --error-logfile ~/logunicorn0320.txt --timeout 600 -b 0.0.0.0:8081 -w 4 autosubmit_api.app:app --daemon`, where `~/logunicorn0320.txt` is the path to the log file that will be used (it does not need to exist beforehand), `--timeout 600` indicates the number of seconds that `gunicorn` will wait for each process before killing it, `-b 0.0.0.0:8081` is the IP and port that will be used (two services cannot share the same IP and port, `0.0.0.0` is a shortcut for localhost, in practice, the public address will be `http://192.168.11.91:8081`), `autosubmit_api.app:app` is the name of the file that exposes the operations that the API will answer, and `--daemon` is a flag that indicates that this is a background process.
4. You can test if the process is running with the method mentioned before, or by checking the log files you set in the previous step.
**Autosubmit API** should be UP and RUNNING.