Skip to content

Latest commit

 

History

History
130 lines (102 loc) · 5.2 KB

index.org

File metadata and controls

130 lines (102 loc) · 5.2 KB
Raw

Design of ADS and related services

Introduction

Requirements

For release v1.0.2

  1. ADS, when deployed on a machine (VM/container) creates containers on a specified machine running centos 6.6 and openVZ kernel 2.6.32-042stab103.6
  2. ADS, when deployed on a machine (VM/container) starts the VMManager service on port 9089 on the newly created containers.

Design

CentOSVZAdapter

Documentation of CentOSVZAdapter is found here

AWSAdapter

Documentation of AWSAdapter is found here here

Implementation

Test Cases

Design Discussions

Deploying a Lab :: A case for using configuration management tools.

To deploy a lab, there are two steps:

  • Provision a VM
  • Install the lab on the provisioned VM.

Provisioning and installation details are declared in a deployment specification file.

One of the drawbacks of this approach is that abstraction happens at two levels: first when the deployment specification is defined by the integrator and second when the these declarations are interpreted while execution. It might take several cycles of testing for the integrator to figure out the way the installer is interpreting the specification before getting it right.

Also, the integrator might be asking for help from VLEAD while going through these cycles of testing. VLEAD will have to invest some of it’s engineering resources towards support.

To avoid these pitfalls, configuration tools can be used to our advantage. An integrator can be made entirely responsible for delivering a playbook (in ansible terms) which is self-contained and interpreted only by configuration manager (ansible in this case).

In such a scenario. ADS role is limited to providing the playbook to the configuration server which would configure and install the lab on the provisioned machine. Both lab integrator and ADS use the same configuration management tool precluding ambiguities, development and support.

Lab integrator would still have to provide the specification of the machine on which the lab is deployed/configured.

Life cycle management of labs

Life cycle management is the ability to perform the following 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 a bunch of scripts - start, stop, backup, restore, test. These scripts are developed by the integrator.

Auto deployment and life cycle management of labs enable continuous development, testing and release of software. If the onus on the integrator is to make a lab auto-deployable with life-cycle management scripts, it is imperative for VLEAD to build a platform for continuous delivery

Platform for Continuous Delivery

Lab ID

The key for the record that is saved into DB during deployment of a lab is lab_id. The values used for lab_id are alphanumeric e.g cse02, and are provided by the lab deployer to deploy a lab. lab_id is solely used to uniquely identify a record that is saved during deployment of lab in a database by ADS; essentially used for book keeping by the ADS.

In any situation, the user of ADS should not be burdened with providing a key. Instead, the generation should be the responsibility of ADS in such a way that a lab is always identified uniquely at any time.

Releases

Conventions followed with the github issue tracker

Done
An issue is in done state when code review is completed, tested and the branch in which this issue is addressed at the same level as develop branch.
Released
The issue is in production or pushed to master branch and tagged.

Release v1.0.2

Assumptions
Both the containers, one hosting ADS services and the other on which lab is deployed are created on a host machine configured with CentOS and OpenVZ.

ADS runs from a container and

  • creates a container on a host machine and
  • deploys a lab on this newly created container,

Release v1.0.3

Assumptions
ADS runs on a VM on AWS cloud
  1. ADS
    • creates a VM within AWS cloud, and
    • deploys lab on this newly created VM.
  2. Only authorized users deploy the labs.

Release v1.0.4

Assumptions
  • ADS runs from a container within a bridged network
  • Both the containers, one hosting ADS services and the other on which lab is deployed are created on a host machine configured with CentOS and OpenVZ.

ADS ::

  • creates a container within this bridged network and
  • deploys lab on this newly created container.

Release v1.2.0

This release is about:

  • providing support for life cycle management of ADS.
  • and enhancing the ability of ADS to deploy a lab when IAM role is associated with the machine running ADS services.
  • Manage services from a single script.
  • Adhere to Pep 8 coding standards
  • Save the state of a lab
  • GitHub Issues: 37, 57, 42, 48, 41, 3, 64, 46, 43, 56, 65, 53, 4, 50, 49 and 44