Proj-2014-2015-Mini datacenter portail

Objectif

Développer un portail pour une plate-forme d'expérimentation (oar-docker) en s'inspirant de la plate-forme Grid'5000.

Plus globalement cette action s'inscrit dans la partie DataCentre du projet d'éboration d'une plateforme pédagogique pour l'expérimentation sur des systèmes massivement distribués.

Nous voulons à terme fournir une interface web agréable à utiliser, permettant de gérer facilement une simulation de cluster.

Fiche SRS

Product Backlog

sources (archive zip, branche master du git )

Equipe

• Tuteur : Olivier Richard

• Membres: Robin EUDES , Ombeline ROSSI

• Département : RICM 4, Polytech Grenoble

Outils et Technologies

Outils et technologies utilisés :

• OAR
• OAR-Docker
• Boostrap
• PHP 5
• API REST (OARAPI)
• AJAX, librairie JQuery
• Datatables, un plugin JQuery pour manipuler des tableaux
• JQuery Form Plugin

Avancement du projet

Semaine 1 [13/01 - 18/01]

• Nous avons immédiatement décidé d'utiliser OAR-Docker, qui nous permet de générer directement un nombre donné de noeuds interconnectés.

Il nous a de ce fait fallu apprendre les bases nécessaires pour maîtriser OAR et OAR-Docker.

Nous avons contacté le développeur de ce dernier afin qu'il nous éclaire sur une ambiguïté pour l'installation de ce dernier.

Note : Il est nécessaire d'avoir un OS 64bits pour faire fonctionner OAR-docker.

Semaine 2 [19/01 - 25/01]

• Nous avons exécuté quelques premières modifications des fichiers fournis dans OAR-docker pour apprendre à maîtriser le logiciel.

• Une première version de la fiche SRS a également été écrite.

Semaine 3 [26/01 - 01/02]

• Complétion de la fiche SRS et de celle du projet.

• Un premier script minimal d'initialisation a été conçu et ajouté dans le git, afin de faciliter l'utilisation de OAR-Docker par des personnes non-initiées.

