Merge pull request #85 from lsst-ts/release/3.0.0

Release/3.0.0

.gitignore

@@ -11,6 +11,8 @@ webpack-stats.*
 **/db_data
 
 # preserve folder structure with dummy gitinclude file
+manager/config/**
+!manager/config/.gitinclude
 manager/media/thumbnails/**
 !manager/media/thumbnails/.gitinclude
 manager/ui_framework/tests/media/thumbnails/**

README.md

@@ -3,49 +3,57 @@ This repository contains the code of the Django Channels project that acts as mi
 See the documentation here: https://lsst-ts.github.io/LOVE-manager/html/index.html
 
 # Use as part of the LOVE system
+
 In order to use the LOVE-manager as part of the LOVE system we recommend to use the docker-compose and configuration files provided in the [LOVE-integration-tools](https://github.com/lsst-ts/LOVE-integration-tools) repo. Please follow the instructions there.
 
 ## Initialize Environment variables
+
 In order to use the LOVE-manager, some environment variables must be defined before it is run.
 All these variables are initialized with default variables defined in :code:`.env` files defined in the corresponding deployment environment defined in [LOVE-integration-tools](https://github.com/lsst-ts/LOVE-integration-tools). The are:
 
-* `ADMIN_USER_PASS`: password for the default `admin` user, which has every permission.
-* `USER_USER_PASS`: password for the default `user` user, which has readonly permissions and cannot execute commands.
-* `CMD_USER_PASS`: password for the default `cmd` user, which has readonly permissions but can execute commands.
-* `REDIS_HOST`: the location of the redis host that implements the `Channels Layer`.
-* `REDIS_PASS`: the password that the LOVE-manager needs to use to connect with `redis`.
-* `PROCESS_CONNECTION_PASS`: the password that the LOVE-producer will use to establish a websocket connection with the LOVE-manager.
-* `DB_ENGINE`: describe which database engine should be used. If its value is `postgresql` Postgres will be used, otherwise it will use Sqlite3.
-* `DB_NAME`: defines the name of the Database. Only used if `DB_ENGINE=postgresql`.
-* `DB_USER`: defines the user of the Database. Only used if `DB_ENGINE=postgresql`.
-* `DB_PASS`: defines the password of the Database. Only used if `DB_ENGINE=postgresql`.
-* `DB_HOST`: defines the host of the Database. Only used if `DB_ENGINE=postgresql`.
-* `DB_PORT`: defines the port of the Database. Only used if `DB_ENGINE=postgresql`.
-* `NO_DEBUG`: defines wether or not the LOVE-.manager will be run using Django's debug mode. If the variable is defined, then Debug mode will be off.
-* `SECRET_KEY`: overrides Django's SECRET_KEY, if not defined the default value (public in this repo) will be used.
-* `AUTH_LDAP_SERVER_URI`: (deprecated) the location of the LDAP authentication server. No LDAP server is used if this variable is empty
+- `ADMIN_USER_PASS`: password for the default `admin` user, which has every permission.
+- `USER_USER_PASS`: password for the default `user` user, which has readonly permissions and cannot execute commands.
+- `CMD_USER_PASS`: password for the default `cmd` user, which has readonly permissions but can execute commands.
+- `REDIS_HOST`: the location of the redis host that implements the `Channels Layer`.
+- `REDIS_PASS`: the password that the LOVE-manager needs to use to connect with `redis`.
+- `PROCESS_CONNECTION_PASS`: the password that the LOVE-producer will use to establish a websocket connection with the LOVE-manager.
+- `DB_ENGINE`: describe which database engine should be used. If its value is `postgresql` Postgres will be used, otherwise it will use Sqlite3.
+- `DB_NAME`: defines the name of the Database. Only used if `DB_ENGINE=postgresql`.
+- `DB_USER`: defines the user of the Database. Only used if `DB_ENGINE=postgresql`.
+- `DB_PASS`: defines the password of the Database. Only used if `DB_ENGINE=postgresql`.
+- `DB_HOST`: defines the host of the Database. Only used if `DB_ENGINE=postgresql`.
+- `DB_PORT`: defines the port of the Database. Only used if `DB_ENGINE=postgresql`.
+- `NO_DEBUG`: defines wether or not the LOVE-.manager will be run using Django's debug mode. If the variable is defined, then Debug mode will be off.
+- `SECRET_KEY`: overrides Django's SECRET_KEY, if not defined the default value (public in this repo) will be used.
+- `AUTH_LDAP_SERVER_URI`: (deprecated) the location of the LDAP authentication server. No LDAP server is used if this variable is empty
 
 # Local load for development
+
 We provide a docker image and a docker-compose file in order to load the LOVE-manager with a Postgres database locally, for development purposes, such as run tests and build documentation.
 
 This docker-compose does not copy the code into the image, but instead it mounts the repository inside the image, this way you can edit the code from outside the docker container with no need to rebuild or restart.
 
 ## Load and get into the docker image
+
 Follow these instructions to run the application in a docker container and get into it:
 
 ```
 docker-compose up -d
-docker-exec manager bash
+docker-compose exec manager bash
 ```
 
 ## Run tests
+
 Once inside the container you will be in the `/usr/src/love/manager` folder, where you can run the tests as follows:
+
 ```
 pytest
 ```
 
 ## Build documentation
+
 Once inside the container you will be in the `/usr/src/love/manager` folder, where you can move out to the `docsrc` folder and build the documentation as follows:
+
 ```
 cd ../docsrc
 ./create_docs.sh

docs/html/.buildinfo

@@ -1,4 +1,4 @@
 # Sphinx build info version 1
 # This file hashes the configuration used when building these files. When it is not found, a full rebuild will be done.
-config: 0e75181af2d457cfd432dc4ec2676b09
+config: f7c93eb5b9fa8ff85b7779f24fc50c8f
 tags: 645f666f9bcd5a90fca523b33c5a78b7

docs/html/_sources/apidoc/api.rst.txt

@@ -51,6 +51,14 @@ api.models module
    :undoc-members:
    :show-inheritance:
 
+api.schema\_validator module
+----------------------------
+
+.. automodule:: api.schema_validator
+   :members:
+   :undoc-members:
+   :show-inheritance:
+
 api.serializers module
 ----------------------
 
@@ -59,6 +67,14 @@ api.serializers module
    :undoc-members:
    :show-inheritance:
 
+api.signals module
+------------------
+
+.. automodule:: api.signals
+   :members:
+   :undoc-members:
+   :show-inheritance:
+
 api.urls module
 ---------------
 

docs/html/_sources/apidoc/api.tests.rst.txt

@@ -4,6 +4,22 @@ api.tests package
 Submodules
 ----------
 
+api.tests.test\_commander module
+--------------------------------
+
+.. automodule:: api.tests.test_commander
+   :members:
+   :undoc-members:
+   :show-inheritance:
+
+api.tests.test\_schema\_validation module
+-----------------------------------------
+
+.. automodule:: api.tests.test_schema_validation
+   :members:
+   :undoc-members:
+   :show-inheritance:
+
 api.tests.tests\_auth\_api module
 ---------------------------------
 
@@ -12,6 +28,14 @@ api.tests.tests\_auth\_api module
    :undoc-members:
    :show-inheritance:
 
+api.tests.tests\_config module
+------------------------------
+
+.. automodule:: api.tests.tests_config
+   :members:
+   :undoc-members:
+   :show-inheritance:
+
 
 Module contents
 ---------------

docs/html/_sources/apidoc/manager.rst.txt

@@ -36,6 +36,14 @@ manager.urls module
    :undoc-members:
    :show-inheritance:
 
+manager.utils module
+--------------------
+
+.. automodule:: manager.utils
+   :members:
+   :undoc-members:
+   :show-inheritance:
+
 manager.wsgi module
 -------------------
 

docs/html/_sources/apidoc/subscription.rst.txt

@@ -4,6 +4,14 @@ subscription package
 Submodules
 ----------
 
+subscription.apps module
+------------------------
+
+.. automodule:: subscription.apps
+   :members:
+   :undoc-members:
+   :show-inheritance:
+
 subscription.auth module
 ------------------------
 
@@ -20,6 +28,14 @@ subscription.consumers module
    :undoc-members:
    :show-inheritance:
 
+subscription.heartbeat\_manager module
+--------------------------------------
+
+.. automodule:: subscription.heartbeat_manager
+   :members:
+   :undoc-members:
+   :show-inheritance:
+
 subscription.routing module
 ---------------------------
 

docs/html/_sources/apidoc/ui_framework.rst.txt

@@ -43,6 +43,14 @@ ui\_framework.serializers module
    :undoc-members:
    :show-inheritance:
 
+ui\_framework.signals module
+----------------------------
+
+.. automodule:: ui_framework.signals
+   :members:
+   :undoc-members:
+   :show-inheritance:
+
 ui\_framework.urls module
 -------------------------
 

docs/html/_sources/apidoc/ui_framework.tests.rst.txt

@@ -4,6 +4,14 @@ ui\_framework.tests package
 Submodules
 ----------
 
+ui\_framework.tests.test\_view\_thumbnail module
+------------------------------------------------
+
+.. automodule:: ui_framework.tests.test_view_thumbnail
+   :members:
+   :undoc-members:
+   :show-inheritance:
+
 ui\_framework.tests.tests\_api module
 -------------------------------------
 
@@ -12,6 +20,14 @@ ui\_framework.tests.tests\_api module
    :undoc-members:
    :show-inheritance:
 
+ui\_framework.tests.tests\_custom\_api module
+---------------------------------------------
+
+.. automodule:: ui_framework.tests.tests_custom_api
+   :members:
+   :undoc-members:
+   :show-inheritance:
+
 ui\_framework.tests.tests\_models module
 ----------------------------------------
 

docs/html/_sources/modules/how_it_works.rst.txt

@@ -9,28 +9,44 @@ LOVE-manager parts
 ==================
 The LOVE-manager is composed by different software components, as explained below.
 
-API
----
-Provides a REST API with endpoints to request and validate access tokens.
-When a client (LOVE-frontend) tries to login it sends the users credentials (user and password) through an HTTP request to the API, which responds with the token (if the credentials are valid) or an error (if the credentials are invalid). The validation is done comparing searching the given user in the :code:`DB` and comparing the given password.
+Auth API
+--------
+Provides an HTTP API with endpoints to request and validate access tokens.
+
+When a client (LOVE-frontend) tries to login it sends the users credentials (user and password) through an HTTP request to the API, which responds with the token (if the credentials are valid) or an error (if the credentials are invalid). The validation is performed by searching the given user in the :code:`DB` and comparing the given password with the user's password in the :code:`DB`.
+
+The Auth API also provides additional information in its responses, such as the users permissions and the current server time in diffent formats (UTC, TAI, Sidereal, among others). For more details please see the :ref:`Authentication` section.
+
+UI Framework API
+----------------
+Provides a REST API with endpoints to perform CRUD (Create, Retrieve, Update, Delete) operations on UI Frmework Views. The views contents, layout and configuration are saved as a JSON string in the database.
+
+Commander API
+----------------
+Provides an HTTP API with endpoints to run Commands.
+When a client (like a :code:`LOVE-Frontend` instance) requests a Command, the :code:`Commander API` sends the request to the :code:`LOVE-Commander`.
+
+When the :code:`LOVE-Commander` receives the request, it runs the Command using :code:`salobj` and waits for its acknowledgement. Once the acknowledgement is received, the :code:`LOVE-Commander` sends the acknowledgement in the request's response.
+Similarly, the :code:`Commander API`sends the acknowledgement in its response to the client request.
+
+Additionally, the :code:`Commander API` provides endpoints to request genera information from SAL (SAL Info). These requests are also handled by the :code:`LOVE-Commander`.
 
 Consumers
 ---------
 Once the client (LOVE-frontend) has an access token, it can establish a websocket connection with LOVE-manager's :code:`Channels Layer`. Each client (LOVE-frontend) instance is connected to a unique :code:`Consumer` instance, which handles the communication with that particular client.
-Similarly, a :code:`Consumer` also handle the communication with a LOVE-producer instance.
+Similarly, a :code:`Consumer` also handles the communication with a LOVE-producer instance.
 
-Each :code:`consumer` communicates only with their corresponding clients. In order to receive messages from other clients, the consumer of a client must subscribe to a given group.
+Each :code:`consumer` communicates only with its corresponding client. In order to receive messages, the consumer of a client must subscribe to a given group.
 When a client sends a message to a group, it is forwarded to all the consumers subscribed to that group, which in turn send the message to their corresponding clients. All the message routing is done in the :code:`Channels Layer`.
 
 Channel Layer
 -------------
 The :code:`Channels Layer` acts as the message handler, and is in charge of making sure every consumer receives the messages from the groups it has subscribed to.
 When a client sends a message to its :code:`Consumer`, it is forwarded to the :code:`Channels Layer`. The :code:`Channels Layer` forwards the message to all the consumers subscribed to the group, and each consumer forwards the messages to its corresponding client.
 
-DB
---
-The :code:`DB` is used to model and store the users data (username, password and permissions). It is currently implemented in a simple :code:`.sqlite3` file, and is initialized with default users and groups.
-
+Database
+--------
+The :code:`DB` is used to model and store the users data (username, password and permissions), and the UI Framework views. It is currently configured to be a :code:`PostgreSQL` instance, and it is initialized with default users and groups.
 
 Example
 =======
@@ -46,10 +62,11 @@ Code organization
 
 Currently the application is divided in the following modules and files:
 
-* :code:`api`: This module contains the :code:`API` Django app, which defines the models and API endpoints for authentication. For more details please refer to the ApiDoc section
+* :code:`api`: This module contains the :code:`API` Django app, which defines the models and API endpoints for authentication (:code:`Auth API`) and Commander (:code:`Commander API`) APIs. For more details please refer to the :ref:`ApiDoc` section
+* :code:`ui_framework`: This module contains the :code:`UI Framework` Django app, which defines the models and API endpoints for the UI Framework views (:code:`UI Framework API`) API. For more details please refer to the :ref:`ApiDoc` section
 * :code:`subscription`: This module contains the Django app that defines the consumers that handle the websocket communication.
 * :code:`manager`: This module contains basic Django configuration files, such as urls and channels routing, etc.
-* :code:`manage.py`: This module is the main executable of the Django application, used mostly for development purposes, but also to execute some actions over the database, such as applying migrations, creating data, etc.
+* :code:`manage.py`: This module is the main executable of the Django application, used mostly for development purposes, but also to execute some actions over the database, such as applying migrations, saving data from fixtures, etc.
 * :code:`pytest.ini`: This is the configuration file for the Pytest testing module.
 * :code:`requierements.txt`: This file defines the python libraries required by the application.
 * :code:`runserver.sh` and :code:`runserver-dev.sh`: These are simple scripts used to run the application inside the docker images.