• Created by Unknown User (mfreemon), last modified on Aug 03, 2015

Block Diagram

Version 7 (8/3/2015). Click to enlarge.

Design/Implementation

NDS Explorer Implementation

  • angular.js

NDS Web Services Implementation

  • Python/Django/Django-REST-Framework
  • Use the OpenStack nova API to perform the calls to the OpenStack management functions 
  • What do the REST calls actually look like?
    • See wiki pages
  • Regarding the installation of the OpenStack python libraries: We probably eventually want to move this to being fully self-contained with a requirements.txt file.   requirements.txt is a mechanism of specifying things to pip so that things can be pip installed; it's similar to what enables webapps to be deployed in "kernel" form on things like amazon beanstalk and so on, too. If we do it this way, our webapp will be pip-installable, and will install into ~/.site-local if need be.

Authentication/Authorization

  • For the initial version, we will use a service account for OpenStack.  Users credentials will not be OpenStack credentials.
  • The OpenStack credentials are used by the REST API logic and are not provided by (nor known to) the user.  This will need to be specified in such a way that it will not be accidentally committed to the repository.

Application State

  • How to tell what Environments exist?
    • If they were created by NDS Web Services (and have not been deleted), then they exist.  Ignore any NDS Environments that have been created manually (not using NDS Web Services).
  • How to store info about the existing Environments?
  • How to store the Service definitions?
  • Use the easiest and most straightforward solution for the first prototype.

Service Definition Files

  • The service definition will need to include environment variables that are passed in which can/should be free-form text + a set of predefined env vars. These can be obtained by parsing the JSON returned from "docker inspect", and for any orchestrated multi-service environments we'll want dedepulication of env vars.

Guiding Principles

This section provides useful and relevant things to consider.  These items should not be taken as concrete requirements.

Prior Versions of the Block Diagram

Version 6 (7/28/2015). Click to enlarge.

Version 5 (7/24/2015). Click to enlarge.

Version 4 (7/15/2015). Click to enlarge.

Version 3 (6/16/2015).  Click to enlarge.

From 6/12/2015 meeting:

From 6/10/2015 meeting:

 

  File Modified
JPEG File block-diagram-capture-v5.JPG Jul 24, 2015 by mfreemon
JPEG File block-diagram-v3.JPG Jun 16, 2015 by mfreemon
JPEG File block-diagram-v6.JPG Jul 28, 2015 by mfreemon
JPEG File block-diagram-v7.JPG Aug 03, 2015 by mfreemon
JPEG File Capture.JPG Jun 12, 2015 by mfreemon
JPEG File NDS-block-diagram-Capture-v4.JPG Jul 15, 2015 by mfreemon
Microsoft Powerpoint Presentation NDS-Block-Diagram-v4.pptx Jul 15, 2015 by mfreemon
JPEG File NDS-Explorer-Block-Diagram.JPG Jun 10, 2015 by mfreemon
Microsoft Powerpoint Presentation NDS-Explorer-Block-Diagram-v3.pptx Jun 26, 2015 by mfreemon

  • No labels

2 Comments

  1. Unknown User (mfelarca)

    This looks good. It should be noted that where possible, the NDS Rest API service will be in turn, making REST calls to the other backend services that it is acting as a facade for.

  2. Matthew Turk

    I would suggest that the web app backend and frontend not be combined into a single repository, to avoid tying them too deeply and to ensure loosely-coupled microservices.  Additionally, I think that having service definitions that can be expressed as JSON would be ideal, since that's readily and easily parseable (and constructable) in a fully client-side app.