Skip to content

UMNET-perfSONAR/pssid-gui2

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

pssid-gui2

Version 2.0 of the pSSID-GUI Web Application

Installation

Ansible

Follow the steps in this repository.

Source Code

Clone this repository and run

docker-compose -f docker-compose.yml up -d

in the same directory. You may need sudo access to run docker compose.


Important README Links in this Repository

Steps to add fields to config file

Ideas for future improvement

Backend

About Test Template Files

About the Backend Folders

About Each Service File - In Server

Frontend

About each Frontend Directory

About each Client Component


pSSID GUI Web Application

System Overview

The core application consists of three Docker containers, client, server, and MongoDB. Users directly interact with the client container, which will in turn communicate with the backend server and database containers. Test templates are files on disk that define the rules for each test, i.e., what configuration fields should be provided for each test type. Dynamics forms are then geneated on the frontend based on the rules defined in the templates.

config-file-anatomy

The web application outputs two files, hosts.ini and pssid_conf.json. The latter is the pSSID daemon config file described below, which essentially contains the batches to be scheduled. The former, hosts.ini, is an Ansible inventory containing the list of hosts and groups defined on the GUI. They provide information about what to do (pssid_conf.json) on which probes (hosts.ini). The provisioning scripts will use Ansible to copy the daemon config file onto the probes defined in hosts.ini, and pSSID daemon on each probe will run accordingly.

Output pSSID Daemon Config File

The output configuration file is broken up into 7 components: hosts, host groups, schedules, SSID profiles, tests, jobs, and batches, each corresponding to a page on the GUI dashboard. See the breakdown below:

config-file-anatomy

At a high level, we use template files on disk to define a test. We then use tests to define a job. Eventually, we use SSID profiles, schedules, and jobs to define a batch and run batches, not raw tests, on the probes.

Graphical User Interface

The web application has seven separate tabs, one for each component of the configuration file.

Each tab has the ability to create, read, update, and delete its own data. Each tab has the following:

  • List of current objects in the MongoDB collection
    • inclduing a regex search bar to search through objects
  • Add object form
  • Edit/delete object form that appears after clicking on the name of an object

gui-screenshot