• `A ce niveau : l'utilisateur connait au démarrage de la simulation le nombre maximal de noeud qui lui faudra. ( voir semaine 6 )

• Recherche de sources précompilées de node.js car cela prend énormément de temps lors du lancement de la simulation.

Semaine 4 [02/02 - 08/02]

• Mise à jour de la fiche SRS

• Recherche d'informations sur l'utilisation de l'API d'OAR

• Suite à un souci avec (principalement) l'initialisation des noeuds et de la récupération de l'état des ressources, nous avons à nouveau contacté le développeur qui nous a indiqué avir effectué une mise à jour il y a quelques semaines. Depuis, nous avons ajouté une alerte sur ce dépot, pour ne pas manquer une mise à jour, et perdre du temps en debug.

• Update oar-docker vers la version 0.4.0 :

  Python3 support
  Prefixed all container outputs with the container hostname (like oardocker logs subcommand)
  Added --force-rm and --pull options to oardocker build subcommand
  Allowed user to build custom images with custom_setup.sh script located in .oardocker/images/<image_name>/
  Added a proper way to shutdown container
  Updated /etc/hosts when reseting containers
  Removed dockerpty package from dependencies
  Removed oardocker ssh/ssh-config subcommand
  Added --verbose option
  Fixed oardocker logs subcommand

Semaine 5 [09/02 - 15/02]

• Découverte des fonctions de bootstrap.

• Mise en forme de la page d'accueil du portail.

• Test des premières requêtes json vers l'API.

Semaine 6 [23/02 - 01/03]

• Update vers la version 0.4.3 d'oar-docker, apportant divers bug fixes :

   Added --debug option
   Set default docker API to 1.15 (#25)
   Workaround phpphadmin apache install
   Removed drawgantt-svg permissions errors (#23) [Salem Harrache]
   Fixed oardocker init subcommand (#22)
   Upload workdir to containers during the build
   Updated Dockerfiles to execute custom_setup.sh script

• Rajout d'informations sur les noeuds sur la page d'accueil et de pages séparées pour chaque noeud en particulier.

• Ajout d'identification nécessaire pour les utilisateurs.

• Ajout du waffle (scrum)

• Première approche pour la création de ressources à la volée ( après l'initialisation ) concluante : problème soulevé en Semaine 3 "résolu", de même pour la soumission d'un "job" à un noeud. Ces fonctionnalités seront ajoutées à la webui par la suite.

• Diverses réorganisations autour de la webui (contenu & mise en forme).

• L'initialisation de la webui (installation des composants nécessaires, clonage du git, etc) est désormais intégrée lors du build initial. Le script initialement développé (et exécuté à chaque instanciation du frontend ) est maintenant inclu dans le build, et donc exécuté une unique fois. Les composants n'ont plus besoin d'être réinstallé à chaque fois. Cette option est permise par l'éxécution d'un script "custom_setup.sh" lors du build.

Semaine 7 [02/03 - 08/03]

• Accélération de l'éxecution du custom_setup.sh pour le frontend, boostrap n'est plus installé à partir des sources. Les fichiers minimaux requis sont présents sur le git.

• De multiples corrections de bug dans info_node.php, qui donne une première vue générale des noeuds.

• Création de info_rsc.php, qui nous permet une vue détaillé d'un host particulier. Un host ( par exemple "node1" ) regroupe plusieurs ressources, chacune d'entre elle pouvant effectuer des calculs. Ainsi, connaitre les paramètres précis d'une ressource avant de lui soumettre un job est important.

• Formulaire de soumission de taches à une ressource fonctionnel (pour une commande uniquement, fichier script à venir).

• Gestion de diverses erreurs autour de la soumission de taches :

** paramètres minimaux manquants ( ressource visée, commande à effectuer )
** Authentification requise ( user : docker )

• Mise en place d'une page "errors.php" , pour gérer les affichages des diverses erreurs (lors du login, par exemple ).

• L'authentification est désormais réalisée via un formulaire, qui se charge de vérifier que les login/password concordent avec ceux inscrit dans le fichier /etc/oar/api-users .

** L'authentification sera requise uniquement pour les requêtes vers l'API qui le nécessitent.
** Si on est logué avec le mauvais utilisateur pour soumettre un job -> redirection vers errors.php avec un message explicatif.

• Réflexions autour de l'utilisation d'AJAX pour afficher des alertes en cas d'erreur / succès de diverses actions, plutôt qu'une redirection vers error.php ( qui elle même redirige vers différente pages suivant le type d'erreur.)

Semaine 8 [09/03 - 15/03]

• Réorganisation du Product Backlog, définitions de nouvelles taches.
• Version 1.0 de notre projet est presque aboutie :

  A first version with the following functionalities :
   - a proper identification
   - submit a simple job (command line ) to a resource
   - create a resource (without custom parameter, exept the host, for now )
   - a general view of the cluster

Cependant, un bug est encore présent, quand aux propriétés donnée au core que l'on souhaite créer. Pour l'instant, nous ne pouvons créer qu'une resource sans réel core/cpu associé.

  array(3) { ["title"]=> string(40) "SQL query failed into resources creation" ["message"]=> array(1) { [0]=> string(347) "Error: ERROR: column "properties" of relation "resources"
  does   not exist LINE 1: ...rces (resource_id,state,state_num,network_address,properties...
  ^Query: INSERT INTO resources (resource_id,state,state_num,network_address,properties) VALUES (15,'Alive',1,'new_node','HASH(0x36be8e8)')" } ["code"]=> int(500) }

En regardant le schéma de la DB dans laquelle sont stockés nos resources, nous ne comprenons pas l'origine de cette erreur. la requête json est probablement mal construite, nous travaillons au débug.

• Nous nous sommes par ailleurs penchés d'avantage sur l'architecture, en étudiant la documentation OAR

Ce schéma nous montre les relations "d'inclusion" : un core est dans un cpu, qui est dans un node, qui peut être dans un switch. Parce que nous sommes dans un environnement entièrement virtuel, nous pouvons donc construire des architecture complexe, aussi, nous devons veiller à la cohérence de chaque core, in fine. Ainsi, notre vue "gobale" actuelle n'est pas suffisamment adaptée, nous devons en priorité grouper les core d'un même CPU, et les CPU d'un même node ensemble. Cet objectif sera ajouté dans la version 1.1 de notre webui.

Par ailleurs, le retour sur soumission d'un job est encore très sommaire, nous devons encore améliorer cela. Notre interface n'est pas encore assez souple.

Semaine 9 [16/03 - 22/03]

• Utilisation de Datatable pour générer intégralement le contenu de info_node.php -> Réduction du code html "tapé manuellement" réduit au minimum.

• Corrections d'un bug sur le ciblage d'un core pour la soumission d'un job.

• Correction du bug autour de l'ajout d'une ressource. Utilisation de l'API. La documentation de cette dernière n'était pas à jour, ce qui nous a considérablement ralenti.

Semaine 10 [23/03 - 30/03]

• Ajout de la possibilité de supprimer une ressource

• Nettoyage du code

• Familiarisation avec javascript et l'AJAX.

Semaine 11 [31/03 - 06/04]

• Utilisation d'un plugin jquerry supplémentaire pour effectuer des vérifications sur les formulaires avant la soumission de ces derniers ( ce qui était auparavant effectué au niveau du PHP ). Librairie stokée localement pour limiter les accès réseaux.

• Les pages sont plus dynamiques, nous utilisons un event AJAX pour actualiser une section de la page, informant l'utilisateur du succès/echec de son action.

• Ajout de la liste des jobs courants

• Ajout possibilité suppression job.

• De façon générale, nous avons déporté au niveau du client ( par exécution de javascript ) des vérifications avant de soumettre des requêtes à l'API.

Semaine 12 [06/04 - 08/04]

• Finalisation du code

• Rédaction du rapport , des slides pour la présentation, bilan du projet.