Latest revision as of 06:50, 4 May 2015

Document History
	Version	Date	Authors	Description	Validator	Validation Date
	0.1.0	TBC	Eudes, Rossi	TBC	TBC	TBC

1. Introduction

1.1 Purpose of the requirements document

This Software Requirements Specification (SRS) identifies the requirements for this datacenter's webUI. The purpose of this document is to easily explain the development of this project and to provide instructions to understand and use the software.

1.2 Scope of the product

The purpose of this project is to provide an userfriendly web interface to simulate and use a small datacenter. Each node of the datacenter can perform some operations, users can interact with a group of nodes or a specific one.

1.3 Definitions, acronyms and abbreviations

Frontend: intern server allowing to interact with OAR-docker
OAR: task and resources manager
Docker: virtualization tools, using containers' technologies
Containers: VMs sharing their OS, comprising only an application and its dependencies
Cluster: group of nodes link together
Node: calculating unit

1.4 References

Grid'5000
OAR OAR is a versatile resource and task manager (also called a batch scheduler) for HPC clusters and other computing infrastructures. It's used on Grid'5000.
OAR-docker: oar-docker is a set of docker images especially configured for deploying your own OAR cluster. The main idea is to have a mini development cluster with a frontend, a server and some nodes that launch in just a few seconds on a simple laptop.
API REST API for OAR
Boostrap CSS
Datatables JQuery plugin, allowing to use tables
JQuery Plugin Form JQuery plugin, allowing to check form

1.5 Overview of the remainder of the document

The SRS document includes 3 main chapters :

General description, which contains the general characteristics of the project and our implementation choices.
Specific requirements, which gives the main requirements of each function.
Product evolution, which details the different steps of implementation we chose.

2. General description

2.1 Product perspective

Our project is based on a simulated infrastructure provided by OAR-docker. This cluster is made up of nodes, which can be used by only one user at a time. Our goal is to product a webUI easily understandable and usable by non-developers. As OAR-docker is designed only to test locally sub-developments' step, our webUI is not appropriate for external access.

2.2 Product functions

With this interface, users will be able to manage each node, submit a job to a node, cancel a job, create or delete a node.

2.3 User characteristics

The user can interacts with the interface even if he does not know how to manage the resources or deal with jobs.

2.4 General constraints

We have to gain access to the simulation in a private environment where docker is installed.

2.5 Assumptions and dependencies

Web browser which can interpret AJAX

3. Specific requirements, covering functional, non-functional and interface requirements

3.1 Requirement X.Y.Z (in Structured Natural Language)

Function:

Gather information from several nodes
Post information on a webUI, available from a browser

Description:

Generate an interface allowing to check resources' states, create or delete nodes and jobs

Inputs:

Information about the nodes of OAR-docker's cluster, sent in a json format.

Source:

OAR API

Outputs:

A website

Destination:

Searchers' team

Action:

Create or delete nodes
Affect or suppress jobs

Non functional requirements:

Easily usable: no user experience required
Small: does only need a few mega octets of space
Safe: specific users can do specific actions
Ethic: free-software used

Pre-condition:

Software:

- OAR-docker

Post-condition:

Side-effects:

4. Product evolution

This webUI just use a part of what OAR-API can do, so it could be improved. Moreover, as OAR-docker is still in development, new functionalities can be added.

5. Appendices

This document is inspired of the IEEE/ANSI 830-1998 Standard.

References:

@@ Line 1: / Line 1: @@
+{|class="wikitable alternance"
+ |+ Document History
+ |-
+ |
+ !scope="col"| Version
+ !scope="col"| Date
+ !scope="col"| Authors
+ !scope="col"| Description
+ !scope="col"| Validator
+ !scope="col"| Validation Date
+ |-
+ !scope="row" |
+ | 0.1.0
+ | TBC
+ | Eudes, Rossi
+ | TBC
+ | TBC
+ | TBC
+ |}
@@ Line 9: / Line 29: @@
 Each node of the datacenter can perform some operations, users can interact with a group of nodes or a specific one.
 ==1.3   Definitions, acronyms and abbreviations==
-* node
+* Frontend: intern server allowing to interact with OAR-docker
-* datacenter
+* OAR: task and resources manager
-* frontend
+* Docker: virtualization tools, using containers' technologies
-* oar
+* Containers: VMs sharing their OS, comprising only an application and its dependencies
-* docker
+* Cluster: group of nodes link together
+* Node: calculating unit
 ==1.4   References==
