Lab Structure

Directory structure of lab sources

|-- README.txt
|-- scripts
|   |-- backup
|   |-- labspec.json
|   |-- restore
|   |-- startup
|   |-- stop
|   `-- test
|-- src
|-- tests

Integration Levels

Level 0

Lab does not adhere to any of the integration critetia

Level 1 :: Versioned

Complete sources are versioned at an available location.

Level 2 :: Buildable

Sources conform to a lab development kit. They are buildable through scripts.

Level 3 :: Testable

Lab has unit and integration tests and is testable on a central test server.

Level 4 :: Hostable

Lab is deployable on a central hosting server

Level 5 :: Automated Deployment of a Lab

Lab is supported by a specification and scripts for automated deployment

At this level, the lab gets deployed on a machine without manual intervention. The specification for deployment is in place which is the input to the deployment service.

The deployment specification will capture all the steps that are required to deploy a lab.

Level 6 :: Life-Cycle Management

Lab is supported by a set of scripts for life-cycle management of lab. Life

Life cycle management is the ability to perform these tasks on a lab: start, stop, backup, restore from a previous backup and test. Having such functionality helps continuous releases of the software running the lab. This management of a lab is achieved through the following bunch of scripts. These scripts are developed by the integrator.

Structure of the scripts

>-- README.txt
>-- scripts/
    >-- start
    >-- stop
    >-- backup
    >-- restore
    >-- test
    >-- labspec.json


  • Start a Lab

    Script start provides a mechanism to start databases, web server, application defined services and populating data stores that are required for the lab to work. The script ensures all services are started and the dependencies of the lab are initialized in the right order.

  • Stop a Lab

    Script stop stops the lab from running. This script does a clean termination of all the processes and services initiated by the lab. This script backs up the relevant data and state information that is necessary to bring back the lab to the state it was in before termination.

  • Back up a Lab

    Script backup captures and saves the relevant data that is essential to bring the lab to the same state it was in at the time of backup. The relevant data could vary with each version of lab software released. A subset of relevant data is user information, configuration, user files and databases.

    There is a high possibility that this relevant data varies with each version of lab software. Therefore, when a backup is made, it is ensured that the version of lab software is also captured.

    This script is required for: disaster recovery, enable newer versions of lab deployment by retaining the old data, regular backups, etc.

    When the backup script is executed, a single file is generated in the same directoy. The version of the lab software is appended to the generated file. The file is named labbackup-<version>.tar. Example values of <version> are v1.0, v1.0.1 , etc. More information on versioning/tagging is available here.

    If there is no backup required for a lab, the script should still be in place, which can either be empty or contain comments.

  • Restore a Lab

    Script restore restores data backed up by backup script. The restore script takes the filename as argument and uses the supplied file for restoration.

    % restore labbackup_<version>.tar

    The restore script works with at least two versions of lab software when there is more than one version of lab software available.

    1. restore script restores the lab from the backup file generated by the backup script. Both the restore and backup are part of the same release of the lab software.
    2. restore script restores the lab from the backup file generated by the backup script contained in the previous release of the lab software.

    If restoration process requires certain services to be stopped or started, then restore script takes care of all such requirements.

    If there is no restoration required for a lab, the script should still be in place, which can either be empty or contain comments.

  • Test a Lab

    When a lab is hosted, script test provides a mechanism to ascertain the lab is fully functional. These test cases are run immediately after the lab is deployed and also at regular intervals. The developers are informed of the failure in test cases with the test output.

    A test script indicates either successful or unsuccessful execution of all tests. The output the test script is saved to a file named test_results.txt in the same directory.



|-- tests
|    -- system_tests
|       -- <exp1>_tests
|          -- test_1.txt
|          -- test_2.txt
|             ...
|             ---
|       -- <exp2>_tests
|          -- test_1.txt
|             ...
|             ---
|    -- functional_tests
|       -- <exp1>_tests
|          -- test_1.txt
|          -- test_2.txt
|             ...
|             ---
|       -- <exp2>_tests
|          -- test_1.txt
|             ...
|             ---

Systems Tests

System tests will capture availability, performance of lab software.

Functional Tests

Functional tests will capture the defined functionality of each experiment and therefore a lab.

Pages generated from emacs org-mode