-* [https://developer.nvidia.com/get-started-jetson Get Started Jetson TK1]
 * [https://www.grid5000.fr Grid'5000]
 * [http://oar.imag.fr OAR] OAR is a versatile resource and task manager (also called a batch scheduler) for HPC clusters and other computing infrastructures. It's used on Grid'5000.
-* [https://github.com/oar-team/oar-docker oar-docker]: oar-docker is a set of docker images especially configured for deploying your own OAR cluster. The main idea is to have a mini development cluster with a frontend, a server and some nodes that launch in just a few seconds on a simple laptop.
+* [https://github.com/oar-team/oar-docker OAR-docker]: oar-docker is a set of docker images especially configured for deploying your own OAR cluster. The main idea is to have a mini development cluster with a frontend, a server and some nodes that launch in just a few seconds on a simple laptop.
+* [http://oar.imag.fr/sources/2.5/docs/documentation/OAR-DOCUMENTATION-API-USER/ API REST] API for OAR
-* [http://kameleon.imag.fr/ Kameleon] : Kameleon is a simple but powerful tool to generate customized appliances.
+* [http://getbootstrap.com/ Boostrap ] CSS
+* [http://www.datatables.net/ Datatables ] JQuery plugin, allowing to use tables
+* [http://jquery.malsup.com/form/ JQuery Plugin Form] JQuery plugin, allowing to check form
 ==1.5   Overview of the remainder of the document==
 The SRS document includes 3 main chapters :
 * General description, which contains the general characteristics of the project and our implementation choices.
 * Specific requirements, which gives the main requirements of each function.
-* Product evolution, which details the differents steps of implementation we chose.
+* Product evolution, which details the different steps of implementation we chose.
 =2.   General description=
 ==2.1   Product perspective==
-Tout d'abord, notre projet se base sur une infrastructure simulée par OAR-docker. Cette infractructure contient divers noeuds, chacun exploitable par un un utilisateur à la fois.
+Our project is based on a simulated infrastructure provided by OAR-docker. This cluster is made up of nodes, which can be used by only one user at a time.
+Our goal is to product a webUI easily understandable and usable by non-developers.
-Notre but est de produire une interface web facilement utilisable et compréhensible par des non-initiés,
+As OAR-docker is designed only to test locally sub-developments' step, our webUI is not appropriate for external access.
 ==2.2   Product functions==
-With this interface, users will be able to manage each node, submit a job to a node, cancel a job, create a node or delete a node.
+With this interface, users will be able to manage each node, submit a job to a node, cancel a job, create or delete a node.
 [[File:Diagramme_contexte.bmp]]
 ==2.3   User characteristics==
+The user can interacts with the interface even if he does not know how to manage the resources or deal with jobs.
-L'utilisateur n'a pas besoin de connaître la façon dont s'instancie une ressource pour pouvoir utiliser l'interface.
 [[File:Diagramme_utilisateur.bmp]]
 ==2.4   General constraints==
+We have to gain access to the simulation in a private environment where docker is installed.
-accès à la simulation dnas un environnement privé
-OAR-docker installé
 ==2.5   Assumptions and dependencies==
+* Web browser which can interpret AJAX
-Chaque utilisateur ne travaille pas sur une même infrastructure, puisque les environnements sont privés.
+=3. Specific requirements, covering functional, non-functional and interface requirements=
+==3.1 Requirement X.Y.Z (in Structured Natural Language)==
+'''Function''':
+* Gather information from several nodes
+* Post information on a webUI, available from a browser
+'''Description''':
+* Generate an interface allowing to check resources' states, create or delete nodes and jobs
+'''Inputs''':
+* Information about the nodes of OAR-docker's cluster, sent in a json format.
+'''Source''':
+* OAR API
+'''Outputs''':
+* A website
+'''Destination''':
+* Searchers' team
+'''Action''':
+* Create or delete nodes
+* Affect or suppress jobs
+'''Non functional requirements''':
+* Easily usable: no user experience required
+* Small: does only need a few mega octets of space
+* Safe: specific users can do specific actions
+* Ethic: free-software used
+'''Pre-condition''':
+*Software:
+::- OAR-docker
+'''Post-condition''':
+'''Side-effects''':
-=3. Product evolution=
+=4. Product evolution=
-We can improve this webui, we just use a part of what OAR API can do.
+This webUI just use a part of what OAR-API can do, so it could be improved. Moreover, as OAR-docker is still in development, new functionalities can be added.
-=4. Appendices=
+=5. Appendices=
 This document is inspired of the IEEE/ANSI 830-1998 Standard.

Proj-2014-2015-Mini datacenter portail SRS: Difference between revisions