air - User contributions [en]

Résultats - Gestionnaire de packages

2017-03-15T15:39:57Z

Thibaut.Nouguier: /* Perspectives d'évolutions */

[[Projet 2017 : Gestionnaire de packages Polytech| '''Page d'accueil du projet''']]
= Réalisations =
== Frontend ==
'''Authentification'''
* Authentification avec auth0

'''Visualisation des packages'''
* L'affichage des packages à partir de la base de données (API) est fonctionnelle.
* Les différents filtres pour trier les packages sont fonctionnels.
* La recherche par mots-clés est opérationnelle.

'''Visualisation des tickets'''
* Fonctionnement similaire à la visualisation des packages. Les fonctionnalités disponibles sont les mêmes.
* Un système de vote a été mis en place pour indiquer la "popularité" d'un package.
* Un bouton est affiché si l'utilisateur est administrateur.
* Le système de vote +/- est fonctionnel. L'utilisateur peut ajouter/supprimer/mettre à jour son vote.

'''Formulaire de dépôt d'un package'''
* Il est possible de remplir le formulaire pour ajouter un ticket. Le ticket est ajouté à la base de données sous forme d'un fichier JSON.

'''FAQ'''
* La page de FAQ est lue à partir de deux fichiers JSON contenant les différents tutoriels ainsi que les questions de la FAQ pour faciliter la modification du contenu en fonction des besoins des utilisateurs.

== Backend-controller ==
* Authentification avec auth0 et un token JWT propre à notre application
* Gestion complète du modèle défini pendant la phase de conception
* Tests automatiques du modèle de l'API (tests internes)
* Tests automatiques de l'interface REST de l'API (test externes)

== Backend-builder ==
Le builder gère les types de projet suivants :
* ant
* exécutables / binaires
* gradle
* makefile
* maven
et produit un package en conséquence.

= Perspectives d'évolutions =

== Frontend ==
* Implémenter dans la vue Tickets le système de tri par résultat des votes
* Les tickets créés ne sont pas liés au code joint dans le formulaire (tarball, git...). Il faut compléter la gestion du formulaire tout en faisant attention au soucis de sécurité lié à l'acquisition de code source.

== Backend-controller ==
* L'utilisation de mongodb implique que la gestion de clé étrangères doit être géré manuellement. Actuellement, les clés sont vérifiés lors de la création d'objets mais pas de leurs suppression. Des objets orphelins peuvent donc exister.
* Il a été choisi d'utiliser une base de donnée mongodb pour permettre l'upload d'archive (liés aux tickets) directement en base. Mais quel est le risque de sécurité lié ? Une reflexion sur l'intérêt de charger des fichiers plutôt que uniquement des liens est à considérer.

== Backend-builder ==
* Améliorer la modularité du builder en le rendant plus permissif.
* Ajouter d'autres types de projet tels que : CMake, SCons, Waf, ...

Résultats - Gestionnaire de packages

2017-03-15T15:38:50Z

Thibaut.Nouguier: /* Backend-builder */

Résultats - Gestionnaire de packages

2017-03-15T15:38:30Z

Thibaut.Nouguier: /* Réalisations */

[[Projet 2017 : Gestionnaire de packages Polytech| '''Page d'accueil du projet''']]
= Réalisations =
== Frontend ==
'''Authentification'''
* Authentification avec auth0

'''Visualisation des packages'''
* L'affichage des packages à partir de la base de données (API) est fonctionnelle.
* Les différents filtres pour trier les packages sont fonctionnels.
* La recherche par mots-clés est opérationnelle.

'''Visualisation des tickets'''
* Fonctionnement similaire à la visualisation des packages. Les fonctionnalités disponibles sont les mêmes.
* Un système de vote a été mis en place pour indiquer la "popularité" d'un package.
* Un bouton est affiché si l'utilisateur est administrateur.
* Le système de vote +/- est fonctionnel. L'utilisateur peut ajouter/supprimer/mettre à jour son vote.

'''Formulaire de dépôt d'un package'''
* Il est possible de remplir le formulaire pour ajouter un ticket. Le ticket est ajouté à la base de données sous forme d'un fichier JSON.

'''FAQ'''
* La page de FAQ est lue à partir de deux fichiers JSON contenant les différents tutoriels ainsi que les questions de la FAQ pour faciliter la modification du contenu en fonction des besoins des utilisateurs.

== Backend-controller ==
* Authentification avec auth0 et un token JWT propre à notre application
* Gestion complète du modèle défini pendant la phase de conception
* Tests automatiques du modèle de l'API (tests internes)
* Tests automatiques de l'interface REST de l'API (test externes)

== Backend-builder ==
* Le builder gère les types de projet suivants :
** ant
** exécutables / binaires
** gradle
** makefile
** maven
et produit un package en conséquence.

= Perspectives d'évolutions =

== Frontend ==
* Implémenter dans la vue Tickets le système de tri par résultat des votes
* Les tickets créés ne sont pas liés au code joint dans le formulaire (tarball, git...). Il faut compléter la gestion du formulaire tout en faisant attention au soucis de sécurité lié à l'acquisition de code source.

== Backend-controller ==
* L'utilisation de mongodb implique que la gestion de clé étrangères doit être géré manuellement. Actuellement, les clés sont vérifiés lors de la création d'objets mais pas de leurs suppression. Des objets orphelins peuvent donc exister.
* Il a été choisi d'utiliser une base de donnée mongodb pour permettre l'upload d'archive (liés aux tickets) directement en base. Mais quel est le risque de sécurité lié ? Une reflexion sur l'intérêt de charger des fichiers plutôt que uniquement des liens est à considérer.

Documentation - Gestionnaire de packages

2017-03-15T13:46:33Z

Thibaut.Nouguier:

[[Projet 2017 : Gestionnaire de packages Polytech| '''Page d'accueil du projet''']]

== Documentation pour le Backend Builder ==
https://github.com/Packebian/Backend-builder/blob/master/README.md

Documentation - Gestionnaire de packages

2017-03-15T13:46:17Z

Thibaut.Nouguier: Created page with "Documentation : Gestionnaire de package. '''Page d'accueil du projet''' == Documentation pour le Backend Builder == http..."

Documentation : Gestionnaire de package.

[[Projet 2017 : Gestionnaire de packages Polytech| '''Page d'accueil du projet''']]

== Documentation pour le Backend Builder ==
https://github.com/Packebian/Backend-builder/blob/master/README.md

Projet 2017 : Gestionnaire de packages Polytech

2017-03-15T13:45:10Z

Thibaut.Nouguier: /* Documentation */

[[Projets_2016-2017| '''Lien vers la page des projets RICM5''']]

= Objectif du projet =
Durant les 3 années de RICM, de nombreux logiciels et bibliothèques d'outils sont utilisés pour des TP et des projets. Beaucoup de temps est passé durant les séances de TP à installer tous ces outils sur les machines des étudiants. Pour résoudre ce problème, nous avons voulu travailler sur une solution permettant aux étudiants d'installer tous ces outils plus rapidement.

Le but de notre projet est d'établir un catalogue des outils nécessaires au cursus RICM, et de mettre à disposition des outils pour les enseignants pour qu'il puissent proposer eux mêmes des packages à installer.
Pour réaliser cela, nous avons décidé de créer un gestionnaire de package qui permet d'uniformiser l'installation des outils proposés par les enseignants, grâce à la création de packages Debian facilement déployables sur les machines Linux des étudiants.

= Équipe =
* Rémi Gattaz
* Germain Lecorps (Chef de Projet)
* Thibaut Nouguier
* Régis Ramel (Scrum Master)

= Documentation =
* [[Documentation - Gestionnaire de packages| '''Documentation''']]
* [[SRS - Gestionnaire de packages| '''SRS''']]
* [[Fiche de suivi - Gestionnaire de packages| '''Fiche de suivi''']]
* [[Scrum - Gestionnaire de packages| '''Scrum''']]
* [[Conception - Gestionnaire de packages| '''Conception''']]
* [[Maquette - Gestionnaire de packages| '''Maquette''']]
* [[Deploiement - Gestionnaire de packages| '''Déploiement''']]
* [[Management de projet innovant - Gestionnaire de packages| '''Management de projet innovant''']]
* [[Media:PackagesRappotBilan.pdf|'''Rapport de projet - MPI''']]
* [[Media:PackagesPresentationConception.pdf|'''Présentation intermédiaire''']]
* [[Media:PackagesPresentationFinale.pdf| '''Présentation finale''']]

= Liens du projet =
* [https://github.com/Packebian '''Dépôt Git''']
* [[Liens - Gestionnaire de packages| '''Liens utiles''']]

Fiche de suivi - Gestionnaire de packages

2017-03-13T17:25:01Z

Thibaut.Nouguier: /* Semaine 8 : 13/03 - 19/03 */

Voici la Fiche de suivi du Projet 2017 : Gestionnaire de package.

[[Projet 2017 : Gestionnaire de packages Polytech| '''Page d'accueil du projet''']]

= Équipe =
* Rémi Gattaz
* Germain Lecorps (Chef de Projet)
* Thibaut Nouguier
* Régis Ramel (Scrum Master)

= Avancée du projet =
== Semaine 1 : 23/01 - 29/01 ==
=== Lundi 23 Janvier ===
Travail de groupe :
* Formation du groupe
* Réflexion sur le sujet avec M. Donsez
* Envoi d'un mail explicatif à M. Palix et M. Danjean pour prise de rendez-vous
* Premières réflexions sur une solution de gestion de package

=== Mardi 24 Janvier ===
Travail de groupe :
* Réponse aux enseignants
* Design de la structure de l'application
Rémi Gattaz, Germain Lecorps et Thibaut Nouguier :
* Travail sur la doc sur les repository Debian
Régis Ramel :
* Travail sur le Wiki

=== Mercredi 25 Janvier ===
Travail de groupe :
* Entretiens avec M. Palix et M. Danjean pour préciser les exigences du projet, discuter des différentes possibilités et de ce qu'il est possible / intéressant de faire.
* Formalisation des objectifs du projet.

=== Jeudi 26 Janvier ===
Travail de groupe :
* Première séance de MPI : Description du projet, définition des rôles, exercice de map minder
Rémi Gattaz et Thibaut Nouguier :
* POC de création de package et d'application d'un fix
Germain Lecorps:
* Travail sur le Wiki : SRS
Régis Ramel :
* Envoi de la définition du sujet aux enseignants
* Constitution d'une liste de mail des enseignants pour obtenir la liste des outils nécessaires en RICM
* Envoi de la demande de recensement des outils requis en RICM

== Semaine 2 : 30/01 - 05/02 ==
=== Lundi 30 Janvier ===
Travail de groupe :
* Choix des technologies : Debian + langage de script.

=== Mardi 31 Janvier ===
Travail de groupe :
* Discussion pour le choix des langages : Python et Shell.
* Conception de la structure détaillée de l'application

Thibaut Nouguier :
* Création d'un repository local avec des packages Debian basiques (Reprepro)
* Installation des paquets Debian depuis le repository local
* Sécurisation du repository via des clés RSA

Rémi Gattaz :
* Recherches sur Reprepro
* Utilisation de Reprepro dans un container docker (pour environnement de dev)
* Interview par les étudiants PEIP

Régis Ramel :
* Mise au propre de la structure de l'application
* Travail sur le Wiki : Conception de l'application
* Travail sur le SRS : Fonctionnement de l'application

Germain Lecorps :
* Préparation de l’environnement de développement Web

=== Mercredi 01 Février ===

Thibaut Nouguier :
* Recherches complémentaires sur l'utilisateion de reprepro
* Simulation d'un cas d'utilisation avec reprepro en utilisant des clés GPG (master key, signing key, encryption key)

Rémi Gattaz :
* Recherches sur Aptly
* Utilisation de Aptly dans un container docker (pour environnement de dev)

Régis Ramel :
* Travail sur la structure de l'application
* Travail sur le Wiki
* Installation de Netbeans pour HTML5/Javascript

Germain Lecorps :
* [[Maquette - Gestionnaire de packages| '''Maquettes''']] de l'interface Web

=== Jeudi 02 Février ===
Travail de groupe :
* Deuxième séance de MPI : Exercice de Brainstorming, exercice de pitch

Rémi Gattaz et Thibaut Nouguier :
* Définition des actions du Controleur et de l'API

Thibaut Nouguier :
* Travail sur la base de données MySQL

Rémi Gattaz :
* Définition des routes offerte par l'API du contrôleur dans le backend - [[Conception - Gestionnaire de packages#API_offerte_par_le_contr.C3.B4leur | '''documentation''']]

Germain Lecorps :
* Formation Angular

=== Vendredi 03 Février ===
Rémi Gattaz et Thibaut Nouguier :
* Mise en place du scrum (définition des user stories et des tâches)

Rémi Gattaz :
* Ajout des user stories et des tâches dans le wiki
* Création du tableau scrum sur github

Germain Lecorps :
* Formation Angular.js

== Semaine 3 : 06/02 - 12/02 ==
=== Lundi 06 Février ===
Travail de groupe :
* Troisième séance de MPI : Matrice de risques et Coût du budget
* Revue de sprint, définition des objectifs du sprint 2

Rémi Gattaz :

Germain Lecorps :
* Travail sur le sprint Scrum
* Tutoriel Angular
* Formation Web
* Installation des outils
* Ébauche de site internet

Thibaut Nouguier :
* Travail sur le Builder de package

Régis Ramel :
* Travail sur le wiki : (Fiche de Suivi, Scrum, MPI)
* Travail sur le sprint Scrum
* Création d'un nouveau projet Angular
* Push du projet Angular sur GitHub
* Travail sur un modèle de projet Angular (liens vers d'autres pages)

=== Mardi 07 Février ===
Thibaut Nouguier :
* Première version d'un Builder de package qui fonctionne pour :
** un ensemble de fichiers c avec un makefile
** un script

Rémi Gattaz :
* NetBeans Day
* Terminer composition environnement backend controller

Germain Lecorps et Régis Ramel :
* Travail sur l'interface Web

=== Mercredi 08 Février ===
Thibaut Nouguier :
* Travail sur le Builder de package

Régis Ramel :
* Travail sur l'interface Web : génération d'une FAQ
* Travail sur l'interface Web : amélioration de la page de login

Germain Lecorps :
* Formation Web
* Travail sur l'interface Web : Création du formulaire de Contribution

Rémi Gattaz:
* Mise en place de tests sur le Backend-controller

=== Jeudi 09 Février ===
Thibaut Nouguier :
* Travail sur le Builder de package

Rémi Gattaz:
* Mise en place de tests sur le Backend-controller (suite du travail de la veille)

Régis Ramel :
* Travail sur l'interface Web : dynamicité de l'affichage des liens
* Travail sur le Wiki

Germain Lecorps :
* Travail sur le Frontend

=== Vendredi 10 Février ===
Thibaut Nouguier :
* Travail sur le Builder de package

Rémi Gattaz:
* Automatisation des tests du Backen-controller à chaque commit

Régis Ramel :
* Travail sur l'interface Web
* Travail sur la séance de MPI : calcul des coûts
* Travail sur la séance de MPI : préparation de la séance sur la communication interpersonelle

Germain Lecorps :
* Travail sur le FrontEnd

== Semaine 4 : 13/02 - 19/02 ==
=== Lundi 13 Février ===
Travail de groupe :
* Réunion pour définir les objectifs de la semaine en vue de la soutenance de mi-parcours

Thibaut Nouguier :
* Travail sur le Builder de package

Rémi Gattaz :
* Travail sur notre modèle de modélisation des données (refonte de la BDD)
* Prise de rendez vous avec le Responsable du service informatique de Polytech

Régis Ramel :
* Travail sur le cout du projet : Main d'oeuvre, amortissement du matériel

Germain Lecorps :
* Travail sur le FrontEnd
* Formation sur le filtrage en angularjs

=== Mardi 14 Février ===
Travail de groupe :
* Quatrième séance de MPI : Communication interpersonnelles

Rémi Gattaz :
* Travail dans le controller backend
** Création des classes modèle Ticket, Package et Infos.
** Mise en place des routes /packages et /tickets
** Mise en place des liens dans le modèle
** Création du CRUD au travers de l'API REST sur les ressources Package et Ticket

Régis Ramel et Germain Lecorps :
* Travail sur la lecture des packages en Json

Thibaut Nouguier :
* Travail sur le Builder de package

=== Mercredi 15 Février ===
Rémi Gattaz et Régis Ramel :
* Rencontre avec M. Jean-Marc Palomares, responsable du CAS de l'UGA

Régis Ramel et Germain Lecorps :
* Travail sur le FrontEnd
** Filtrage sur la liste des packages
** Début de filtrage "complexe" sur ces packages

Rémi Gattaz :
* Découverte d'un problème avec mysql et waterline (absence de transaction)
* Remaniement de la BDD pour une migration de mysql vers mongodb
* Migration vers mongodb

Thibaut Nouguier :
* Travail sur le Builder de package

=== Jeudi 16 Février ===
Travail de groupe :
* Revue de sprint

Régis Ramel et Germain Lecorps :
* Travail sur le FrontEnd
** Filtrage "complexe" sur la liste des packages
** Ajout de la liste des tickets
** Modification de la lecture des Json pour suivre le nouveau

Rémi Gattaz :
* Fin de la migration vers mongo
* Complétion de l'API nécessaire à la complétion du Frontend

Thibaut Nouguier :
* Travail sur le Builder de package

=== Vendredi 17 Février ===
Travail de groupe :
* Soutenance de mi-parcours

Régis Ramel :
* Correction mineure sur l'interface Web

== Semaine 5 : 20/02 - 26/02 (Vacances) ==
=== Lundi 20 Février ===

=== Mardi 21 Février ===

=== Mercredi 22 Février ===
Rémi Gattaz :
* Ajout de l'appel tickets/:id/votes/results pour obtenir le score d'un ticket (upvotes, downvotes, neutres)
* Ajout de tests du modèle

=== Jeudi 23 Février ===
Rémi Gattaz :
* Completion des tests du model du Backend-controller

=== Vendredi 24 Février ===
Rémi Gattaz :
* Construction automatique de l'image docker du Backend-controller
* Mise à jour du projet Backend-controller-env pour utiliser cette image
* Mise en place de la création de la base Mongo à la création du container (utilisation de variables d'environnement)

=== Samedi 25 Février ===
Rémi Gattaz :
* Test de l'écriture de la documentation avec Swagger
* Début de l'écriture de la documentation avec API Blueprint

== Semaine 6 : 27/02 - 05/03 ==
=== Lundi 27 Février ===
Germain Lecorps et Régis Ramel :
* Travail sur l'interface Web : Préparation de l'intégration de l'API

Régis Ramel :
* Travail sur le lancement de l'image docker du Backend-Controller-env

Rémi Gattaz :
* Documentation de l'API
* Tentative de résolution d'un problème de synchronisation dans l'API (une fonction asynchrone devait être appelée depuis une fonction synchrone du framework qui a été surchargée)

Thibaut Nouguier :
* Travail sur la création d'une image docker pour aptly

=== Mardi 28 Février ===
Rémi Gattaz :
* Résolution du problème de la veille
* Fin de l'écriture de la documentation
* Validation de la version 1.0 de l'API

Thibaut Nouguier :
* Travail sur la création d'une image docker pour aptly
* Renseignement sur chroot pour le builder

Régis Ramel :
* Lancement de l'image Docker du Backend-Controller-env
* Travail sur le lancement de l'API en local pour intégrer au FrontEnd
* Début d'intégration de l'API au FrontEnd

Germain Lecorps :
* Réinstallation de l’environnement suite à un bug inconnu

=== Mercredi 01 Mars ===

Thibaut Nouguier :
* Travail sur le builder de package

Régis Ramel & Germain Lecorps :
* Travail sur l'intégration de l'API

Rémi Gattaz :
* Début mise en place de tests avec dredd pour tester l'API du backend avec sa description

=== Jeudi 02 Mars ===
Rémi Gattaz :
* Suite de la mise en place de tests avec dredd pour tester l'API du backend avec sa description

Thibaut Nouguier :
* Test du builder avec des scripts comme sources
* Packaging de Procesim pour les RICM3
* Correction de plusieurs erreurs du builder

Régis Ramel & Germain Lecorps :
* Travail sur l'interface Web : Intégration de l'API et correction des modules Angular

=== Vendredi 03 Mars ===
Rémi Gattaz :
* Complétion de la mise en place de tests avec dredd pour tester l'API du backend avec sa description
* Utilisation d'un environnement unique pour effectuer le développement, la production, les tests dredd et les tests mocha (tests du model)

Thibaut Nouguier :
* Travail sur le builder de package
* Test du builder avec un projet maven

Régis Ramel & Germain Lecorps :
* Travail sur l'interface Web : Intégration de l'API et correction des modules Angular

== Semaine 7 : 06/03 - 12/03 ==
=== Lundi 06 Mars ===
Travail de groupe :
* Revue du 3e sprint

Régis Ramel et Germain Lecorps :
* Travail sur l'interface Web : intégration de l'API (création/modification d'un vote)

Thibaut Nouguier :
* Travail sur le builder

Rémi Gattaz :
* Travail sur le backend
** Correction d'un bug lié au calcul des résultat des votes

=== Mardi 07 Mars ===
Travail de groupe :
* Création [http://air.imag.fr/images/5/5e/PackagesRappotBilan.pdf '''du dossier MPI''']

Régis Ramel et Germain Lecorps :
* Travail sur l'interface Web : implémentation du système de votes

Thibaut Nouguier :
* Travail sur le builder

Rémi Gattaz :
* Travail sur le Frontend
** Refactoring

=== Mercredi 08 Mars ===
Régis Ramel et Germain Lecorps :
* Travail sur l'interface Web : implémentation du système de votes

Thibaut Nouguier :
* Travail sur le builder

Rémi Gattaz :
* Travail sur le Frontend.
** Création de services
** Début mise en place du login avec auth0

=== Jeudi 09 Mars ===
Régis Ramel et Germain Lecorps :
* Travail sur l'interface Web : implémentation du formulaire de contibution

Rémi Gattaz :
* Participation à l'Eclipse IOT Day

=== Vendredi 10 Mars ===
Régis Ramel et Germain Lecorps :
* Travail sur l'interface Web : implémentation du formulaire de contribution

Thibaut Nouguier :
* Travail sur le builder

Rémi Gattaz :
* Travail sur le Frontend.
** Mise en place du login avec auth0
* Travail sur la Backend-controller
** Mise en place du login avec auth0

== Semaine 8 : 13/03 - 19/03 ==
=== Lundi 13 Mars ===
Régis Ramel et Germain Lecorps :
* Travail sur l'interface Web : finalisation du formulaire de contribution
* Travail sur l'interface Web : Commentaire du code HTML

Thibaut Nouguier :
* Version 2.0 du builder permettant l'implémentation d'un nouveau type de projet plus facilement
* Modification de chaque cas en conséquences de la nouvelle version du builder
* Commentaire du code

=== Mardi 14 Mars ===

=== Mercredi 15 Mars ===

=== Jeudi 16 Mars ===

== Fin du Projet ==

Fiche de suivi - Gestionnaire de packages

2017-03-13T17:24:36Z

Thibaut.Nouguier: /* Vendredi 17 Mars */

Fiche de suivi - Gestionnaire de packages

2017-03-13T17:23:49Z

Thibaut.Nouguier: /* Lundi 13 Mars */

Fiche de suivi - Gestionnaire de packages

2017-03-10T09:45:49Z

Thibaut.Nouguier: /* Semaine 7 : 06/03 - 12/03 */

Voici la Fiche de suivi du Projet 2017 : Gestionnaire de package.

[[Projet 2017 : Gestionnaire de packages Polytech| '''Page d'accueil du projet''']]

= Équipe =
* Rémi Gattaz
* Germain Lecorps (Chef de Projet)
* Thibaut Nouguier
* Régis Ramel (Scrum Master)

= Avancée du projet =
== Semaine 1 : 23/01 - 29/01 ==
=== Lundi 23 Janvier ===
Travail de groupe :
* Formation du groupe
* Réflexion sur le sujet avec M. Donsez
* Envoi d'un mail explicatif à M. Palix et M. Danjean pour prise de rendez-vous
* Premières réflexions sur une solution de gestion de package

=== Mardi 24 Janvier ===
Travail de groupe :
* Réponse aux enseignants
* Design de la structure de l'application
Rémi Gattaz, Germain Lecorps et Thibaut Nouguier :
* Travail sur la doc sur les repository Debian
Régis Ramel :
* Travail sur le Wiki

=== Mercredi 25 Janvier ===
Travail de groupe :
* Entretiens avec M. Palix et M. Danjean pour préciser les exigences du projet, discuter des différentes possibilités et de ce qu'il est possible / intéressant de faire.
* Formalisation des objectifs du projet.

=== Jeudi 26 Janvier ===
Travail de groupe :
* Première séance de MPI : Description du projet, définition des rôles, exercice de map minder
Rémi Gattaz et Thibaut Nouguier :
* POC de création de package et d'application d'un fix
Germain Lecorps:
* Travail sur le Wiki : SRS
Régis Ramel :
* Envoi de la définition du sujet aux enseignants
* Constitution d'une liste de mail des enseignants pour obtenir la liste des outils nécessaires en RICM
* Envoi de la demande de recensement des outils requis en RICM

== Semaine 2 : 30/01 - 05/02 ==
=== Lundi 30 Janvier ===
Travail de groupe :
* Choix des technologies : Debian + langage de script.

=== Mardi 31 Janvier ===
Travail de groupe :
* Discussion pour le choix des langages : Python et Shell.
* Conception de la structure détaillée de l'application

Thibaut Nouguier :
* Création d'un repository local avec des packages Debian basiques (Reprepro)
* Installation des paquets Debian depuis le repository local
* Sécurisation du repository via des clés RSA

Rémi Gattaz :
* Recherches sur Reprepro
* Utilisation de Reprepro dans un container docker (pour environnement de dev)
* Interview par les étudiants PEIP

Régis Ramel :
* Mise au propre de la structure de l'application
* Travail sur le Wiki : Conception de l'application
* Travail sur le SRS : Fonctionnement de l'application

Germain Lecorps :
* Préparation de l’environnement de développement Web

=== Mercredi 01 Février ===

Thibaut Nouguier :
* Recherches complémentaires sur l'utilisateion de reprepro
* Simulation d'un cas d'utilisation avec reprepro en utilisant des clés GPG (master key, signing key, encryption key)

Rémi Gattaz :
* Recherches sur Aptly
* Utilisation de Aptly dans un container docker (pour environnement de dev)

Régis Ramel :
* Travail sur la structure de l'application
* Travail sur le Wiki
* Installation de Netbeans pour HTML5/Javascript

Germain Lecorps :
* [[Maquette - Gestionnaire de packages| '''Maquettes''']] de l'interface Web

=== Jeudi 02 Février ===
Travail de groupe :
* Deuxième séance de MPI : Exercice de Brainstorming, exercice de pitch

Rémi Gattaz et Thibaut Nouguier :
* Définition des actions du Controleur et de l'API

Thibaut Nouguier :
* Travail sur la base de données MySQL

Rémi Gattaz :
* Définition des routes offerte par l'API du contrôleur dans le backend - [[Conception - Gestionnaire de packages#API_offerte_par_le_contr.C3.B4leur | '''documentation''']]

Germain Lecorps :
* Formation Angular

=== Vendredi 03 Février ===
Rémi Gattaz et Thibaut Nouguier :
* Mise en place du scrum (définition des user stories et des tâches)

Rémi Gattaz :
* Ajout des user stories et des tâches dans le wiki
* Création du tableau scrum sur github

Germain Lecorps :
* Formation Angular.js

== Semaine 3 : 06/02 - 12/02 ==
=== Lundi 06 Février ===
Travail de groupe :
* Troisième séance de MPI : Matrice de risques et Coût du budget
* Revue de sprint, définition des objectifs du sprint 2

Rémi Gattaz :

Germain Lecorps :
* Travail sur le sprint Scrum
* Tutoriel Angular
* Formation Web
* Installation des outils
* Ébauche de site internet

Thibaut Nouguier :
* Travail sur le Builder de package

Régis Ramel :
* Travail sur le wiki : (Fiche de Suivi, Scrum, MPI)
* Travail sur le sprint Scrum
* Création d'un nouveau projet Angular
* Push du projet Angular sur GitHub
* Travail sur un modèle de projet Angular (liens vers d'autres pages)

=== Mardi 07 Février ===
Thibaut Nouguier :
* Première version d'un Builder de package qui fonctionne pour :
** un ensemble de fichiers c avec un makefile
** un script

Rémi Gattaz :
* NetBeans Day
* Terminer composition environnement backend controller

Germain Lecorps et Régis Ramel :
* Travail sur l'interface Web

=== Mercredi 08 Février ===
Thibaut Nouguier :
* Travail sur le Builder de package

Régis Ramel :
* Travail sur l'interface Web : génération d'une FAQ
* Travail sur l'interface Web : amélioration de la page de login

Germain Lecorps :
* Formation Web
* Travail sur l'interface Web : Création du formulaire de Contribution

Rémi Gattaz:
* Mise en place de tests sur le Backend-controller

=== Jeudi 09 Février ===
Thibaut Nouguier :
* Travail sur le Builder de package

Rémi Gattaz:
* Mise en place de tests sur le Backend-controller (suite du travail de la veille)

Régis Ramel :
* Travail sur l'interface Web : dynamicité de l'affichage des liens
* Travail sur le Wiki

Germain Lecorps :
* Travail sur le Frontend

=== Vendredi 10 Février ===
Thibaut Nouguier :
* Travail sur le Builder de package

Rémi Gattaz:
* Automatisation des tests du Backen-controller à chaque commit

Régis Ramel :
* Travail sur l'interface Web
* Travail sur la séance de MPI : calcul des coûts
* Travail sur la séance de MPI : préparation de la séance sur la communication interpersonelle

Germain Lecorps :
* Travail sur le FrontEnd

== Semaine 4 : 13/02 - 19/02 ==
=== Lundi 13 Février ===
Travail de groupe :
* Réunion pour définir les objectifs de la semaine en vue de la soutenance de mi-parcours

Thibaut Nouguier :
* Travail sur le Builder de package

Rémi Gattaz :
* Travail sur notre modèle de modélisation des données (refonte de la BDD)
* Prise de rendez vous avec le Responsable du service informatique de Polytech

Régis Ramel :
* Travail sur le cout du projet : Main d'oeuvre, amortissement du matériel

Germain Lecorps :
* Travail sur le FrontEnd
* Formation sur le filtrage en angularjs

=== Mardi 14 Février ===
Travail de groupe :
* Quatrième séance de MPI : Communication interpersonnelles

Rémi Gattaz :
* Travail dans le controller backend
** Création des classes modèle Ticket, Package et Infos.
** Mise en place des routes /packages et /tickets
** Mise en place des liens dans le modèle
** Création du CRUD au travers de l'API REST sur les ressources Package et Ticket

Régis Ramel et Germain Lecorps :
* Travail sur la lecture des packages en Json

Thibaut Nouguier :
* Travail sur le Builder de package

=== Mercredi 15 Février ===
Rémi Gattaz et Régis Ramel :
* Rencontre avec M. Jean-Marc Palomares, responsable du CAS de l'UGA

Régis Ramel et Germain Lecorps :
* Travail sur le FrontEnd
** Filtrage sur la liste des packages
** Début de filtrage "complexe" sur ces packages

Rémi Gattaz :
* Découverte d'un problème avec mysql et waterline (absence de transaction)
* Remaniement de la BDD pour une migration de mysql vers mongodb
* Migration vers mongodb

Thibaut Nouguier :
* Travail sur le Builder de package

=== Jeudi 16 Février ===
Travail de groupe :
* Revue de sprint

Régis Ramel et Germain Lecorps :
* Travail sur le FrontEnd
** Filtrage "complexe" sur la liste des packages
** Ajout de la liste des tickets
** Modification de la lecture des Json pour suivre le nouveau

Rémi Gattaz :
* Fin de la migration vers mongo
* Complétion de l'API nécessaire à la complétion du Frontend

Thibaut Nouguier :
* Travail sur le Builder de package

=== Vendredi 17 Février ===
Travail de groupe :
* Soutenance de mi-parcours

Régis Ramel :
* Correction mineure sur l'interface Web

== Semaine 5 : 20/02 - 26/02 (Vacances) ==
=== Lundi 20 Février ===

=== Mardi 21 Février ===

=== Mercredi 22 Février ===
Rémi Gattaz :
* Ajout de l'appel tickets/:id/votes/results pour obtenir le score d'un ticket (upvotes, downvotes, neutres)
* Ajout de tests du modèle

=== Jeudi 23 Février ===
Rémi Gattaz :
* Completion des tests du model du Backend-controller

=== Vendredi 24 Février ===
Rémi Gattaz :
* Construction automatique de l'image docker du Backend-controller
* Mise à jour du projet Backend-controller-env pour utiliser cette image
* Mise en place de la création de la base Mongo à la création du container (utilisation de variables d'environnement)

=== Samedi 25 Février ===
Rémi Gattaz :
* Test de l'écriture de la documentation avec Swagger
* Début de l'écriture de la documentation avec API Blueprint

== Semaine 6 : 27/02 - 05/03 ==
=== Lundi 27 Février ===
Germain Lecorps et Régis Ramel :
* Travail sur l'interface Web : Préparation de l'intégration de l'API

Régis Ramel :
* Travail sur le lancement de l'image docker du Backend-Controller-env

Rémi Gattaz :
* Documentation de l'API
* Tentative de résolution d'un problème de synchronisation dans l'API (une fonction asynchrone devait être appelée depuis une fonction synchrone du framework qui a été surchargée)

Thibaut Nouguier :
* Travail sur la création d'une image docker pour aptly

=== Mardi 28 Février ===
Rémi Gattaz :
* Résolution du problème de la veille
* Fin de l'écriture de la documentation
* Validation de la version 1.0 de l'API

Thibaut Nouguier :
* Travail sur la création d'une image docker pour aptly
* Renseignement sur chroot pour le builder

Régis Ramel :
* Lancement de l'image Docker du Backend-Controller-env
* Travail sur le lancement de l'API en local pour intégrer au FrontEnd
* Début d'intégration de l'API au FrontEnd

Germain Lecorps :
* Réinstallation de l’environnement suite à un bug inconnu

=== Mercredi 01 Mars ===

Thibaut Nouguier :
* Travail sur le builder de package

Régis Ramel & Germain Lecorps :
* Travail sur l'intégration de l'API

Rémi Gattaz :
* Début mise en place de tests avec dredd pour tester l'API du backend avec sa description

=== Jeudi 02 Mars ===
Rémi Gattaz :
* Suite de la mise en place de tests avec dredd pour tester l'API du backend avec sa description

Thibaut Nouguier :
* Test du builder avec des scripts comme sources
* Packaging de Procesim pour les RICM3
* Correction de plusieurs erreurs du builder

Régis Ramel & Germain Lecorps :
* Travail sur l'interface Web : Intégration de l'API et correction des modules Angular

=== Vendredi 03 Mars ===
Rémi Gattaz :
* Complétion de la mise en place de tests avec dredd pour tester l'API du backend avec sa description
* Utilisation d'un environnement unique pour effectuer le développement, la production, les tests dredd et les tests mocha (tests du model)

Thibaut Nouguier :
* Travail sur le builder de package
* Test du builder avec un projet maven

Régis Ramel & Germain Lecorps :
* Travail sur l'interface Web : Intégration de l'API et correction des modules Angular

== Semaine 7 : 06/03 - 12/03 ==
=== Lundi 06 Mars ===
Travail de groupe :
* Revue du 3e sprint

Régis Ramel et Germain Lecorps :
* Travail sur l'interface Web : intégration de l'API (création/modification d'un vote)

Thibaut Nouguier
* Travail sur le builder

=== Mardi 07 Mars ===
Thibaut Nouguier
* Travail sur le builder

=== Mercredi 08 Mars ===
Thibaut Nouguier
* Travail sur le builder

=== Jeudi 09 Mars ===

=== Vendredi 10 Mars ===
Thibaut Nouguier
* Travail sur le builder

== Semaine 8 : 13/03 - 19/03 ==
=== Lundi 13 Mars ===

=== Mardi 14 Mars ===

=== Mercredi 15 Mars ===

=== Jeudi 16 Mars ===

=== Vendredi 17 Mars ===

Fiche de suivi - Gestionnaire de packages

2017-03-03T08:29:14Z

Thibaut.Nouguier: /* Semaine 6 : 27/02 - 05/03 */

Voici la Fiche de suivi du Projet 2017 : Gestionnaire de package.

[[Projet 2017 : Gestionnaire de packages Polytech| '''Page d'accueil du projet''']]

= Équipe =
* Rémi Gattaz
* Germain Lecorps (Chef de Projet)
* Thibaut Nouguier
* Régis Ramel (Scrum Master)

= Avancée du projet =
== Semaine 1 : 23/01 - 29/01 ==
=== Lundi 23 Janvier ===
Travail de groupe :
* Formation du groupe
* Réflexion sur le sujet avec M. Donsez
* Envoi d'un mail explicatif à M. Palix et M. Danjean pour prise de rendez-vous
* Premières réflexions sur une solution de gestion de package

=== Mardi 24 Janvier ===
Travail de groupe :
* Réponse aux enseignants
* Design de la structure de l'application
Rémi Gattaz, Germain Lecorps et Thibaut Nouguier :
* Travail sur la doc sur les repository Debian
Régis Ramel :
* Travail sur le Wiki

=== Mercredi 25 Janvier ===
Travail de groupe :
* Entretiens avec M. Palix et M. Danjean pour préciser les exigences du projet, discuter des différentes possibilités et de ce qu'il est possible / intéressant de faire.
* Formalisation des objectifs du projet.

=== Jeudi 26 Janvier ===
Travail de groupe :
* Première séance de MPI : Description du projet, définition des rôles, exercice de map minder
Rémi Gattaz et Thibaut Nouguier :
* POC de création de package et d'application d'un fix
Germain Lecorps:
* Travail sur le Wiki : SRS
Régis Ramel :
* Envoi de la définition du sujet aux enseignants
* Constitution d'une liste de mail des enseignants pour obtenir la liste des outils nécessaires en RICM
* Envoi de la demande de recensement des outils requis en RICM

== Semaine 2 : 30/01 - 05/02 ==
=== Lundi 30 Janvier ===
Travail de groupe :
* Choix des technologies : Debian + langage de script.

=== Mardi 31 Janvier ===
Travail de groupe :
* Discussion pour le choix des langages : Python et Shell.
* Conception de la structure détaillée de l'application

Thibaut Nouguier :
* Création d'un repository local avec des packages Debian basiques (Reprepro)
* Installation des paquets Debian depuis le repository local
* Sécurisation du repository via des clés RSA

Rémi Gattaz :
* Recherches sur Reprepro
* Utilisation de Reprepro dans un container docker (pour environnement de dev)
* Interview par les étudiants PEIP

Régis Ramel :
* Mise au propre de la structure de l'application
* Travail sur le Wiki : Conception de l'application
* Travail sur le SRS : Fonctionnement de l'application

Germain Lecorps :
* Préparation de l’environnement de développement Web

=== Mercredi 01 Février ===

Thibaut Nouguier :
* Recherches complémentaires sur l'utilisateion de reprepro
* Simulation d'un cas d'utilisation avec reprepro en utilisant des clés GPG (master key, signing key, encryption key)

Rémi Gattaz :
* Recherches sur Aptly
* Utilisation de Aptly dans un container docker (pour environnement de dev)

Régis Ramel :
* Travail sur la structure de l'application
* Travail sur le Wiki
* Installation de Netbeans pour HTML5/Javascript

Germain Lecorps :
* [[Maquette - Gestionnaire de packages| '''Maquettes''']] de l'interface Web

=== Jeudi 02 Février ===
Travail de groupe :
* Deuxième séance de MPI : Exercice de Brainstorming, exercice de pitch

Rémi Gattaz et Thibaut Nouguier :
* Définition des actions du Controleur et de l'API

Thibaut Nouguier :
* Travail sur la base de données MySQL

Rémi Gattaz :
* Définition des routes offerte par l'API du contrôleur dans le backend - [[Conception - Gestionnaire de packages#API_offerte_par_le_contr.C3.B4leur | '''documentation''']]

Germain Lecorps :
* Formation Angular

=== Vendredi 03 Février ===
Rémi Gattaz et Thibaut Nouguier :
* Mise en place du scrum (définition des user stories et des tâches)

Rémi Gattaz :
* Ajout des user stories et des tâches dans le wiki
* Création du tableau scrum sur github

Germain Lecorps :
* Formation Angular.js

== Semaine 3 : 06/02 - 12/02 ==
=== Lundi 06 Février ===
Travail de groupe :
* Troisième séance de MPI : Matrice de risques et Coût du budget
* Revue de sprint, définition des objectifs du sprint 2

Rémi Gattaz :

Germain Lecorps :
* Travail sur le sprint Scrum
* Tutoriel Angular
* Formation Web
* Installation des outils
* Ébauche de site internet

Thibaut Nouguier :
* Travail sur le Builder de package

Régis Ramel :
* Travail sur le wiki : (Fiche de Suivi, Scrum, MPI)
* Travail sur le sprint Scrum
* Création d'un nouveau projet Angular
* Push du projet Angular sur GitHub
* Travail sur un modèle de projet Angular (liens vers d'autres pages)

=== Mardi 07 Février ===
Thibaut Nouguier :
* Première version d'un Builder de package qui fonctionne pour :
** un ensemble de fichiers c avec un makefile
** un script

Rémi Gattaz :
* NetBeans Day
* Terminer composition environnement backend controller

Germain Lecorps et Régis Ramel :
* Travail sur l'interface Web

=== Mercredi 08 Février ===
Thibaut Nouguier :
* Travail sur le Builder de package

Régis Ramel :
* Travail sur l'interface Web : génération d'une FAQ
* Travail sur l'interface Web : amélioration de la page de login

Germain Lecorps :
* Formation Web
* Travail sur l'interface Web : Création du formulaire de Contribution

Rémi Gattaz:
* Mise en place de tests sur le Backend-controller

=== Jeudi 09 Février ===
Thibaut Nouguier :
* Travail sur le Builder de package

Rémi Gattaz:
* Mise en place de tests sur le Backend-controller (suite du travail de la veille)

Régis Ramel :
* Travail sur l'interface Web : dynamicité de l'affichage des liens
* Travail sur le Wiki

Germain Lecorps :
* Travail sur le Frontend

=== Vendredi 10 Février ===
Thibaut Nouguier :
* Travail sur le Builder de package

Rémi Gattaz:
* Automatisation des tests du Backen-controller à chaque commit

Régis Ramel :
* Travail sur l'interface Web
* Travail sur la séance de MPI : calcul des coûts
* Travail sur la séance de MPI : préparation de la séance sur la communication interpersonelle

Germain Lecorps :
* Travail sur le FrontEnd

== Semaine 4 : 13/02 - 19/02 ==
=== Lundi 13 Février ===
Travail de groupe :
* Réunion pour définir les objectifs de la semaine en vue de la soutenance de mi-parcours

Thibaut Nouguier :
* Travail sur le Builder de package

Rémi Gattaz :
* Travail sur notre modèle de modélisation des données (refonte de la BDD)
* Prise de rendez vous avec le Responsable du service informatique de Polytech

Régis Ramel :
* Travail sur le cout du projet : Main d'oeuvre, amortissement du matériel

Germain Lecorps :
* Travail sur le FrontEnd
* Formation sur le filtrage en angularjs

=== Mardi 14 Février ===
Travail de groupe :
* Quatrième séance de MPI : Communication interpersonnelles

Rémi Gattaz :
* Travail dans le controller backend
** Création des classes modèle Ticket, Package et Infos.
** Mise en place des routes /packages et /tickets
** Mise en place des liens dans le modèle
** Création du CRUD au travers de l'API REST sur les ressources Package et Ticket

Régis Ramel et Germain Lecorps :
* Travail sur la lecture des packages en Json

Thibaut Nouguier :
* Travail sur le Builder de package

=== Mercredi 15 Février ===
Rémi Gattaz et Régis Ramel :
* Rencontre avec M. Jean-Marc Palomares, responsable du CAS de l'UGA

Régis Ramel et Germain Lecorps :
* Travail sur le FrontEnd
** Filtrage sur la liste des packages
** Début de filtrage "complexe" sur ces packages

Rémi Gattaz :
* Découverte d'un problème avec mysql et waterline (absence de transaction)
* Remaniement de la BDD pour une migration de mysql vers mongodb
* Migration vers mongodb

Thibaut Nouguier :
* Travail sur le Builder de package

=== Jeudi 16 Février ===
Travail de groupe :
* Revue de sprint

Régis Ramel et Germain Lecorps :
* Travail sur le FrontEnd
** Filtrage "complexe" sur la liste des packages
** Ajout de la liste des tickets
** Modification de la lecture des Json pour suivre le nouveau

Rémi Gattaz :
* Fin de la migration vers mongo
* Complétion de l'API nécessaire à la complétion du Frontend

Thibaut Nouguier :
* Travail sur le Builder de package

=== Vendredi 17 Février ===
Travail de groupe :
* Soutenance de mi-parcours

Régis Ramel :
* Correction mineure sur l'interface Web

== Semaine 5 : 20/02 - 26/02 (Vacances) ==
=== Lundi 20 Février ===

=== Mardi 21 Février ===

=== Mercredi 22 Février ===
Rémi Gattaz :
* Ajout de l'appel tickets/:id/votes/results pour obtenir le score d'un ticket (upvotes, downvotes, neutres)
* Ajout de tests du modèle

=== Jeudi 23 Février ===
Rémi Gattaz :
* Completion des tests du model du Backend-controller

=== Vendredi 24 Février ===
Rémi Gattaz :
* Construction automatique de l'image docker du Backend-controller
* Mise à jour du projet Backend-controller-env pour utiliser cette image
* Mise en place de la création de la base Mongo à la création du container (utilisation de variables d'environnement)

=== Samedi 25 Février ===
Rémi Gattaz :
* Test de l'écriture de la documentation avec Swagger
* Début de l'écriture de la documentation avec API Blueprint

== Semaine 6 : 27/02 - 05/03 ==
=== Lundi 27 Février ===
Germain Lecorps et Régis Ramel :
* Travail sur l'interface Web : Préparation de l'intégration de l'API

Régis Ramel :
* Travail sur le lancement de l'image docker du Backend-Controller-env

Rémi Gattaz :
* Documentation de l'API
* Tentative de résolution d'un problème de synchronisation dans l'API (une fonction asynchrone devait être appelée depuis une fonction synchrone du framework qui a été surchargée)

Thibaut Nouguier :
* Travail sur la création d'une image docker pour aptly

=== Mardi 28 Février ===
Rémi Gattaz :
* Résolution du problème de la veille
* Fin de l'écriture de la documentation
* Validation de la version 1.0 de l'API

Thibaut Nouguier :
* Travail sur la création d'une image docker pour aptly
* Renseignement sur chroot pour le builder

Régis Ramel :
* Lancement de l'image Docker du Backend-Controller-env
* Travail sur le lancement de l'API en local pour intégrer au FrontEnd
* Début d'intégration de l'API au FrontEnd

Germain Lecorps :
* Réinstallation de l’environnement suite à un bug inconnu

=== Mercredi 01 Mars ===

Thibaut Nouguier :
* Travail sur le builder de package

=== Jeudi 02 Mars ===

Thibaut Nouguier :
* Test du builder avec des scripts comme sources
* Packaging de Procesim pour les RICM3
* Correction de plusieurs erreurs du builder

=== Vendredi 03 Mars ===

Thibaut Nouguier :
* Travail sur le builder de package
* Test du builder avec un projet maven

== Semaine 7 : 06/03 - 12/03 ==
=== Lundi 06 Mars ===

=== Mardi 07 Mars ===

=== Mercredi 08 Mars ===

=== Jeudi 09 Mars ===

=== Vendredi 10 Mars ===

== Semaine 8 : 13/03 - 19/03 ==
=== Lundi 13 Mars ===

=== Mardi 14 Mars ===

=== Mercredi 15 Mars ===

=== Jeudi 16 Mars ===

=== Vendredi 17 Mars ===

Fiche de suivi - Gestionnaire de packages

2017-03-03T08:27:01Z

Thibaut.Nouguier: /* Mercredi 01 Mars */

Voici la Fiche de suivi du Projet 2017 : Gestionnaire de package.

[[Projet 2017 : Gestionnaire de packages Polytech| '''Page d'accueil du projet''']]

= Équipe =
* Rémi Gattaz
* Germain Lecorps (Chef de Projet)
* Thibaut Nouguier
* Régis Ramel (Scrum Master)

= Avancée du projet =
== Semaine 1 : 23/01 - 29/01 ==
=== Lundi 23 Janvier ===
Travail de groupe :
* Formation du groupe
* Réflexion sur le sujet avec M. Donsez
* Envoi d'un mail explicatif à M. Palix et M. Danjean pour prise de rendez-vous
* Premières réflexions sur une solution de gestion de package

=== Mardi 24 Janvier ===
Travail de groupe :
* Réponse aux enseignants
* Design de la structure de l'application
Rémi Gattaz, Germain Lecorps et Thibaut Nouguier :
* Travail sur la doc sur les repository Debian
Régis Ramel :
* Travail sur le Wiki

=== Mercredi 25 Janvier ===
Travail de groupe :
* Entretiens avec M. Palix et M. Danjean pour préciser les exigences du projet, discuter des différentes possibilités et de ce qu'il est possible / intéressant de faire.
* Formalisation des objectifs du projet.

=== Jeudi 26 Janvier ===
Travail de groupe :
* Première séance de MPI : Description du projet, définition des rôles, exercice de map minder
Rémi Gattaz et Thibaut Nouguier :
* POC de création de package et d'application d'un fix
Germain Lecorps:
* Travail sur le Wiki : SRS
Régis Ramel :
* Envoi de la définition du sujet aux enseignants
* Constitution d'une liste de mail des enseignants pour obtenir la liste des outils nécessaires en RICM
* Envoi de la demande de recensement des outils requis en RICM

== Semaine 2 : 30/01 - 05/02 ==
=== Lundi 30 Janvier ===
Travail de groupe :
* Choix des technologies : Debian + langage de script.

=== Mardi 31 Janvier ===
Travail de groupe :
* Discussion pour le choix des langages : Python et Shell.
* Conception de la structure détaillée de l'application

Thibaut Nouguier :
* Création d'un repository local avec des packages Debian basiques (Reprepro)
* Installation des paquets Debian depuis le repository local
* Sécurisation du repository via des clés RSA

Rémi Gattaz :
* Recherches sur Reprepro
* Utilisation de Reprepro dans un container docker (pour environnement de dev)
* Interview par les étudiants PEIP

Régis Ramel :
* Mise au propre de la structure de l'application
* Travail sur le Wiki : Conception de l'application
* Travail sur le SRS : Fonctionnement de l'application

Germain Lecorps :
* Préparation de l’environnement de développement Web

=== Mercredi 01 Février ===

Thibaut Nouguier :
* Recherches complémentaires sur l'utilisateion de reprepro
* Simulation d'un cas d'utilisation avec reprepro en utilisant des clés GPG (master key, signing key, encryption key)

Rémi Gattaz :
* Recherches sur Aptly
* Utilisation de Aptly dans un container docker (pour environnement de dev)

Régis Ramel :
* Travail sur la structure de l'application
* Travail sur le Wiki
* Installation de Netbeans pour HTML5/Javascript

Germain Lecorps :
* [[Maquette - Gestionnaire de packages| '''Maquettes''']] de l'interface Web

=== Jeudi 02 Février ===
Travail de groupe :
* Deuxième séance de MPI : Exercice de Brainstorming, exercice de pitch

Rémi Gattaz et Thibaut Nouguier :
* Définition des actions du Controleur et de l'API

Thibaut Nouguier :
* Travail sur la base de données MySQL

Rémi Gattaz :
* Définition des routes offerte par l'API du contrôleur dans le backend - [[Conception - Gestionnaire de packages#API_offerte_par_le_contr.C3.B4leur | '''documentation''']]

Germain Lecorps :
* Formation Angular

=== Vendredi 03 Février ===
Rémi Gattaz et Thibaut Nouguier :
* Mise en place du scrum (définition des user stories et des tâches)

Rémi Gattaz :
* Ajout des user stories et des tâches dans le wiki
* Création du tableau scrum sur github

Germain Lecorps :
* Formation Angular.js

== Semaine 3 : 06/02 - 12/02 ==
=== Lundi 06 Février ===
Travail de groupe :
* Troisième séance de MPI : Matrice de risques et Coût du budget
* Revue de sprint, définition des objectifs du sprint 2

Rémi Gattaz :

Germain Lecorps :
* Travail sur le sprint Scrum
* Tutoriel Angular
* Formation Web
* Installation des outils
* Ébauche de site internet

Thibaut Nouguier :
* Travail sur le Builder de package

Régis Ramel :
* Travail sur le wiki : (Fiche de Suivi, Scrum, MPI)
* Travail sur le sprint Scrum
* Création d'un nouveau projet Angular
* Push du projet Angular sur GitHub
* Travail sur un modèle de projet Angular (liens vers d'autres pages)

=== Mardi 07 Février ===
Thibaut Nouguier :
* Première version d'un Builder de package qui fonctionne pour :
** un ensemble de fichiers c avec un makefile
** un script

Rémi Gattaz :
* NetBeans Day
* Terminer composition environnement backend controller

Germain Lecorps et Régis Ramel :
* Travail sur l'interface Web

=== Mercredi 08 Février ===
Thibaut Nouguier :
* Travail sur le Builder de package

Régis Ramel :
* Travail sur l'interface Web : génération d'une FAQ
* Travail sur l'interface Web : amélioration de la page de login

Germain Lecorps :
* Formation Web
* Travail sur l'interface Web : Création du formulaire de Contribution

Rémi Gattaz:
* Mise en place de tests sur le Backend-controller

=== Jeudi 09 Février ===
Thibaut Nouguier :
* Travail sur le Builder de package

Rémi Gattaz:
* Mise en place de tests sur le Backend-controller (suite du travail de la veille)

Régis Ramel :
* Travail sur l'interface Web : dynamicité de l'affichage des liens
* Travail sur le Wiki

Germain Lecorps :
* Travail sur le Frontend

=== Vendredi 10 Février ===
Thibaut Nouguier :
* Travail sur le Builder de package

Rémi Gattaz:
* Automatisation des tests du Backen-controller à chaque commit

Régis Ramel :
* Travail sur l'interface Web
* Travail sur la séance de MPI : calcul des coûts
* Travail sur la séance de MPI : préparation de la séance sur la communication interpersonelle

Germain Lecorps :
* Travail sur le FrontEnd

== Semaine 4 : 13/02 - 19/02 ==
=== Lundi 13 Février ===
Travail de groupe :
* Réunion pour définir les objectifs de la semaine en vue de la soutenance de mi-parcours

Thibaut Nouguier :
* Travail sur le Builder de package

Rémi Gattaz :
* Travail sur notre modèle de modélisation des données (refonte de la BDD)
* Prise de rendez vous avec le Responsable du service informatique de Polytech

Régis Ramel :
* Travail sur le cout du projet : Main d'oeuvre, amortissement du matériel

Germain Lecorps :
* Travail sur le FrontEnd
* Formation sur le filtrage en angularjs

=== Mardi 14 Février ===
Travail de groupe :
* Quatrième séance de MPI : Communication interpersonnelles

Rémi Gattaz :
* Travail dans le controller backend
** Création des classes modèle Ticket, Package et Infos.
** Mise en place des routes /packages et /tickets
** Mise en place des liens dans le modèle
** Création du CRUD au travers de l'API REST sur les ressources Package et Ticket

Régis Ramel et Germain Lecorps :
* Travail sur la lecture des packages en Json

Thibaut Nouguier :
* Travail sur le Builder de package

=== Mercredi 15 Février ===
Rémi Gattaz et Régis Ramel :
* Rencontre avec M. Jean-Marc Palomares, responsable du CAS de l'UGA

Régis Ramel et Germain Lecorps :
* Travail sur le FrontEnd
** Filtrage sur la liste des packages
** Début de filtrage "complexe" sur ces packages

Rémi Gattaz :
* Découverte d'un problème avec mysql et waterline (absence de transaction)
* Remaniement de la BDD pour une migration de mysql vers mongodb
* Migration vers mongodb

Thibaut Nouguier :
* Travail sur le Builder de package

=== Jeudi 16 Février ===
Travail de groupe :
* Revue de sprint

Régis Ramel et Germain Lecorps :
* Travail sur le FrontEnd
** Filtrage "complexe" sur la liste des packages
** Ajout de la liste des tickets
** Modification de la lecture des Json pour suivre le nouveau

Rémi Gattaz :
* Fin de la migration vers mongo
* Complétion de l'API nécessaire à la complétion du Frontend

Thibaut Nouguier :
* Travail sur le Builder de package

=== Vendredi 17 Février ===
Travail de groupe :
* Soutenance de mi-parcours

Régis Ramel :
* Correction mineure sur l'interface Web

== Semaine 5 : 20/02 - 26/02 (Vacances) ==
=== Lundi 20 Février ===

=== Mardi 21 Février ===

=== Mercredi 22 Février ===
Rémi Gattaz :
* Ajout de l'appel tickets/:id/votes/results pour obtenir le score d'un ticket (upvotes, downvotes, neutres)
* Ajout de tests du modèle

=== Jeudi 23 Février ===
Rémi Gattaz :
* Completion des tests du model du Backend-controller

=== Vendredi 24 Février ===
Rémi Gattaz :
* Construction automatique de l'image docker du Backend-controller
* Mise à jour du projet Backend-controller-env pour utiliser cette image
* Mise en place de la création de la base Mongo à la création du container (utilisation de variables d'environnement)

=== Samedi 25 Février ===
Rémi Gattaz :
* Test de l'écriture de la documentation avec Swagger
* Début de l'écriture de la documentation avec API Blueprint

== Semaine 6 : 27/02 - 05/03 ==
=== Lundi 27 Février ===
Germain Lecorps et Régis Ramel :
* Travail sur l'interface Web : Préparation de l'intégration de l'API

Régis Ramel :
* Travail sur le lancement de l'image docker du Backend-Controller-env

Rémi Gattaz :
* Documentation de l'API
* Tentative de résolution d'un problème de synchronisation dans l'API (une fonction asynchrone devait être appelée depuis une fonction synchrone du framework qui a été surchargée)

Thibaut Nouguier :
* Travail sur la création d'une image docker pour aptly

=== Mardi 28 Février ===
Rémi Gattaz :
* Résolution du problème de la veille
* Fin de l'écriture de la documentation
* Validation de la version 1.0 de l'API

Thibaut Nouguier :
* Travail sur la création d'une image docker pour aptly
* Renseignement sur chroot pour le builder

Régis Ramel :
* Lancement de l'image Docker du Backend-Controller-env
* Travail sur le lancement de l'API en local pour intégrer au FrontEnd
* Début d'intégration de l'API au FrontEnd

Germain Lecorps :
* Réinstallation de l’environnement suite à un bug inconnu

=== Mercredi 01 Mars ===

Thibaut Nouguier :
* Travail sur le builder de package

=== Jeudi 02 Mars ===

=== Vendredi 03 Mars ===

== Semaine 7 : 06/03 - 12/03 ==
=== Lundi 06 Mars ===

=== Mardi 07 Mars ===

=== Mercredi 08 Mars ===

=== Jeudi 09 Mars ===

=== Vendredi 10 Mars ===

== Semaine 8 : 13/03 - 19/03 ==
=== Lundi 13 Mars ===

=== Mardi 14 Mars ===

=== Mercredi 15 Mars ===

=== Jeudi 16 Mars ===

=== Vendredi 17 Mars ===

Fiche de suivi - Gestionnaire de packages

2017-02-28T15:10:12Z

Thibaut.Nouguier: /* Mardi 28 Février */

Voici la Fiche de suivi du Projet 2017 : Gestionnaire de package.

[[Projet 2017 : Gestionnaire de packages Polytech| '''Page d'accueil du projet''']]

= Équipe =
* Rémi Gattaz
* Germain Lecorps (Chef de Projet)
* Thibaut Nouguier
* Régis Ramel (Scrum Master)

= Avancée du projet =
== Semaine 1 : 23/01 - 29/01 ==
=== Lundi 23 Janvier ===
Travail de groupe :
* Formation du groupe
* Réflexion sur le sujet avec M. Donsez
* Envoi d'un mail explicatif à M. Palix et M. Danjean pour prise de rendez-vous
* Premières réflexions sur une solution de gestion de package

=== Mardi 24 Janvier ===
Travail de groupe :
* Réponse aux enseignants
* Design de la structure de l'application
Rémi Gattaz, Germain Lecorps et Thibaut Nouguier :
* Travail sur la doc sur les repository Debian
Régis Ramel :
* Travail sur le Wiki

=== Mercredi 25 Janvier ===
Travail de groupe :
* Entretiens avec M. Palix et M. Danjean pour préciser les exigences du projet, discuter des différentes possibilités et de ce qu'il est possible / intéressant de faire.
* Formalisation des objectifs du projet.

=== Jeudi 26 Janvier ===
Travail de groupe :
* Première séance de MPI : Description du projet, définition des rôles, exercice de map minder
Rémi Gattaz et Thibaut Nouguier :
* POC de création de package et d'application d'un fix
Germain Lecorps:
* Travail sur le Wiki : SRS
Régis Ramel :
* Envoi de la définition du sujet aux enseignants
* Constitution d'une liste de mail des enseignants pour obtenir la liste des outils nécessaires en RICM
* Envoi de la demande de recensement des outils requis en RICM

== Semaine 2 : 30/01 - 05/02 ==
=== Lundi 30 Janvier ===
Travail de groupe :
* Choix des technologies : Debian + langage de script.

=== Mardi 31 Janvier ===
Travail de groupe :
* Discussion pour le choix des langages : Python et Shell.
* Conception de la structure détaillée de l'application

Thibaut Nouguier :
* Création d'un repository local avec des packages Debian basiques (Reprepro)
* Installation des paquets Debian depuis le repository local
* Sécurisation du repository via des clés RSA

Rémi Gattaz :
* Recherches sur Reprepro
* Utilisation de Reprepro dans un container docker (pour environnement de dev)
* Interview par les étudiants PEIP

Régis Ramel :
* Mise au propre de la structure de l'application
* Travail sur le Wiki : Conception de l'application
* Travail sur le SRS : Fonctionnement de l'application

Germain Lecorps :
* Préparation de l’environnement de développement Web

=== Mercredi 01 Février ===

Thibaut Nouguier :
* Recherches complémentaires sur l'utilisateion de reprepro
* Simulation d'un cas d'utilisation avec reprepro en utilisant des clés GPG (master key, signing key, encryption key)

Rémi Gattaz :
* Recherches sur Aptly
* Utilisation de Aptly dans un container docker (pour environnement de dev)

Régis Ramel :
* Travail sur la structure de l'application
* Travail sur le Wiki
* Installation de Netbeans pour HTML5/Javascript

Germain Lecorps :
* [[Maquette - Gestionnaire de packages| '''Maquettes''']] de l'interface Web

=== Jeudi 02 Février ===
Travail de groupe :
* Deuxième séance de MPI : Exercice de Brainstorming, exercice de pitch

Rémi Gattaz et Thibaut Nouguier :
* Définition des actions du Controleur et de l'API

Thibaut Nouguier :
* Travail sur la base de données MySQL

Rémi Gattaz :
* Définition des routes offerte par l'API du contrôleur dans le backend - [[Conception - Gestionnaire de packages#API_offerte_par_le_contr.C3.B4leur | '''documentation''']]

Germain Lecorps :
* Formation Angular

=== Vendredi 03 Février ===
Rémi Gattaz et Thibaut Nouguier :
* Mise en place du scrum (définition des user stories et des tâches)

Rémi Gattaz :
* Ajout des user stories et des tâches dans le wiki
* Création du tableau scrum sur github

Germain Lecorps :
* Formation Angular.js

== Semaine 3 : 06/02 - 12/02 ==
=== Lundi 06 Février ===
Travail de groupe :
* Troisième séance de MPI : Matrice de risques et Coût du budget
* Revue de sprint, définition des objectifs du sprint 2

Rémi Gattaz :

Germain Lecorps :
* Travail sur le sprint Scrum
* Tutoriel Angular
* Formation Web
* Installation des outils
* Ébauche de site internet

Thibaut Nouguier :
* Travail sur le Builder de package

Régis Ramel :
* Travail sur le wiki : (Fiche de Suivi, Scrum, MPI)
* Travail sur le sprint Scrum
* Création d'un nouveau projet Angular
* Push du projet Angular sur GitHub
* Travail sur un modèle de projet Angular (liens vers d'autres pages)

=== Mardi 07 Février ===
Thibaut Nouguier :
* Première version d'un Builder de package qui fonctionne pour :
** un ensemble de fichiers c avec un makefile
** un script

Rémi Gattaz :
* NetBeans Day
* Terminer composition environnement backend controller

Germain Lecorps et Régis Ramel :
* Travail sur l'interface Web

=== Mercredi 08 Février ===
Thibaut Nouguier :
* Travail sur le Builder de package

Régis Ramel :
* Travail sur l'interface Web : génération d'une FAQ
* Travail sur l'interface Web : amélioration de la page de login

Germain Lecorps :
* Formation Web
* Travail sur l'interface Web : Création du formulaire de Contribution

Rémi Gattaz:
* Mise en place de tests sur le Backend-controller

=== Jeudi 09 Février ===
Thibaut Nouguier :
* Travail sur le Builder de package

Rémi Gattaz:
* Mise en place de tests sur le Backend-controller (suite du travail de la veille)

Régis Ramel :
* Travail sur l'interface Web : dynamicité de l'affichage des liens
* Travail sur le Wiki

Germain Lecorps :
* Travail sur le Frontend

=== Vendredi 10 Février ===
Thibaut Nouguier :
* Travail sur le Builder de package

Rémi Gattaz:
* Automatisation des tests du Backen-controller à chaque commit

Régis Ramel :
* Travail sur l'interface Web
* Travail sur la séance de MPI : calcul des coûts
* Travail sur la séance de MPI : préparation de la séance sur la communication interpersonelle

Germain Lecorps :
* Travail sur le FrontEnd

== Semaine 4 : 13/02 - 19/02 ==
=== Lundi 13 Février ===
Travail de groupe :
* Réunion pour définir les objectifs de la semaine en vue de la soutenance de mi-parcours

Thibaut Nouguier :
* Travail sur le Builder de package

Rémi Gattaz :
* Travail sur notre modèle de modélisation des données (refonte de la BDD)
* Prise de rendez vous avec le Responsable du service informatique de Polytech

Régis Ramel :
* Travail sur le cout du projet : Main d'oeuvre, amortissement du matériel

Germain Lecorps :
* Travail sur le FrontEnd
* Formation sur le filtrage en angularjs

=== Mardi 14 Février ===
Travail de groupe :
* Quatrième séance de MPI : Communication interpersonnelles

Rémi Gattaz :
* Travail dans le controller backend
** Création des classes modèle Ticket, Package et Infos.
** Mise en place des routes /packages et /tickets
** Mise en place des liens dans le modèle
** Création du CRUD au travers de l'API REST sur les ressources Package et Ticket

Régis Ramel et Germain Lecorps :
* Travail sur la lecture des packages en Json

Thibaut Nouguier :
* Travail sur le Builder de package

=== Mercredi 15 Février ===
Rémi Gattaz et Régis Ramel :
* Rencontre avec M. Jean-Marc Palomares, responsable du CAS de l'UGA

Régis Ramel et Germain Lecorps :
* Travail sur le FrontEnd
** Filtrage sur la liste des packages
** Début de filtrage "complexe" sur ces packages

Rémi Gattaz :
* Découverte d'un problème avec mysql et waterline (absence de transaction)
* Remaniement de la BDD pour une migration de mysql vers mongodb
* Migration vers mongodb

Thibaut Nouguier :
* Travail sur le Builder de package

=== Jeudi 16 Février ===
Travail de groupe :
* Revue de sprint

Régis Ramel et Germain Lecorps :
* Travail sur le FrontEnd
** Filtrage "complexe" sur la liste des packages
** Ajout de la liste des tickets
** Modification de la lecture des Json pour suivre le nouveau

Rémi Gattaz :
* Fin de la migration vers mongo
* Complétion de l'API nécessaire à la complétion du Frontend

Thibaut Nouguier :
* Travail sur le Builder de package

=== Vendredi 17 Février ===
Travail de groupe :
* Soutenance de mi-parcours

Régis Ramel :
* Correction mineure sur l'interface Web

== Semaine 5 : 20/02 - 26/02 (Vacances) ==
=== Lundi 20 Février ===

=== Mardi 21 Février ===

=== Mercredi 22 Février ===
Rémi Gattaz :
* Ajout de l'appel tickets/:id/votes/results pour obtenir le score d'un ticket (upvotes, downvotes, neutres)
* Ajout de tests du modèle

=== Jeudi 23 Février ===
Rémi Gattaz :
* Completion des tests du model du Backend-controller

=== Vendredi 24 Février ===
Rémi Gattaz :
* Construction automatique de l'image docker du Backend-controller
* Mise à jour du projet Backend-controller-env pour utiliser cette image
* Mise en place de la création de la base Mongo à la création du container (utilisation de variables d'environnement)

=== Samedi 25 Février ===
Rémi Gattaz :
* Test de l'écriture de la documentation avec Swagger
* Début de l'écriture de la documentation avec API Blueprint

== Semaine 6 : 27/02 - 05/03 ==
=== Lundi 27 Février ===
Germain Lecorps et Régis Ramel :
* Travail sur l'interface Web : Préparation de l'intégration de l'API

Rémi Gattaz :
* Documentation de l'API
* Tentative de résolution d'un problème de synchronisation dans l'API (une fonction asynchrone devait être appelée depuis une fonction synchrone du framework qui a été surchargée)

Thibaut Nouguier :
* Travail sur la création d'une image docker pout aptly

=== Mardi 28 Février ===
Rémi Gattaz :
* Résolution du problème de la veille
* Fin de l'écriture de la documentation
* Validation de la version 1.0 de l'API

Thibaut Nouguier :
* Travail sur la création d'une image docker pour aptly
* Renseignement sur chroot pour le builder

=== Mercredi 01 Mars ===

=== Jeudi 02 Mars ===

=== Vendredi 03 Mars ===

== Semaine 7 : 06/03 - 12/03 ==
=== Lundi 06 Mars ===

=== Mardi 07 Mars ===

=== Mercredi 08 Mars ===

=== Jeudi 09 Mars ===

=== Vendredi 10 Mars ===

== Semaine 8 : 13/03 - 19/03 ==
=== Lundi 13 Mars ===

=== Mardi 14 Mars ===

=== Mercredi 15 Mars ===

=== Jeudi 16 Mars ===

=== Vendredi 17 Mars ===

Fiche de suivi - Gestionnaire de packages

2017-02-28T15:09:18Z

Thibaut.Nouguier: /* Lundi 27 Février */

Voici la Fiche de suivi du Projet 2017 : Gestionnaire de package.

[[Projet 2017 : Gestionnaire de packages Polytech| '''Page d'accueil du projet''']]

= Équipe =
* Rémi Gattaz
* Germain Lecorps (Chef de Projet)
* Thibaut Nouguier
* Régis Ramel (Scrum Master)

= Avancée du projet =
== Semaine 1 : 23/01 - 29/01 ==
=== Lundi 23 Janvier ===
Travail de groupe :
* Formation du groupe
* Réflexion sur le sujet avec M. Donsez
* Envoi d'un mail explicatif à M. Palix et M. Danjean pour prise de rendez-vous
* Premières réflexions sur une solution de gestion de package

=== Mardi 24 Janvier ===
Travail de groupe :
* Réponse aux enseignants
* Design de la structure de l'application
Rémi Gattaz, Germain Lecorps et Thibaut Nouguier :
* Travail sur la doc sur les repository Debian
Régis Ramel :
* Travail sur le Wiki

=== Mercredi 25 Janvier ===
Travail de groupe :
* Entretiens avec M. Palix et M. Danjean pour préciser les exigences du projet, discuter des différentes possibilités et de ce qu'il est possible / intéressant de faire.
* Formalisation des objectifs du projet.

=== Jeudi 26 Janvier ===
Travail de groupe :
* Première séance de MPI : Description du projet, définition des rôles, exercice de map minder
Rémi Gattaz et Thibaut Nouguier :
* POC de création de package et d'application d'un fix
Germain Lecorps:
* Travail sur le Wiki : SRS
Régis Ramel :
* Envoi de la définition du sujet aux enseignants
* Constitution d'une liste de mail des enseignants pour obtenir la liste des outils nécessaires en RICM
* Envoi de la demande de recensement des outils requis en RICM

== Semaine 2 : 30/01 - 05/02 ==
=== Lundi 30 Janvier ===
Travail de groupe :
* Choix des technologies : Debian + langage de script.

=== Mardi 31 Janvier ===
Travail de groupe :
* Discussion pour le choix des langages : Python et Shell.
* Conception de la structure détaillée de l'application

Thibaut Nouguier :
* Création d'un repository local avec des packages Debian basiques (Reprepro)
* Installation des paquets Debian depuis le repository local
* Sécurisation du repository via des clés RSA

Rémi Gattaz :
* Recherches sur Reprepro
* Utilisation de Reprepro dans un container docker (pour environnement de dev)
* Interview par les étudiants PEIP

Régis Ramel :
* Mise au propre de la structure de l'application
* Travail sur le Wiki : Conception de l'application
* Travail sur le SRS : Fonctionnement de l'application

Germain Lecorps :
* Préparation de l’environnement de développement Web

=== Mercredi 01 Février ===

Thibaut Nouguier :
* Recherches complémentaires sur l'utilisateion de reprepro
* Simulation d'un cas d'utilisation avec reprepro en utilisant des clés GPG (master key, signing key, encryption key)

Rémi Gattaz :
* Recherches sur Aptly
* Utilisation de Aptly dans un container docker (pour environnement de dev)

Régis Ramel :
* Travail sur la structure de l'application
* Travail sur le Wiki
* Installation de Netbeans pour HTML5/Javascript

Germain Lecorps :
* [[Maquette - Gestionnaire de packages| '''Maquettes''']] de l'interface Web

=== Jeudi 02 Février ===
Travail de groupe :
* Deuxième séance de MPI : Exercice de Brainstorming, exercice de pitch

Rémi Gattaz et Thibaut Nouguier :
* Définition des actions du Controleur et de l'API

Thibaut Nouguier :
* Travail sur la base de données MySQL

Rémi Gattaz :
* Définition des routes offerte par l'API du contrôleur dans le backend - [[Conception - Gestionnaire de packages#API_offerte_par_le_contr.C3.B4leur | '''documentation''']]

Germain Lecorps :
* Formation Angular

=== Vendredi 03 Février ===
Rémi Gattaz et Thibaut Nouguier :
* Mise en place du scrum (définition des user stories et des tâches)

Rémi Gattaz :
* Ajout des user stories et des tâches dans le wiki
* Création du tableau scrum sur github

Germain Lecorps :
* Formation Angular.js

== Semaine 3 : 06/02 - 12/02 ==
=== Lundi 06 Février ===
Travail de groupe :
* Troisième séance de MPI : Matrice de risques et Coût du budget
* Revue de sprint, définition des objectifs du sprint 2

Rémi Gattaz :

Germain Lecorps :
* Travail sur le sprint Scrum
* Tutoriel Angular
* Formation Web
* Installation des outils
* Ébauche de site internet

Thibaut Nouguier :
* Travail sur le Builder de package

Régis Ramel :
* Travail sur le wiki : (Fiche de Suivi, Scrum, MPI)
* Travail sur le sprint Scrum
* Création d'un nouveau projet Angular
* Push du projet Angular sur GitHub
* Travail sur un modèle de projet Angular (liens vers d'autres pages)

=== Mardi 07 Février ===
Thibaut Nouguier :
* Première version d'un Builder de package qui fonctionne pour :
** un ensemble de fichiers c avec un makefile
** un script

Rémi Gattaz :
* NetBeans Day
* Terminer composition environnement backend controller

Germain Lecorps et Régis Ramel :
* Travail sur l'interface Web

=== Mercredi 08 Février ===
Thibaut Nouguier :
* Travail sur le Builder de package

Régis Ramel :
* Travail sur l'interface Web : génération d'une FAQ
* Travail sur l'interface Web : amélioration de la page de login

Germain Lecorps :
* Formation Web
* Travail sur l'interface Web : Création du formulaire de Contribution

Rémi Gattaz:
* Mise en place de tests sur le Backend-controller

=== Jeudi 09 Février ===
Thibaut Nouguier :
* Travail sur le Builder de package

Rémi Gattaz:
* Mise en place de tests sur le Backend-controller (suite du travail de la veille)

Régis Ramel :
* Travail sur l'interface Web : dynamicité de l'affichage des liens
* Travail sur le Wiki

Germain Lecorps :
* Travail sur le Frontend

=== Vendredi 10 Février ===
Thibaut Nouguier :
* Travail sur le Builder de package

Rémi Gattaz:
* Automatisation des tests du Backen-controller à chaque commit

Régis Ramel :
* Travail sur l'interface Web
* Travail sur la séance de MPI : calcul des coûts
* Travail sur la séance de MPI : préparation de la séance sur la communication interpersonelle

Germain Lecorps :
* Travail sur le FrontEnd

== Semaine 4 : 13/02 - 19/02 ==
=== Lundi 13 Février ===
Travail de groupe :
* Réunion pour définir les objectifs de la semaine en vue de la soutenance de mi-parcours

Thibaut Nouguier :
* Travail sur le Builder de package

Rémi Gattaz :
* Travail sur notre modèle de modélisation des données (refonte de la BDD)
* Prise de rendez vous avec le Responsable du service informatique de Polytech

Régis Ramel :
* Travail sur le cout du projet : Main d'oeuvre, amortissement du matériel

Germain Lecorps :
* Travail sur le FrontEnd
* Formation sur le filtrage en angularjs

=== Mardi 14 Février ===
Travail de groupe :
* Quatrième séance de MPI : Communication interpersonnelles

Rémi Gattaz :
* Travail dans le controller backend
** Création des classes modèle Ticket, Package et Infos.
** Mise en place des routes /packages et /tickets
** Mise en place des liens dans le modèle
** Création du CRUD au travers de l'API REST sur les ressources Package et Ticket

Régis Ramel et Germain Lecorps :
* Travail sur la lecture des packages en Json

Thibaut Nouguier :
* Travail sur le Builder de package

=== Mercredi 15 Février ===
Rémi Gattaz et Régis Ramel :
* Rencontre avec M. Jean-Marc Palomares, responsable du CAS de l'UGA

Régis Ramel et Germain Lecorps :
* Travail sur le FrontEnd
** Filtrage sur la liste des packages
** Début de filtrage "complexe" sur ces packages

Rémi Gattaz :
* Découverte d'un problème avec mysql et waterline (absence de transaction)
* Remaniement de la BDD pour une migration de mysql vers mongodb
* Migration vers mongodb

Thibaut Nouguier :
* Travail sur le Builder de package

=== Jeudi 16 Février ===
Travail de groupe :
* Revue de sprint

Régis Ramel et Germain Lecorps :
* Travail sur le FrontEnd
** Filtrage "complexe" sur la liste des packages
** Ajout de la liste des tickets
** Modification de la lecture des Json pour suivre le nouveau

Rémi Gattaz :
* Fin de la migration vers mongo
* Complétion de l'API nécessaire à la complétion du Frontend

Thibaut Nouguier :
* Travail sur le Builder de package

=== Vendredi 17 Février ===
Travail de groupe :
* Soutenance de mi-parcours

Régis Ramel :
* Correction mineure sur l'interface Web

== Semaine 5 : 20/02 - 26/02 (Vacances) ==
=== Lundi 20 Février ===

=== Mardi 21 Février ===

=== Mercredi 22 Février ===
Rémi Gattaz :
* Ajout de l'appel tickets/:id/votes/results pour obtenir le score d'un ticket (upvotes, downvotes, neutres)
* Ajout de tests du modèle

=== Jeudi 23 Février ===
Rémi Gattaz :
* Completion des tests du model du Backend-controller

=== Vendredi 24 Février ===
Rémi Gattaz :
* Construction automatique de l'image docker du Backend-controller
* Mise à jour du projet Backend-controller-env pour utiliser cette image
* Mise en place de la création de la base Mongo à la création du container (utilisation de variables d'environnement)

=== Samedi 25 Février ===
Rémi Gattaz :
* Test de l'écriture de la documentation avec Swagger
* Début de l'écriture de la documentation avec API Blueprint

== Semaine 6 : 27/02 - 05/03 ==
=== Lundi 27 Février ===
Germain Lecorps et Régis Ramel :
* Travail sur l'interface Web : Préparation de l'intégration de l'API

Rémi Gattaz :
* Documentation de l'API
* Tentative de résolution d'un problème de synchronisation dans l'API (une fonction asynchrone devait être appelée depuis une fonction synchrone du framework qui a été surchargée)

Thibaut Nouguier :
* Travail sur la création d'une image docker pout aptly

=== Mardi 28 Février ===
Rémi Gattaz :
* Résolution du problème de la veille
* Fin de l'écriture de la documentation
* Validation de la version 1.0 de l'API

=== Mercredi 01 Mars ===

=== Jeudi 02 Mars ===

=== Vendredi 03 Mars ===

== Semaine 7 : 06/03 - 12/03 ==
=== Lundi 06 Mars ===

=== Mardi 07 Mars ===

=== Mercredi 08 Mars ===

=== Jeudi 09 Mars ===

=== Vendredi 10 Mars ===

== Semaine 8 : 13/03 - 19/03 ==
=== Lundi 13 Mars ===

=== Mardi 14 Mars ===

=== Mercredi 15 Mars ===

=== Jeudi 16 Mars ===

=== Vendredi 17 Mars ===

Fiche de suivi - Gestionnaire de packages

2017-02-17T08:00:15Z

Thibaut.Nouguier: /* Semaine 4 : 13/02 - 19/02 */

Fiche de suivi - Gestionnaire de packages

2017-02-14T16:29:20Z

Thibaut.Nouguier: /* Semaine 4 : 13/02 - 19/02 */

Fiche de suivi - Gestionnaire de packages

2017-02-13T15:39:41Z

Thibaut.Nouguier: /* Lundi 13 février */

Fiche de suivi - Gestionnaire de packages

2017-02-13T15:38:49Z

Thibaut.Nouguier: /* Vendredi 10 février */

Fiche de suivi - Gestionnaire de packages

2017-02-13T15:38:29Z

Thibaut.Nouguier: /* Jeudi 09 février */

Fiche de suivi - Gestionnaire de packages

2017-02-09T10:06:18Z

Thibaut.Nouguier: /* Mercredi 08 février */

Fiche de suivi - Gestionnaire de packages

2017-02-08T08:33:38Z

Thibaut.Nouguier: /* Mardi 07 février */

Fiche de suivi - Gestionnaire de packages

2017-02-07T09:55:38Z

Thibaut.Nouguier: /* Lundi 06 février */

Fiche de suivi - Gestionnaire de packages

2017-02-02T15:36:50Z

Thibaut.Nouguier: /* Jeudi 02 février */

Fiche de suivi - Gestionnaire de packages

2017-02-02T15:34:20Z

Thibaut.Nouguier: /* Mercredi 01 février */

Fiche de suivi - Gestionnaire de packages

2017-02-02T15:34:06Z

Thibaut.Nouguier: /* Mercredi 01 février */

Conception - Gestionnaire de packages

2017-02-02T13:47:19Z

Thibaut.Nouguier: /* Ensemble des fonctionnalités BackEnd à implémenter : */

Voici le détail de la Conception du Projet 2017 : Gestionnaire de package.

[[Projet 2017 : Gestionnaire de packages Polytech| '''Page d'accueil du projet''']]

= Équipe =
* Rémi Gattaz
* Germain Lecorps (Chef de Projet)
* Thibaut Nouguier
* Régis Ramel (Scrum Master)

= Conception =
== Schéma de la structure de l'application ==
Nous avons tout d'abord réalisé une [[Gestionnaire de packages : Structure de l'application - version 1| première version du schéma de la structure de l'application]]. Cette représentation est abstraite, cela nous a permit de définir les principaux composants de l'application.

Nous avons ensuite précisé cette représentation en isolant la partie construction des packages (Builder) et en détaillant les fonctionnalités de chaque composants.
[[Image:Structure de l'application version 2.png|550px|center|Structure de l'application]]

== Ensemble des fonctionnalités BackEnd à implémenter : ==
* Lister les packages présents sur le repository
* Création d'un package en traitant l'archive (tar, zip, ...) déposée par un utilisateur
* Ajouter/Supprimer des packages
* Gérer les accès au repository : (Administrateur)
** étudiant : une clé par année
** professeur : sur demande
* Rendre le repository disponible (permettre son ajout dans sources.list)
* Détecter les mises à jour de packages automatiquement
Technologies envisagées : NodeJS (Gestion de CLI, API Rest), MySQL (Base de données/Repo), Shell (Build des packages)

== Ensemble des fonctionnalités FrontEnd à implémenter : ==
* Visualisation des packages disponibles
* Filtrage sur la visualisation des packages (Mots-Clés, Filière, Matière)
* Connexion utilisateur
* Dépôt d'une archive pour la création d'un package par un utilisateur authentifié
* Visualisation des tickets :
** ticket de création de package
** ticket de mise à jour d'un package
* Suppression d'un ticket de création d'un package / ticket de mise à jour d'un package par le créateur ou un administrateur
* Visualisation des logs pour les build de packages (Administrateur)

Technologies envisagées : HTML5, CSS3, AngularJS

== Choix des langages : ==
Pour la gestion du dépôt des demandes de packages, nous avons choisi Javascript avec l'utilisation de micro-services qui vont permettre une gestion de CLI et de l'API.
Pour la construction du package Debian, nous avons choisi d'utiliser le langage Shell, car cette construction va consister en une succession de commandes Unix.

== Choix des technologies pour le Repository : ==
Plusieurs solutions ont été considérées :
* [https://wiki.debian-fr.xyz/Reprepro '''Reprepro''']
* [https://www.aptly.info/ '''Aptly''']
* [https://wiki.debian.org/DakHowTo '''mini-dak''']

Finalement, notre choix s'est porté sur Aptly.

Pour simplifier la phase de développement, un container docker contenant un repository sera créé. Pour le déploiement, l'utilisation d'un serveur sera toutefois préféré.

Conception - Gestionnaire de packages

2017-02-02T13:46:36Z

Thibaut.Nouguier: /* Ensemble des fonctionnalités BackEnd à implémenter : */

Voici le détail de la Conception du Projet 2017 : Gestionnaire de package.

[[Projet 2017 : Gestionnaire de packages Polytech| '''Page d'accueil du projet''']]

= Équipe =
* Rémi Gattaz
* Germain Lecorps (Chef de Projet)
* Thibaut Nouguier
* Régis Ramel (Scrum Master)

= Conception =
== Schéma de la structure de l'application ==
Nous avons tout d'abord réalisé une [[Gestionnaire de packages : Structure de l'application - version 1| première version du schéma de la structure de l'application]]. Cette représentation est abstraite, cela nous a permit de définir les principaux composants de l'application.

Nous avons ensuite précisé cette représentation en isolant la partie construction des packages (Builder) et en détaillant les fonctionnalités de chaque composants.
[[Image:Structure de l'application version 2.png|550px|center|Structure de l'application]]

== Ensemble des fonctionnalités BackEnd à implémenter : ==
* Lister les packages présents sur le repository
* Création d'un package en traitant l'archive (tar, zip, ...) déposée par un utilisateur
* Ajouter/Supprimer des packages
* Gérer les accès au repository : (Administrateur)
** étudiant : une clé par année
** professeur : sur demande
* Rendre le repository disponible (permettre son ajout dans sources.list)
* Détecter les mises à jour de packages automatiquement
Technologies envisagées : Python (Gestion de CLI, API Rest), MySQL (Base de données/Repo), Shell (Build des packages)

== Ensemble des fonctionnalités FrontEnd à implémenter : ==
* Visualisation des packages disponibles
* Filtrage sur la visualisation des packages (Mots-Clés, Filière, Matière)
* Connexion utilisateur
* Dépôt d'une archive pour la création d'un package par un utilisateur authentifié
* Visualisation des tickets :
** ticket de création de package
** ticket de mise à jour d'un package
* Suppression d'un ticket de création d'un package / ticket de mise à jour d'un package par le créateur ou un administrateur
* Visualisation des logs pour les build de packages (Administrateur)

Technologies envisagées : HTML5, CSS3, AngularJS

== Choix des langages : ==
Pour la gestion du dépôt des demandes de packages, nous avons choisi Javascript avec l'utilisation de micro-services qui vont permettre une gestion de CLI et de l'API.
Pour la construction du package Debian, nous avons choisi d'utiliser le langage Shell, car cette construction va consister en une succession de commandes Unix.

== Choix des technologies pour le Repository : ==
Plusieurs solutions ont été considérées :
* [https://wiki.debian-fr.xyz/Reprepro '''Reprepro''']
* [https://www.aptly.info/ '''Aptly''']
* [https://wiki.debian.org/DakHowTo '''mini-dak''']

Finalement, notre choix s'est porté sur Aptly.

Pour simplifier la phase de développement, un container docker contenant un repository sera créé. Pour le déploiement, l'utilisation d'un serveur sera toutefois préféré.

Conception - Gestionnaire de packages

2017-02-02T13:45:47Z

Thibaut.Nouguier: /* Ensemble des fonctionnalités FrontEnd à implémenter : */

Voici le détail de la Conception du Projet 2017 : Gestionnaire de package.

[[Projet 2017 : Gestionnaire de packages Polytech| '''Page d'accueil du projet''']]

= Équipe =
* Rémi Gattaz
* Germain Lecorps (Chef de Projet)
* Thibaut Nouguier
* Régis Ramel (Scrum Master)

= Conception =
== Schéma de la structure de l'application ==
Nous avons tout d'abord réalisé une [[Gestionnaire de packages : Structure de l'application - version 1| première version du schéma de la structure de l'application]]. Cette représentation est abstraite, cela nous a permit de définir les principaux composants de l'application.

Nous avons ensuite précisé cette représentation en isolant la partie construction des packages (Builder) et en détaillant les fonctionnalités de chaque composants.
[[Image:Structure de l'application version 2.png|550px|center|Structure de l'application]]

== Ensemble des fonctionnalités BackEnd à implémenter : ==
* Lister les packages présents sur le repository
* Création d'un package en traitant l'archive (tar, zip, ...) déposée par un utilisateur
* Ajouter/Supprimer des packages
* Gérer les accès au repository :
** étudiant : une clé par année
** professeur : sur demande
* Rendre le repository disponible (permettre son ajout dans sources.list)
* Détecter les mises à jour de packages automatiquement
Technologies envisagées : Python (Gestion de CLI, API Rest), MySQL (Base de données/Repo), Shell (Build des packages)

== Ensemble des fonctionnalités FrontEnd à implémenter : ==
* Visualisation des packages disponibles
* Filtrage sur la visualisation des packages (Mots-Clés, Filière, Matière)
* Connexion utilisateur
* Dépôt d'une archive pour la création d'un package par un utilisateur authentifié
* Visualisation des tickets :
** ticket de création de package
** ticket de mise à jour d'un package
* Suppression d'un ticket de création d'un package / ticket de mise à jour d'un package par le créateur ou un administrateur
* Visualisation des logs pour les build de packages (Administrateur)

Technologies envisagées : HTML5, CSS3, AngularJS

== Choix des langages : ==
Pour la gestion du dépôt des demandes de packages, nous avons choisi Javascript avec l'utilisation de micro-services qui vont permettre une gestion de CLI et de l'API.
Pour la construction du package Debian, nous avons choisi d'utiliser le langage Shell, car cette construction va consister en une succession de commandes Unix.

== Choix des technologies pour le Repository : ==
Plusieurs solutions ont été considérées :
* [https://wiki.debian-fr.xyz/Reprepro '''Reprepro''']
* [https://www.aptly.info/ '''Aptly''']
* [https://wiki.debian.org/DakHowTo '''mini-dak''']

Finalement, notre choix s'est porté sur Aptly.

Pour simplifier la phase de développement, un container docker contenant un repository sera créé. Pour le déploiement, l'utilisation d'un serveur sera toutefois préféré.

Conception - Gestionnaire de packages

2017-02-02T13:42:07Z

Thibaut.Nouguier: /* Choix des technologies pour le Repository : */

Voici le détail de la Conception du Projet 2017 : Gestionnaire de package.

[[Projet 2017 : Gestionnaire de packages Polytech| '''Page d'accueil du projet''']]

= Équipe =
* Rémi Gattaz
* Germain Lecorps (Chef de Projet)
* Thibaut Nouguier
* Régis Ramel (Scrum Master)

= Conception =
== Schéma de la structure de l'application ==
Nous avons tout d'abord réalisé une [[Gestionnaire de packages : Structure de l'application - version 1| première version du schéma de la structure de l'application]]. Cette représentation est abstraite, cela nous a permit de définir les principaux composants de l'application.

Nous avons ensuite précisé cette représentation en isolant la partie construction des packages (Builder) et en détaillant les fonctionnalités de chaque composants.
[[Image:Structure de l'application version 2.png|550px|center|Structure de l'application]]

== Ensemble des fonctionnalités BackEnd à implémenter : ==
* Lister les packages présents sur le repository
* Création d'un package en traitant l'archive (tar, zip, ...) déposée par un utilisateur
* Ajouter/Supprimer des packages
* Gérer les accès au repository :
** étudiant : une clé par année
** professeur : sur demande
* Rendre le repository disponible (permettre son ajout dans sources.list)
* Détecter les mises à jour de packages automatiquement
Technologies envisagées : Python (Gestion de CLI, API Rest), MySQL (Base de données/Repo), Shell (Build des packages)

== Ensemble des fonctionnalités FrontEnd à implémenter : ==
* Visualisation des packages disponibles
* Filtrage sur la visualisation des packages (Mots-Clés, Filière, Matière)
* Connexion utilisateur
* Dépôt d'une archive pour la création d'un package par un utilisateur authentifié
* Visualisation des tickets :
** ticket de création de package
** ticket de mise à jour d'un package
* Suppression d'un ticket de création d'un package / ticket de mise à jour d'un package

Technologies envisagées : HTML5, CSS3, AngularJS

== Choix des langages : ==
Pour la gestion du dépôt des demandes de packages, nous avons choisi Javascript avec l'utilisation de micro-services qui vont permettre une gestion de CLI et de l'API.
Pour la construction du package Debian, nous avons choisi d'utiliser le langage Shell, car cette construction va consister en une succession de commandes Unix.

== Choix des technologies pour le Repository : ==
Plusieurs solutions ont été considérées :
* [https://wiki.debian-fr.xyz/Reprepro '''Reprepro''']
* [https://www.aptly.info/ '''Aptly''']
* [https://wiki.debian.org/DakHowTo '''mini-dak''']

Finalement, notre choix s'est porté sur Aptly.

Pour simplifier la phase de développement, un container docker contenant un repository sera créé. Pour le déploiement, l'utilisation d'un serveur sera toutefois préféré.

Conception - Gestionnaire de packages

2017-02-02T13:41:17Z

Thibaut.Nouguier: /* Ensemble des fonctionnalités FrontEnd à implémenter : */

Voici le détail de la Conception du Projet 2017 : Gestionnaire de package.

[[Projet 2017 : Gestionnaire de packages Polytech| '''Page d'accueil du projet''']]

= Équipe =
* Rémi Gattaz
* Germain Lecorps (Chef de Projet)
* Thibaut Nouguier
* Régis Ramel (Scrum Master)

= Conception =
== Schéma de la structure de l'application ==
Nous avons tout d'abord réalisé une [[Gestionnaire de packages : Structure de l'application - version 1| première version du schéma de la structure de l'application]]. Cette représentation est abstraite, cela nous a permit de définir les principaux composants de l'application.

Nous avons ensuite précisé cette représentation en isolant la partie construction des packages (Builder) et en détaillant les fonctionnalités de chaque composants.
[[Image:Structure de l'application version 2.png|550px|center|Structure de l'application]]

== Ensemble des fonctionnalités BackEnd à implémenter : ==
* Lister les packages présents sur le repository
* Création d'un package en traitant l'archive (tar, zip, ...) déposée par un utilisateur
* Ajouter/Supprimer des packages
* Gérer les accès au repository :
** étudiant : une clé par année
** professeur : sur demande
* Rendre le repository disponible (permettre son ajout dans sources.list)
* Détecter les mises à jour de packages automatiquement
Technologies envisagées : Python (Gestion de CLI, API Rest), MySQL (Base de données/Repo), Shell (Build des packages)

== Ensemble des fonctionnalités FrontEnd à implémenter : ==
* Visualisation des packages disponibles
* Filtrage sur la visualisation des packages (Mots-Clés, Filière, Matière)
* Connexion utilisateur
* Dépôt d'une archive pour la création d'un package par un utilisateur authentifié
* Visualisation des tickets :
** ticket de création de package
** ticket de mise à jour d'un package
* Suppression d'un ticket de création d'un package / ticket de mise à jour d'un package

Technologies envisagées : HTML5, CSS3, AngularJS

== Choix des langages : ==
Pour la gestion du dépôt des demandes de packages, nous avons choisi Javascript avec l'utilisation de micro-services qui vont permettre une gestion de CLI et de l'API.
Pour la construction du package Debian, nous avons choisi d'utiliser le langage Shell, car cette construction va consister en une succession de commandes Unix.

== Choix des technologies pour le Repository : ==
Plusieurs solutions ont été considérées :
* [https://wiki.debian-fr.xyz/Reprepro '''Reprepro''']
* [https://www.aptly.info/ '''Aptly''']
* [https://wiki.debian.org/DakHowTo '''mini-dak''']

Finalement, notre choix s'est porté sur XXX.

Pour simplifier la phase de développement, un container docker contenant un repository sera créé. Pour le déploiement, l'utilisation d'un serveur sera toutefois préféré.

Conception - Gestionnaire de packages

2017-02-02T13:37:41Z

Thibaut.Nouguier: /* Choix des langages : */

Voici le détail de la Conception du Projet 2017 : Gestionnaire de package.

[[Projet 2017 : Gestionnaire de packages Polytech| '''Page d'accueil du projet''']]

= Équipe =
* Rémi Gattaz
* Germain Lecorps (Chef de Projet)
* Thibaut Nouguier
* Régis Ramel (Scrum Master)

= Conception =
== Schéma de la structure de l'application ==
Nous avons tout d'abord réalisé une [[Gestionnaire de packages : Structure de l'application - version 1| première version du schéma de la structure de l'application]]. Cette représentation est abstraite, cela nous a permit de définir les principaux composants de l'application.

Nous avons ensuite précisé cette représentation en isolant la partie construction des packages (Builder) et en détaillant les fonctionnalités de chaque composants.
[[Image:Structure de l'application version 2.png|550px|center|Structure de l'application]]

== Ensemble des fonctionnalités BackEnd à implémenter : ==
* Lister les packages présents sur le repository
* Création d'un package en traitant l'archive (tar, zip, ...) déposée par un utilisateur
* Ajouter/Supprimer des packages
* Gérer les accès au repository :
** étudiant : une clé par année
** professeur : sur demande
* Rendre le repository disponible (permettre son ajout dans sources.list)
* Détecter les mises à jour de packages automatiquement
Technologies envisagées : Python (Gestion de CLI, API Rest), MySQL (Base de données/Repo), Shell (Build des packages)

== Ensemble des fonctionnalités FrontEnd à implémenter : ==
* Visualisation des packages disponibles
* Filtrage sur la visualisation des packages (Mots-Clés, Filière, Matière)
* Connexion utilisateur
* Dépôt d'une archive pour la création d'un package par un utilisateur authentifié
* Suppression d'un package existant par l'utilisateur qui a demandé sa création

Technologies envisagées : HTML5, CSS3, AngularJS

== Choix des langages : ==
Pour la gestion du dépôt des demandes de packages, nous avons choisi Javascript avec l'utilisation de micro-services qui vont permettre une gestion de CLI et de l'API.
Pour la construction du package Debian, nous avons choisi d'utiliser le langage Shell, car cette construction va consister en une succession de commandes Unix.

== Choix des technologies pour le Repository : ==
Plusieurs solutions ont été considérées :
* [https://wiki.debian-fr.xyz/Reprepro '''Reprepro''']
* [https://www.aptly.info/ '''Aptly''']
* [https://wiki.debian.org/DakHowTo '''mini-dak''']

Finalement, notre choix s'est porté sur XXX.

Pour simplifier la phase de développement, un container docker contenant un repository sera créé. Pour le déploiement, l'utilisation d'un serveur sera toutefois préféré.

Conception - Gestionnaire de packages

2017-02-02T13:35:53Z

Thibaut.Nouguier: /* Ensemble des fonctionnalités FrontEnd à implémenter : */

Voici le détail de la Conception du Projet 2017 : Gestionnaire de package.

[[Projet 2017 : Gestionnaire de packages Polytech| '''Page d'accueil du projet''']]

= Équipe =
* Rémi Gattaz
* Germain Lecorps (Chef de Projet)
* Thibaut Nouguier
* Régis Ramel (Scrum Master)

= Conception =
== Schéma de la structure de l'application ==
Nous avons tout d'abord réalisé une [[Gestionnaire de packages : Structure de l'application - version 1| première version du schéma de la structure de l'application]]. Cette représentation est abstraite, cela nous a permit de définir les principaux composants de l'application.

Nous avons ensuite précisé cette représentation en isolant la partie construction des packages (Builder) et en détaillant les fonctionnalités de chaque composants.
[[Image:Structure de l'application version 2.png|550px|center|Structure de l'application]]

== Ensemble des fonctionnalités BackEnd à implémenter : ==
* Lister les packages présents sur le repository
* Création d'un package en traitant l'archive (tar, zip, ...) déposée par un utilisateur
* Ajouter/Supprimer des packages
* Gérer les accès au repository :
** étudiant : une clé par année
** professeur : sur demande
* Rendre le repository disponible (permettre son ajout dans sources.list)
* Détecter les mises à jour de packages automatiquement
Technologies envisagées : Python (Gestion de CLI, API Rest), MySQL (Base de données/Repo), Shell (Build des packages)

== Ensemble des fonctionnalités FrontEnd à implémenter : ==
* Visualisation des packages disponibles
* Filtrage sur la visualisation des packages (Mots-Clés, Filière, Matière)
* Connexion utilisateur
* Dépôt d'une archive pour la création d'un package par un utilisateur authentifié
* Suppression d'un package existant par l'utilisateur qui a demandé sa création

Technologies envisagées : HTML5, CSS3, AngularJS

== Choix des langages : ==
Pour la gestion du dépôt des demandes de packages, nous avons choisi d'utiliser le Python car cela va permettre une gestion de CLI plus simple. De plus, ce langage va nous permettre de proposer une API Rest.
Pour la construction du package Debian, nous avons choisi d'utiliser le langage Shell, car cette construction va consister en une succession de commandes Unix.

== Choix des technologies pour le Repository : ==
Plusieurs solutions ont été considérées :
* [https://wiki.debian-fr.xyz/Reprepro '''Reprepro''']
* [https://www.aptly.info/ '''Aptly''']
* [https://wiki.debian.org/DakHowTo '''mini-dak''']

Finalement, notre choix s'est porté sur XXX.

Pour simplifier la phase de développement, un container docker contenant un repository sera créé. Pour le déploiement, l'utilisation d'un serveur sera toutefois préféré.

Conception - Gestionnaire de packages

2017-02-02T13:34:48Z

Thibaut.Nouguier: /* Ensemble des fonctionnalités BackEnd à implémenter : */

Voici le détail de la Conception du Projet 2017 : Gestionnaire de package.

[[Projet 2017 : Gestionnaire de packages Polytech| '''Page d'accueil du projet''']]

= Équipe =
* Rémi Gattaz
* Germain Lecorps (Chef de Projet)
* Thibaut Nouguier
* Régis Ramel (Scrum Master)

= Conception =
== Schéma de la structure de l'application ==
Nous avons tout d'abord réalisé une [[Gestionnaire de packages : Structure de l'application - version 1| première version du schéma de la structure de l'application]]. Cette représentation est abstraite, cela nous a permit de définir les principaux composants de l'application.

Nous avons ensuite précisé cette représentation en isolant la partie construction des packages (Builder) et en détaillant les fonctionnalités de chaque composants.
[[Image:Structure de l'application version 2.png|550px|center|Structure de l'application]]

== Ensemble des fonctionnalités BackEnd à implémenter : ==
* Lister les packages présents sur le repository
* Création d'un package en traitant l'archive (tar, zip, ...) déposée par un utilisateur
* Ajouter/Supprimer des packages
* Gérer les accès au repository :
** étudiant : une clé par année
** professeur : sur demande
* Rendre le repository disponible (permettre son ajout dans sources.list)
* Détecter les mises à jour de packages automatiquement
Technologies envisagées : Python (Gestion de CLI, API Rest), MySQL (Base de données/Repo), Shell (Build des packages)

== Ensemble des fonctionnalités FrontEnd à implémenter : ==
* Visualisation des packages disponibles
* Filtrage sur la visualisation des packages (Mots-Clés, Filière, Matière)
* Connexion utilisateur
* Dépôt d'une archive pour la création d'un package par un utilisateur authentifié
* Suppression d'un package existant par l'utilisateur qui a demandé sa création

Technologies envisagées : HTML5, Javascript, MySQL

== Choix des langages : ==
Pour la gestion du dépôt des demandes de packages, nous avons choisi d'utiliser le Python car cela va permettre une gestion de CLI plus simple. De plus, ce langage va nous permettre de proposer une API Rest.
Pour la construction du package Debian, nous avons choisi d'utiliser le langage Shell, car cette construction va consister en une succession de commandes Unix.

== Choix des technologies pour le Repository : ==
Plusieurs solutions ont été considérées :
* [https://wiki.debian-fr.xyz/Reprepro '''Reprepro''']
* [https://www.aptly.info/ '''Aptly''']
* [https://wiki.debian.org/DakHowTo '''mini-dak''']

Finalement, notre choix s'est porté sur XXX.

Pour simplifier la phase de développement, un container docker contenant un repository sera créé. Pour le déploiement, l'utilisation d'un serveur sera toutefois préféré.

File:VT2016 OpenTSDB pres.pdf

2016-11-05T09:23:38Z

Thibaut.Nouguier:

VT2016 OpenTSDB

2016-11-01T13:12:45Z

Thibaut.Nouguier:

= Présentation =

* Sujet : OpenTSDB
* Auteur : Thibaut NOUGUIER
* Enseignants : Didier DONSEZ, Georges-Pierre BONNEAU

= Mot clés =
Base de données de séries chronologique, Time Series Daemon, HBase.

= Résumé =
OpenTSDB est une base de données de séries chronologiques. Chaque serveur communique ses informations à son Time Series Daemon (TSD) qui par la suite les enregistre dans HBase. Les TSDs sont aussi capables de récupérer les données stockées pour permettrent leur visualisation par un utilisateur. Il est aussi possible de mettre en place des routines (alertes, messages, ...), dans le but d'informer l'utilisateur lorsque cela est nécessaire.

= Abstract =
OpenTSDB is a time series database. Each server sends his data to his own Time Series Daemon (TSD), and then it store it into HBase. TSDs are able to get stored data in order to show it to an user. It is also possible to create routines (alerts, messages, ...) in order to inform users of anything.

= Synthèse =
== Contexte ==
De nos jours, le stockage en continue d'importante quantité de données est habituel, cependant il est difficile de le faire via des bases de données relationnelles classiques.

=== Objectifs ===
Les bases de données de séries chronologiques ont principalement deux objectifs :
* Le stockage de données horodatées de source et de nature diverses (températures, humidité, ...).
* La visualisation de celles-ci sous forme de graphique.

=== Problèmatique ===
* Stockage de point : nom + timestamp + valeur + tags.
* Stockage de masse de l'odre de la dizaine de millions de points par an.
* Fonctionnalités mathématiques telles que : comptages, moyennes, interpolations, lissages, maximums, minimums...

== Historique ==
=== RRD Tool===
* Elle est la première base de données de séries chronologiques.
* Il est difficile de l'exploiter au quotidien (sauvegarde, export, scalabilité).
* La précision des données se fait au détriment de la taille de la base.

 
Les bases de données suivantes ont toutes ces points communs :
* Une architecture industrielle et scalable.
* Une API permettant le stockage et requetage des données.
* Des fonctions mathématiques intégrées.

=== Whisper ===
* Elle est vue comme la transition entre RRD Tool et les TSDB suivantes.
* Elle est difficilement utilisable sans le projet Graphite.

=== KairosDB ===
* Elle est très similaire à OpenTSDB, si ce n'est qu'elle peut s'utiliser avec H2 ou Cassandra en plus d'HBase.

=== InfluxDB ===
* Elle est capable de stocker des événements en plus des points.
* Elle est basée sur LevelDB, la librairie clé / valeur écrite par Google.

== Fonctionnement ==
Les caractéristiques principales d'OpenTSDB sont les suivantes :
* Une architecture scalable.
* Une API pour la lecture et l'écriture des données.
* Des opérations statistiques intégrées.
* Une capacité de stockage à la milliseconde.
* Le stockage d'un milliard de points par jour.

[[Image:NOUGUIER-tsdb-architecture.png|400px|left center|Architecture]]

La lecture et l'écriture des données se fait via les Time Series Daemon. En effet chaque serveur est lié à un TSD et lui communique ses données. Ensuite, le TSD dans un délais d'une seconde maximum, va enregistrer ces informations dans HBase. Des routines internes au TSD peuvent être déclenchées lors du passage des données. Pour permettre la visualisation du contenu de HBase le TSD peut récupérer les données et les envoyer aux utilisateurs via une page internet.

=== Evolutivité ===
* Un TSD par cluster HBase, un cluster HBase par datacenter.
* Capacité d'écriture : 2000 points (minimum) par seconde et par coeur.
* Capacité de lecture : moins de 2 secondes.

=== Fiabilité ===
* Echec : sauvegarde dans un buffer si HBase ne fonctionne plus.
* Persistance des données : les données restent 1 seconde maximum dans le buffer d'un TSD avant d'être enregistrées dans HBase.

= Démonstration =
* La démonstration consiste à lancer une image docker localement contenant OpenTSDB et HBase préconfigués.
sudo docker pull petergrace/opentsdb-docker
sudo docker start --attach container_id

* Ensuite il faut se connecter à OpenTSDB localement via le protocole telnet (ou via http).
telnet localhost 4242

* Parallèlement j'ai créé un script bash générant des sorties simulant les connexions, les achats et les ventes d'un site de commerce sur une journée.
# Nombre de connexions par heure
heure=0
valeur=( "1000" "900" "700" "400" "100" "40" "150" "500" "1600" "3700" "600" "4500" "9800" "10000" "9900" "4800" "3100" "2600" "1500" "2500" "2900" "3300" "3100" "2000" )
timestamp=1477954800

while [ "$heure" != 24 ]
do
echo "put connexions $timestamp ${valeur[$heure]} particulier=1"
timestamp=$(( $timestamp + 3600 ))
heure=$(( $heure + 1 ))
done

# Nombre d'achats par heure
heure=0
valeur=( "100" "60" "10" "0" "0" "0" "0" "20" "100" "1000" "300" "1700" "4000" "5300" "4300" "2000" "600" "300" "70" "200" "300" "500" "400" "100" )
timestamp=1477954800

while [ "$heure" != 24 ]
do
echo "put achats $timestamp ${valeur[$heure]} particulier=1"
timestamp=$(( $timestamp + 3600 ))
heure=$(( $heure + 1 ))
done

# Nombre de ventes par heure
heure=0
valeur=( "150" "20" "0" "0" "0" "0" "20" "40" "200" "500" "200" "1000" "2000" "3000" "5800" "4500" "2000" "200" "100" "400" "1000" "700" "100" "150" )
timestamp=1477954800

while [ "$heure" != 24 ]
do
echo "put ventes $timestamp ${valeur[$heure]} particulier=1"
timestamp=$(( $timestamp + 3600 ))
heure=$(( $heure + 1 ))
done

* Ensuite il faut rediriger la sortie du script vers la commande telnet que j'ai lancé avant, ce qui aura pour effet d'ajouter toutes les valeurs dans la base de données.

 
[[Image:NOUGUIER DEMO OpenTSDB.png|1200px|left center|Demo]]
 

* Voici donc le résultat dans OpenTSDB. Grâce au graphique, différentes analyses et interprétations peuvent être faites :
** Les connexions / achats / ventes en fonctions de l'heure.
** Les achats / ventes en fonctions des connexions.

= Webographie =
* http://opentsdb.net/
* https://wooster.checkmy.ws/2013/12/time-series-databases/
* https://en.wikipedia.org/wiki/Time_series_database
* http://fr.slideshare.net/HBaseCon/ecosystem-session-6?next_slideshow=1

VT2016 OpenTSDB

2016-11-01T13:08:27Z

Thibaut.Nouguier:

VT2016 OpenTSDB

2016-11-01T13:02:51Z

Thibaut.Nouguier: /* Démonstration */

= Présentation =

* Sujet : OpenTSDB
* Auteur : Thibaut NOUGUIER
* Enseignants : Didier DONSEZ, Georges-Pierre BONNEAU

= Mot clés =
Base de données de séries chronologique, Time Series Daemon, HBase.

= Résumé =
OpenTSDB est une base de données de séries chronologique. Chaque serveur communique ses informations à son Time Series Daemon (TSD) qui par la suite les enregistre dans HBase. Les TSDs sont aussi capables de récupérer les données stockées pour permettrent leur visualisation par un utilisateur. Il est aussi possible de mettre en place des routines (alertes, messages, ...), dans le but d'informer l'utilisateur lorsque cela est nécessaire.

= Abstract =
OpenTSDB is a time series database. Each server sends his data to his own Time Series Daemon (TSD), and then it store it into HBase. TSDs are able to get stored data in order to show it to an user. It is also possible to create routines (alerts, messages, ...) in order to inform users of anything.

= Synthèse =
== Contexte ==
De nos jours, le stockage en continue d'importante quantité de données est habituel, cependant il est difficile de le faire via des bases de données relationnelles classiques.

=== Objectifs ===
Les bases de données de séries chronologiques ont principalement deux objectifs :
* Le stockage de données horodatées de source et de nature diverses (températures, humidité, ...).
* La visualisation de celles-ci sous forme de graphique.

=== Problèmatique ===
* Stockage de point : nom + timestamp + valeur + tags.
* Stockage de masse de l'odre de la dizaine de millions par an.
* Fonctionnalités mathématiques telles que : comptages, moyennes, interpolations, lissages, maximums, minimums...

== Historique ==
=== RRD Tool===
* Elle est la première base de données de séries chronologiques.
* Il est difficile de l'exploiter au quotidien (sauvegarde, export, scalabilité).
* La précision des données se fait au détriment de la taille de la base.

 
Les bases de données suivantes ont toutes ces points communs :
* Une architecture industrielle et scalable.
* Une API permettant le stockage et requetage des données.
* Des fonctions mathématiques intégrées.

=== Whisper ===
* Elle est vue comme la transition entre RRD Tool et les TSDB suivantes.
* Elle est difficilement utilisable sans le projet Graphite.

=== KairosDB ===
* Elle est très similaire à OpenTSDB si ce n'est qu'elle peut s'utiliser avec H2 ou Cassandra en plus d'HBase.

=== InfluxDB ===
* Elle est capable de stocker des événements en plus des points.
* Elle est basée sur LevelDB, la librairie clé / valeur écrite pour être rapide par Google.

== Fonctionnement ==
Les caractéristiques principales d'OpenTSDB sont les suivantes :
* Une architecture scalable.
* Une API pour la lecture et l'écriture des données.
* Des opérations statistiques intégrées.
* Une capacité de stockage à la milliseconde.
* Le stockage d'un milliard de points par jour.

[[Image:NOUGUIER-tsdb-architecture.png|400px|left center|Architecture]]

La lecture et l'écriture des données se fait via les Time Series Daemon. En effet chaque serveur est lié à un TSD et lui communique ses données. Ensuite, le TSD dans un délais d'une seconde maximum, va enregistrer ces informations dans HBase. Des routines internes au TSD peuvent être déclenchées lors du passage des données. Pour permettre la visualisation du contenu de HBase le TSD peut récupérer les données et les envoyer aux utilisateurs via une page internet.

=== Evolutivité ===
* Un TSD par cluster HBase, un cluster HBase par datacenter.
* Capacité d'écriture : 2000 points (minimum) par secondes et par coeur.
* Capacité de lecture : moins de 2 secondes.

=== Fiabilité ===
* Echec : sauvegarde dans un buffer si HBase ne fonctionne plus.
* Persistance des données : les données restent 1 seconde maximum dans le buffer d'un TSD avant d'être enregistrées dans HBase.

= Démonstration =
* La démonstration consiste à lancer une image docker localement contenant OpenTSDB et HBase préconfigués.
sudo docker pull petergrace/opentsdb-docker
sudo docker start --attach container_id

* Ensuite il faut se connecter à OpenTSDB localement via le protocole telnet (ou via http si ce n'est pas du locale).
telnet localhost 4242

* Parallèlement j'ai créé un script bash générant des sorties simulant les connexions, les achats et les ventes d'un site de commerce sur une journée.
# Nombre de connexions par heure
heure=0
valeur=( "1000" "900" "700" "400" "100" "40" "150" "500" "1600" "3700" "600" "4500" "9800" "10000" "9900" "4800" "3100" "2600" "1500" "2500" "2900" "3300" "3100" "2000" )
timestamp=1477954800

while [ "$heure" != 24 ]
do
echo "put connexions $timestamp ${valeur[$heure]} particulier=1"
timestamp=$(( $timestamp + 3600 ))
heure=$(( $heure + 1 ))
done

# Nombre d'achats par heure
heure=0
valeur=( "100" "60" "10" "0" "0" "0" "0" "20" "100" "1000" "300" "1700" "4000" "5300" "4300" "2000" "600" "300" "70" "200" "300" "500" "400" "100" )
timestamp=1477954800

while [ "$heure" != 24 ]
do
echo "put achats $timestamp ${valeur[$heure]} particulier=1"
timestamp=$(( $timestamp + 3600 ))
heure=$(( $heure + 1 ))
done

# Nombre de ventes par heure
heure=0
valeur=( "150" "20" "0" "0" "0" "0" "20" "40" "200" "500" "200" "1000" "2000" "3000" "5800" "4500" "2000" "200" "100" "400" "1000" "700" "100" "150" )
timestamp=1477954800

while [ "$heure" != 24 ]
do
echo "put ventes $timestamp ${valeur[$heure]} particulier=1"
timestamp=$(( $timestamp + 3600 ))
heure=$(( $heure + 1 ))
done

* Ensuite il faut rediriger la sortie du script vers la commande telnet que j'ai lancé avant, ce qui aura pour effet d'ajouter toutes les valeurs dans la base de données.

 
[[Image:NOUGUIER DEMO OpenTSDB.png|1200px|left center|Demo]]
 

* Voici donc le résultat dans OpenTSDB. Grâce au graphique différentes analyses et interprétations peuvent être faites :
** Les connexions / achats / ventes en fonctions de l'heure.
** Les achats / ventes en fonctions des connexions.

= Webographie =
* http://opentsdb.net/
* https://wooster.checkmy.ws/2013/12/time-series-databases/
* https://en.wikipedia.org/wiki/Time_series_database

VT2016 OpenTSDB

2016-11-01T13:02:27Z

Thibaut.Nouguier: /* Synthèse */

= Présentation =

* Sujet : OpenTSDB
* Auteur : Thibaut NOUGUIER
* Enseignants : Didier DONSEZ, Georges-Pierre BONNEAU

= Mot clés =
Base de données de séries chronologique, Time Series Daemon, HBase.

= Résumé =
OpenTSDB est une base de données de séries chronologique. Chaque serveur communique ses informations à son Time Series Daemon (TSD) qui par la suite les enregistre dans HBase. Les TSDs sont aussi capables de récupérer les données stockées pour permettrent leur visualisation par un utilisateur. Il est aussi possible de mettre en place des routines (alertes, messages, ...), dans le but d'informer l'utilisateur lorsque cela est nécessaire.

= Abstract =
OpenTSDB is a time series database. Each server sends his data to his own Time Series Daemon (TSD), and then it store it into HBase. TSDs are able to get stored data in order to show it to an user. It is also possible to create routines (alerts, messages, ...) in order to inform users of anything.

= Synthèse =
== Contexte ==
De nos jours, le stockage en continue d'importante quantité de données est habituel, cependant il est difficile de le faire via des bases de données relationnelles classiques.

=== Objectifs ===
Les bases de données de séries chronologiques ont principalement deux objectifs :
* Le stockage de données horodatées de source et de nature diverses (températures, humidité, ...).
* La visualisation de celles-ci sous forme de graphique.

=== Problèmatique ===
* Stockage de point : nom + timestamp + valeur + tags.
* Stockage de masse de l'odre de la dizaine de millions par an.
* Fonctionnalités mathématiques telles que : comptages, moyennes, interpolations, lissages, maximums, minimums...

== Historique ==
=== RRD Tool===
* Elle est la première base de données de séries chronologiques.
* Il est difficile de l'exploiter au quotidien (sauvegarde, export, scalabilité).
* La précision des données se fait au détriment de la taille de la base.

 
Les bases de données suivantes ont toutes ces points communs :
* Une architecture industrielle et scalable.
* Une API permettant le stockage et requetage des données.
* Des fonctions mathématiques intégrées.

=== Whisper ===
* Elle est vue comme la transition entre RRD Tool et les TSDB suivantes.
* Elle est difficilement utilisable sans le projet Graphite.

=== KairosDB ===
* Elle est très similaire à OpenTSDB si ce n'est qu'elle peut s'utiliser avec H2 ou Cassandra en plus d'HBase.

=== InfluxDB ===
* Elle est capable de stocker des événements en plus des points.
* Elle est basée sur LevelDB, la librairie clé / valeur écrite pour être rapide par Google.

== Fonctionnement ==
Les caractéristiques principales d'OpenTSDB sont les suivantes :
* Une architecture scalable.
* Une API pour la lecture et l'écriture des données.
* Des opérations statistiques intégrées.
* Une capacité de stockage à la milliseconde.
* Le stockage d'un milliard de points par jour.

[[Image:NOUGUIER-tsdb-architecture.png|400px|left center|Architecture]]

La lecture et l'écriture des données se fait via les Time Series Daemon. En effet chaque serveur est lié à un TSD et lui communique ses données. Ensuite, le TSD dans un délais d'une seconde maximum, va enregistrer ces informations dans HBase. Des routines internes au TSD peuvent être déclenchées lors du passage des données. Pour permettre la visualisation du contenu de HBase le TSD peut récupérer les données et les envoyer aux utilisateurs via une page internet.

=== Evolutivité ===
* Un TSD par cluster HBase, un cluster HBase par datacenter.
* Capacité d'écriture : 2000 points (minimum) par secondes et par coeur.
* Capacité de lecture : moins de 2 secondes.

=== Fiabilité ===
* Echec : sauvegarde dans un buffer si HBase ne fonctionne plus.
* Persistance des données : les données restent 1 seconde maximum dans le buffer d'un TSD avant d'être enregistrées dans HBase.

= Démonstration =
* La démonstration consiste à lancer une image docker localement contenant OpenTSDB et HBase préconfigués.
sudo docker pull petergrace/opentsdb-docker
sudo docker start --attach container_id

* Ensuite il faut se connecter à OpenTSDB localement via le protocole telnet (ou via http si ce n'est pas du locale).
telnet localhost 4242

* Parallèlement j'ai créé un script bash générant des sorties simulant les connexions, les achats et les ventes d'un site de commerce sur une journée.
# Nombre de connexions par heure
heure=0
valeur=( "1000" "900" "700" "400" "100" "40" "150" "500" "1600" "3700" "600" "4500" "9800" "10000" "9900" "4800" "3100" "2600" "1500" "2500" "2900" "3300" "3100" "2000" )
timestamp=1477954800

while [ "$heure" != 24 ]
do
echo "put connexions $timestamp ${valeur[$heure]} particulier=1"
timestamp=$(( $timestamp + 3600 ))
heure=$(( $heure + 1 ))
done

# Nombre d'achats par heure
heure=0
valeur=( "100" "60" "10" "0" "0" "0" "0" "20" "100" "1000" "300" "1700" "4000" "5300" "4300" "2000" "600" "300" "70" "200" "300" "500" "400" "100" )
timestamp=1477954800

while [ "$heure" != 24 ]
do
echo "put achats $timestamp ${valeur[$heure]} particulier=1"
timestamp=$(( $timestamp + 3600 ))
heure=$(( $heure + 1 ))
done

# Nombre de ventes par heure
heure=0
valeur=( "150" "20" "0" "0" "0" "0" "20" "40" "200" "500" "200" "1000" "2000" "3000" "5800" "4500" "2000" "200" "100" "400" "1000" "700" "100" "150" )
timestamp=1477954800

while [ "$heure" != 24 ]
do
echo "put ventes $timestamp ${valeur[$heure]} particulier=1"
timestamp=$(( $timestamp + 3600 ))
heure=$(( $heure + 1 ))
done

* Ensuite il faut rediriger la sortie du script vers la commande telnet que j'ai lancé avant, ce qui aura pour effet d'ajouter toutes les valeurs dans la base de données.

[[Image:NOUGUIER DEMO OpenTSDB.png|1200px|left center|Demo]]

* Voici donc le résultat dans OpenTSDB. Grâce au graphique différentes analyses et interprétations peuvent être faites :
** Les connexions / achats / ventes en fonctions de l'heure.
** Les achats / ventes en fonctions des connexions.

= Webographie =
* http://opentsdb.net/
* https://wooster.checkmy.ws/2013/12/time-series-databases/
* https://en.wikipedia.org/wiki/Time_series_database

VT2016 OpenTSDB

2016-11-01T13:01:43Z

Thibaut.Nouguier: /* */

= Présentation =

* Sujet : OpenTSDB
* Auteur : Thibaut NOUGUIER
* Enseignants : Didier DONSEZ, Georges-Pierre BONNEAU

= Mot clés =
Base de données de séries chronologique, Time Series Daemon, HBase.

= Résumé =
OpenTSDB est une base de données de séries chronologique. Chaque serveur communique ses informations à son Time Series Daemon (TSD) qui par la suite les enregistre dans HBase. Les TSDs sont aussi capables de récupérer les données stockées pour permettrent leur visualisation par un utilisateur. Il est aussi possible de mettre en place des routines (alertes, messages, ...), dans le but d'informer l'utilisateur lorsque cela est nécessaire.

= Abstract =
OpenTSDB is a time series database. Each server sends his data to his own Time Series Daemon (TSD), and then it store it into HBase. TSDs are able to get stored data in order to show it to an user. It is also possible to create routines (alerts, messages, ...) in order to inform users of anything.

= Synthèse =
== Contexte ==
De nos jours, le stockage en continue d'importante quantité de données est habituel, cependant il est difficile de le faire via des bases de données relationnelles classiques.

=== Objectifs ===
Les bases de données de séries chronologiques ont principalement deux objectifs :
* Le stockage de données horodatées de source et de nature diverses (températures, humidité, ...).
* La visualisation de celles-ci sous forme de graphique.

=== Problèmatique ===
* Stockage de point : nom + timestamp + valeur + tags.
* Stockage de masse de l'odre de la dizaine de millions par an.
* Fonctionnalités mathématiques telles que : comptages, moyennes, interpolations, lissages, maximums, minimums...

== Historique ==
=== RRD Tool===
* Elle est la première base de données de séries chronologiques.
* Il est difficile de l'exploiter au quotidien (sauvegarde, export, scalabilité).
* La précision des données se fait au détriment de la taille de la base.

=== ===
Les bases de données suivantes ont toutes ces points communs :
* Une architecture industrielle et scalable.
* Une API permettant le stockage et requetage des données.
* Des fonctions mathématiques intégrées.

=== Whisper ===
* Elle est vue comme la transition entre RRD Tool et les TSDB suivantes.
* Elle est difficilement utilisable sans le projet Graphite.

=== KairosDB ===
* Elle est très similaire à OpenTSDB si ce n'est qu'elle peut s'utiliser avec H2 ou Cassandra en plus d'HBase.

=== InfluxDB ===
* Elle est capable de stocker des événements en plus des points.
* Elle est basée sur LevelDB, la librairie clé / valeur écrite pour être rapide par Google.

== Fonctionnement ==
Les caractéristiques principales d'OpenTSDB sont les suivantes :
* Une architecture scalable.
* Une API pour la lecture et l'écriture des données.
* Des opérations statistiques intégrées.
* Une capacité de stockage à la milliseconde.
* Le stockage d'un milliard de points par jour.

[[Image:NOUGUIER-tsdb-architecture.png|400px|left center|Architecture]]

La lecture et l'écriture des données se fait via les Time Series Daemon. En effet chaque serveur est lié à un TSD et lui communique ses données. Ensuite, le TSD dans un délais d'une seconde maximum, va enregistrer ces informations dans HBase. Des routines internes au TSD peuvent être déclenchées lors du passage des données. Pour permettre la visualisation du contenu de HBase le TSD peut récupérer les données et les envoyer aux utilisateurs via une page internet.

=== Evolutivité ===
* Un TSD par cluster HBase, un cluster HBase par datacenter.
* Capacité d'écriture : 2000 points (minimum) par secondes et par coeur.
* Capacité de lecture : moins de 2 secondes.

=== Fiabilité ===
* Echec : sauvegarde dans un buffer si HBase ne fonctionne plus.
* Persistance des données : les données restent 1 seconde maximum dans le buffer d'un TSD avant d'être enregistrées dans HBase.

= Démonstration =
* La démonstration consiste à lancer une image docker localement contenant OpenTSDB et HBase préconfigués.
sudo docker pull petergrace/opentsdb-docker
sudo docker start --attach container_id

* Ensuite il faut se connecter à OpenTSDB localement via le protocole telnet (ou via http si ce n'est pas du locale).
telnet localhost 4242

* Parallèlement j'ai créé un script bash générant des sorties simulant les connexions, les achats et les ventes d'un site de commerce sur une journée.
# Nombre de connexions par heure
heure=0
valeur=( "1000" "900" "700" "400" "100" "40" "150" "500" "1600" "3700" "600" "4500" "9800" "10000" "9900" "4800" "3100" "2600" "1500" "2500" "2900" "3300" "3100" "2000" )
timestamp=1477954800

while [ "$heure" != 24 ]
do
echo "put connexions $timestamp ${valeur[$heure]} particulier=1"
timestamp=$(( $timestamp + 3600 ))
heure=$(( $heure + 1 ))
done

# Nombre d'achats par heure
heure=0
valeur=( "100" "60" "10" "0" "0" "0" "0" "20" "100" "1000" "300" "1700" "4000" "5300" "4300" "2000" "600" "300" "70" "200" "300" "500" "400" "100" )
timestamp=1477954800

while [ "$heure" != 24 ]
do
echo "put achats $timestamp ${valeur[$heure]} particulier=1"
timestamp=$(( $timestamp + 3600 ))
heure=$(( $heure + 1 ))
done

# Nombre de ventes par heure
heure=0
valeur=( "150" "20" "0" "0" "0" "0" "20" "40" "200" "500" "200" "1000" "2000" "3000" "5800" "4500" "2000" "200" "100" "400" "1000" "700" "100" "150" )
timestamp=1477954800

while [ "$heure" != 24 ]
do
echo "put ventes $timestamp ${valeur[$heure]} particulier=1"
timestamp=$(( $timestamp + 3600 ))
heure=$(( $heure + 1 ))
done

* Ensuite il faut rediriger la sortie du script vers la commande telnet que j'ai lancé avant, ce qui aura pour effet d'ajouter toutes les valeurs dans la base de données.

[[Image:NOUGUIER DEMO OpenTSDB.png|1200px|left center|Demo]]

* Voici donc le résultat dans OpenTSDB. Grâce au graphique différentes analyses et interprétations peuvent être faites :
** Les connexions / achats / ventes en fonctions de l'heure.
** Les achats / ventes en fonctions des connexions.

= Webographie =
* http://opentsdb.net/
* https://wooster.checkmy.ws/2013/12/time-series-databases/
* https://en.wikipedia.org/wiki/Time_series_database

VT2016 OpenTSDB

2016-11-01T13:01:32Z

Thibaut.Nouguier: /* */

= Présentation =

* Sujet : OpenTSDB
* Auteur : Thibaut NOUGUIER
* Enseignants : Didier DONSEZ, Georges-Pierre BONNEAU

= Mot clés =
Base de données de séries chronologique, Time Series Daemon, HBase.

= Résumé =
OpenTSDB est une base de données de séries chronologique. Chaque serveur communique ses informations à son Time Series Daemon (TSD) qui par la suite les enregistre dans HBase. Les TSDs sont aussi capables de récupérer les données stockées pour permettrent leur visualisation par un utilisateur. Il est aussi possible de mettre en place des routines (alertes, messages, ...), dans le but d'informer l'utilisateur lorsque cela est nécessaire.

= Abstract =
OpenTSDB is a time series database. Each server sends his data to his own Time Series Daemon (TSD), and then it store it into HBase. TSDs are able to get stored data in order to show it to an user. It is also possible to create routines (alerts, messages, ...) in order to inform users of anything.

= Synthèse =
== Contexte ==
De nos jours, le stockage en continue d'importante quantité de données est habituel, cependant il est difficile de le faire via des bases de données relationnelles classiques.

=== Objectifs ===
Les bases de données de séries chronologiques ont principalement deux objectifs :
* Le stockage de données horodatées de source et de nature diverses (températures, humidité, ...).
* La visualisation de celles-ci sous forme de graphique.

=== Problèmatique ===
* Stockage de point : nom + timestamp + valeur + tags.
* Stockage de masse de l'odre de la dizaine de millions par an.
* Fonctionnalités mathématiques telles que : comptages, moyennes, interpolations, lissages, maximums, minimums...

== Historique ==
=== RRD Tool===
* Elle est la première base de données de séries chronologiques.
* Il est difficile de l'exploiter au quotidien (sauvegarde, export, scalabilité).
* La précision des données se fait au détriment de la taille de la base.

=== ===

Les bases de données suivantes ont toutes ces points communs :
* Une architecture industrielle et scalable.
* Une API permettant le stockage et requetage des données.
* Des fonctions mathématiques intégrées.

=== Whisper ===
* Elle est vue comme la transition entre RRD Tool et les TSDB suivantes.
* Elle est difficilement utilisable sans le projet Graphite.

=== KairosDB ===
* Elle est très similaire à OpenTSDB si ce n'est qu'elle peut s'utiliser avec H2 ou Cassandra en plus d'HBase.

=== InfluxDB ===
* Elle est capable de stocker des événements en plus des points.
* Elle est basée sur LevelDB, la librairie clé / valeur écrite pour être rapide par Google.

== Fonctionnement ==
Les caractéristiques principales d'OpenTSDB sont les suivantes :
* Une architecture scalable.
* Une API pour la lecture et l'écriture des données.
* Des opérations statistiques intégrées.
* Une capacité de stockage à la milliseconde.
* Le stockage d'un milliard de points par jour.

[[Image:NOUGUIER-tsdb-architecture.png|400px|left center|Architecture]]

La lecture et l'écriture des données se fait via les Time Series Daemon. En effet chaque serveur est lié à un TSD et lui communique ses données. Ensuite, le TSD dans un délais d'une seconde maximum, va enregistrer ces informations dans HBase. Des routines internes au TSD peuvent être déclenchées lors du passage des données. Pour permettre la visualisation du contenu de HBase le TSD peut récupérer les données et les envoyer aux utilisateurs via une page internet.

=== Evolutivité ===
* Un TSD par cluster HBase, un cluster HBase par datacenter.
* Capacité d'écriture : 2000 points (minimum) par secondes et par coeur.
* Capacité de lecture : moins de 2 secondes.

=== Fiabilité ===
* Echec : sauvegarde dans un buffer si HBase ne fonctionne plus.
* Persistance des données : les données restent 1 seconde maximum dans le buffer d'un TSD avant d'être enregistrées dans HBase.

= Démonstration =
* La démonstration consiste à lancer une image docker localement contenant OpenTSDB et HBase préconfigués.
sudo docker pull petergrace/opentsdb-docker
sudo docker start --attach container_id

* Ensuite il faut se connecter à OpenTSDB localement via le protocole telnet (ou via http si ce n'est pas du locale).
telnet localhost 4242

* Parallèlement j'ai créé un script bash générant des sorties simulant les connexions, les achats et les ventes d'un site de commerce sur une journée.
# Nombre de connexions par heure
heure=0
valeur=( "1000" "900" "700" "400" "100" "40" "150" "500" "1600" "3700" "600" "4500" "9800" "10000" "9900" "4800" "3100" "2600" "1500" "2500" "2900" "3300" "3100" "2000" )
timestamp=1477954800

while [ "$heure" != 24 ]
do
echo "put connexions $timestamp ${valeur[$heure]} particulier=1"
timestamp=$(( $timestamp + 3600 ))
heure=$(( $heure + 1 ))
done

# Nombre d'achats par heure
heure=0
valeur=( "100" "60" "10" "0" "0" "0" "0" "20" "100" "1000" "300" "1700" "4000" "5300" "4300" "2000" "600" "300" "70" "200" "300" "500" "400" "100" )
timestamp=1477954800

while [ "$heure" != 24 ]
do
echo "put achats $timestamp ${valeur[$heure]} particulier=1"
timestamp=$(( $timestamp + 3600 ))
heure=$(( $heure + 1 ))
done

# Nombre de ventes par heure
heure=0
valeur=( "150" "20" "0" "0" "0" "0" "20" "40" "200" "500" "200" "1000" "2000" "3000" "5800" "4500" "2000" "200" "100" "400" "1000" "700" "100" "150" )
timestamp=1477954800

while [ "$heure" != 24 ]
do
echo "put ventes $timestamp ${valeur[$heure]} particulier=1"
timestamp=$(( $timestamp + 3600 ))
heure=$(( $heure + 1 ))
done

* Ensuite il faut rediriger la sortie du script vers la commande telnet que j'ai lancé avant, ce qui aura pour effet d'ajouter toutes les valeurs dans la base de données.

[[Image:NOUGUIER DEMO OpenTSDB.png|1200px|left center|Demo]]

* Voici donc le résultat dans OpenTSDB. Grâce au graphique différentes analyses et interprétations peuvent être faites :
** Les connexions / achats / ventes en fonctions de l'heure.
** Les achats / ventes en fonctions des connexions.

= Webographie =
* http://opentsdb.net/
* https://wooster.checkmy.ws/2013/12/time-series-databases/
* https://en.wikipedia.org/wiki/Time_series_database

VT2016 OpenTSDB

2016-11-01T13:01:08Z

Thibaut.Nouguier: /* Synthèse */

= Présentation =

* Sujet : OpenTSDB
* Auteur : Thibaut NOUGUIER
* Enseignants : Didier DONSEZ, Georges-Pierre BONNEAU

= Mot clés =
Base de données de séries chronologique, Time Series Daemon, HBase.

= Résumé =
OpenTSDB est une base de données de séries chronologique. Chaque serveur communique ses informations à son Time Series Daemon (TSD) qui par la suite les enregistre dans HBase. Les TSDs sont aussi capables de récupérer les données stockées pour permettrent leur visualisation par un utilisateur. Il est aussi possible de mettre en place des routines (alertes, messages, ...), dans le but d'informer l'utilisateur lorsque cela est nécessaire.

= Abstract =
OpenTSDB is a time series database. Each server sends his data to his own Time Series Daemon (TSD), and then it store it into HBase. TSDs are able to get stored data in order to show it to an user. It is also possible to create routines (alerts, messages, ...) in order to inform users of anything.

= Synthèse =
== Contexte ==
De nos jours, le stockage en continue d'importante quantité de données est habituel, cependant il est difficile de le faire via des bases de données relationnelles classiques.

=== Objectifs ===
Les bases de données de séries chronologiques ont principalement deux objectifs :
* Le stockage de données horodatées de source et de nature diverses (températures, humidité, ...).
* La visualisation de celles-ci sous forme de graphique.

=== Problèmatique ===
* Stockage de point : nom + timestamp + valeur + tags.
* Stockage de masse de l'odre de la dizaine de millions par an.
* Fonctionnalités mathématiques telles que : comptages, moyennes, interpolations, lissages, maximums, minimums...

== Historique ==
=== RRD Tool===
* Elle est la première base de données de séries chronologiques.
* Il est difficile de l'exploiter au quotidien (sauvegarde, export, scalabilité).
* La précision des données se fait au détriment de la taille de la base.

=== ===
Les bases de données suivantes ont toutes ces points communs :
* Une architecture industrielle et scalable.
* Une API permettant le stockage et requetage des données.
* Des fonctions mathématiques intégrées.

=== Whisper ===
* Elle est vue comme la transition entre RRD Tool et les TSDB suivantes.
* Elle est difficilement utilisable sans le projet Graphite.

=== KairosDB ===
* Elle est très similaire à OpenTSDB si ce n'est qu'elle peut s'utiliser avec H2 ou Cassandra en plus d'HBase.

=== InfluxDB ===
* Elle est capable de stocker des événements en plus des points.
* Elle est basée sur LevelDB, la librairie clé / valeur écrite pour être rapide par Google.

== Fonctionnement ==
Les caractéristiques principales d'OpenTSDB sont les suivantes :
* Une architecture scalable.
* Une API pour la lecture et l'écriture des données.
* Des opérations statistiques intégrées.
* Une capacité de stockage à la milliseconde.
* Le stockage d'un milliard de points par jour.

[[Image:NOUGUIER-tsdb-architecture.png|400px|left center|Architecture]]

La lecture et l'écriture des données se fait via les Time Series Daemon. En effet chaque serveur est lié à un TSD et lui communique ses données. Ensuite, le TSD dans un délais d'une seconde maximum, va enregistrer ces informations dans HBase. Des routines internes au TSD peuvent être déclenchées lors du passage des données. Pour permettre la visualisation du contenu de HBase le TSD peut récupérer les données et les envoyer aux utilisateurs via une page internet.

=== Evolutivité ===
* Un TSD par cluster HBase, un cluster HBase par datacenter.
* Capacité d'écriture : 2000 points (minimum) par secondes et par coeur.
* Capacité de lecture : moins de 2 secondes.

=== Fiabilité ===
* Echec : sauvegarde dans un buffer si HBase ne fonctionne plus.
* Persistance des données : les données restent 1 seconde maximum dans le buffer d'un TSD avant d'être enregistrées dans HBase.

= Démonstration =
* La démonstration consiste à lancer une image docker localement contenant OpenTSDB et HBase préconfigués.
sudo docker pull petergrace/opentsdb-docker
sudo docker start --attach container_id

* Ensuite il faut se connecter à OpenTSDB localement via le protocole telnet (ou via http si ce n'est pas du locale).
telnet localhost 4242

* Parallèlement j'ai créé un script bash générant des sorties simulant les connexions, les achats et les ventes d'un site de commerce sur une journée.
# Nombre de connexions par heure
heure=0
valeur=( "1000" "900" "700" "400" "100" "40" "150" "500" "1600" "3700" "600" "4500" "9800" "10000" "9900" "4800" "3100" "2600" "1500" "2500" "2900" "3300" "3100" "2000" )
timestamp=1477954800

while [ "$heure" != 24 ]
do
echo "put connexions $timestamp ${valeur[$heure]} particulier=1"
timestamp=$(( $timestamp + 3600 ))
heure=$(( $heure + 1 ))
done

# Nombre d'achats par heure
heure=0
valeur=( "100" "60" "10" "0" "0" "0" "0" "20" "100" "1000" "300" "1700" "4000" "5300" "4300" "2000" "600" "300" "70" "200" "300" "500" "400" "100" )
timestamp=1477954800

while [ "$heure" != 24 ]
do
echo "put achats $timestamp ${valeur[$heure]} particulier=1"
timestamp=$(( $timestamp + 3600 ))
heure=$(( $heure + 1 ))
done

# Nombre de ventes par heure
heure=0
valeur=( "150" "20" "0" "0" "0" "0" "20" "40" "200" "500" "200" "1000" "2000" "3000" "5800" "4500" "2000" "200" "100" "400" "1000" "700" "100" "150" )
timestamp=1477954800

while [ "$heure" != 24 ]
do
echo "put ventes $timestamp ${valeur[$heure]} particulier=1"
timestamp=$(( $timestamp + 3600 ))
heure=$(( $heure + 1 ))
done

* Ensuite il faut rediriger la sortie du script vers la commande telnet que j'ai lancé avant, ce qui aura pour effet d'ajouter toutes les valeurs dans la base de données.

[[Image:NOUGUIER DEMO OpenTSDB.png|1200px|left center|Demo]]

* Voici donc le résultat dans OpenTSDB. Grâce au graphique différentes analyses et interprétations peuvent être faites :
** Les connexions / achats / ventes en fonctions de l'heure.
** Les achats / ventes en fonctions des connexions.

= Webographie =
* http://opentsdb.net/
* https://wooster.checkmy.ws/2013/12/time-series-databases/
* https://en.wikipedia.org/wiki/Time_series_database

VT2016 OpenTSDB

2016-11-01T13:00:26Z

Thibaut.Nouguier: /* Bibliographie */

= Présentation =

* Sujet : OpenTSDB
* Auteur : Thibaut NOUGUIER
* Enseignants : Didier DONSEZ, Georges-Pierre BONNEAU

= Mot clés =
Base de données de séries chronologique, Time Series Daemon, HBase.

= Résumé =
OpenTSDB est une base de données de séries chronologique. Chaque serveur communique ses informations à son Time Series Daemon (TSD) qui par la suite les enregistre dans HBase. Les TSDs sont aussi capables de récupérer les données stockées pour permettrent leur visualisation par un utilisateur. Il est aussi possible de mettre en place des routines (alertes, messages, ...), dans le but d'informer l'utilisateur lorsque cela est nécessaire.

= Abstract =
OpenTSDB is a time series database. Each server sends his data to his own Time Series Daemon (TSD), and then it store it into HBase. TSDs are able to get stored data in order to show it to an user. It is also possible to create routines (alerts, messages, ...) in order to inform users of anything.

= Synthèse =
== Contexte ==
De nos jours, le stockage en continue d'importante quantité de données est habituel, cependant il est difficile de le faire via des bases de données relationnelles classiques.

=== Objectifs ===
Les bases de données de séries chronologiques ont principalement deux objectifs :
* Le stockage de données horodatées de source et de nature diverses (températures, humidité, ...).
* La visualisation de celles-ci sous forme de graphique.

=== Problèmatique ===
* Stockage de point : nom + timestamp + valeur + tags.
* Stockage de masse de l'odre de la dizaine de millions par an.
* Fonctionnalités mathématiques telles que : comptages, moyennes, interpolations, lissages, maximums, minimums...

== Historique ==
=== RRD Tool===
* Elle est la première base de données de séries chronologiques.
* Il est difficile de l'exploiter au quotidien (sauvegarde, export, scalabilité).
* La précision des données se fait au détriment de la taille de la base.

== ==
Les bases de données suivantes ont toutes ces points communs :
* Une architecture industrielle et scalable.
* Une API permettant le stockage et requetage des données.
* Des fonctions mathématiques intégrées.

=== Whisper ===
* Elle est vue comme la transition entre RRD Tool et les TSDB suivantes.
* Elle est difficilement utilisable sans le projet Graphite.

=== KairosDB ===
* Elle est très similaire à OpenTSDB si ce n'est qu'elle peut s'utiliser avec H2 ou Cassandra en plus d'HBase.

=== InfluxDB ===
* Elle est capable de stocker des événements en plus des points.
* Elle est basée sur LevelDB, la librairie clé / valeur écrite pour être rapide par Google.

== Fonctionnement ==
Les caractéristiques principales d'OpenTSDB sont les suivantes :
* Une architecture scalable.
* Une API pour la lecture et l'écriture des données.
* Des opérations statistiques intégrées.
* Une capacité de stockage à la milliseconde.
* Le stockage d'un milliard de points par jour.

[[Image:NOUGUIER-tsdb-architecture.png|400px|left center|Architecture]]

La lecture et l'écriture des données se fait via les Time Series Daemon. En effet chaque serveur est lié à un TSD et lui communique ses données. Ensuite, le TSD dans un délais d'une seconde maximum, va enregistrer ces informations dans HBase. Des routines internes au TSD peuvent être déclenchées lors du passage des données. Pour permettre la visualisation du contenu de HBase le TSD peut récupérer les données et les envoyer aux utilisateurs via une page internet.

=== Evolutivité ===
* Un TSD par cluster HBase, un cluster HBase par datacenter.
* Capacité d'écriture : 2000 points (minimum) par secondes et par coeur.
* Capacité de lecture : moins de 2 secondes.

=== Fiabilité ===
* Echec : sauvegarde dans un buffer si HBase ne fonctionne plus.
* Persistance des données : les données restent 1 seconde maximum dans le buffer d'un TSD avant d'être enregistrées dans HBase.

= Démonstration =
* La démonstration consiste à lancer une image docker localement contenant OpenTSDB et HBase préconfigués.
sudo docker pull petergrace/opentsdb-docker
sudo docker start --attach container_id

* Ensuite il faut se connecter à OpenTSDB localement via le protocole telnet (ou via http si ce n'est pas du locale).
telnet localhost 4242

* Parallèlement j'ai créé un script bash générant des sorties simulant les connexions, les achats et les ventes d'un site de commerce sur une journée.
# Nombre de connexions par heure
heure=0
valeur=( "1000" "900" "700" "400" "100" "40" "150" "500" "1600" "3700" "600" "4500" "9800" "10000" "9900" "4800" "3100" "2600" "1500" "2500" "2900" "3300" "3100" "2000" )
timestamp=1477954800

while [ "$heure" != 24 ]
do
echo "put connexions $timestamp ${valeur[$heure]} particulier=1"
timestamp=$(( $timestamp + 3600 ))
heure=$(( $heure + 1 ))
done

# Nombre d'achats par heure
heure=0
valeur=( "100" "60" "10" "0" "0" "0" "0" "20" "100" "1000" "300" "1700" "4000" "5300" "4300" "2000" "600" "300" "70" "200" "300" "500" "400" "100" )
timestamp=1477954800

while [ "$heure" != 24 ]
do
echo "put achats $timestamp ${valeur[$heure]} particulier=1"
timestamp=$(( $timestamp + 3600 ))
heure=$(( $heure + 1 ))
done

# Nombre de ventes par heure
heure=0
valeur=( "150" "20" "0" "0" "0" "0" "20" "40" "200" "500" "200" "1000" "2000" "3000" "5800" "4500" "2000" "200" "100" "400" "1000" "700" "100" "150" )
timestamp=1477954800

while [ "$heure" != 24 ]
do
echo "put ventes $timestamp ${valeur[$heure]} particulier=1"
timestamp=$(( $timestamp + 3600 ))
heure=$(( $heure + 1 ))
done

* Ensuite il faut rediriger la sortie du script vers la commande telnet que j'ai lancé avant, ce qui aura pour effet d'ajouter toutes les valeurs dans la base de données.

[[Image:NOUGUIER DEMO OpenTSDB.png|1200px|left center|Demo]]

* Voici donc le résultat dans OpenTSDB. Grâce au graphique différentes analyses et interprétations peuvent être faites :
** Les connexions / achats / ventes en fonctions de l'heure.
** Les achats / ventes en fonctions des connexions.

= Webographie =
* http://opentsdb.net/
* https://wooster.checkmy.ws/2013/12/time-series-databases/
* https://en.wikipedia.org/wiki/Time_series_database

VT2016 OpenTSDB

2016-11-01T12:59:30Z

Thibaut.Nouguier: /* Démonstration */

= Présentation =

* Sujet : OpenTSDB
* Auteur : Thibaut NOUGUIER
* Enseignants : Didier DONSEZ, Georges-Pierre BONNEAU

= Mot clés =
Base de données de séries chronologique, Time Series Daemon, HBase.

= Résumé =
OpenTSDB est une base de données de séries chronologique. Chaque serveur communique ses informations à son Time Series Daemon (TSD) qui par la suite les enregistre dans HBase. Les TSDs sont aussi capables de récupérer les données stockées pour permettrent leur visualisation par un utilisateur. Il est aussi possible de mettre en place des routines (alertes, messages, ...), dans le but d'informer l'utilisateur lorsque cela est nécessaire.

= Abstract =
OpenTSDB is a time series database. Each server sends his data to his own Time Series Daemon (TSD), and then it store it into HBase. TSDs are able to get stored data in order to show it to an user. It is also possible to create routines (alerts, messages, ...) in order to inform users of anything.

= Synthèse =
== Contexte ==
De nos jours, le stockage en continue d'importante quantité de données est habituel, cependant il est difficile de le faire via des bases de données relationnelles classiques.

=== Objectifs ===
Les bases de données de séries chronologiques ont principalement deux objectifs :
* Le stockage de données horodatées de source et de nature diverses (températures, humidité, ...).
* La visualisation de celles-ci sous forme de graphique.

=== Problèmatique ===
* Stockage de point : nom + timestamp + valeur + tags.
* Stockage de masse de l'odre de la dizaine de millions par an.
* Fonctionnalités mathématiques telles que : comptages, moyennes, interpolations, lissages, maximums, minimums...

== Historique ==
=== RRD Tool===
* Elle est la première base de données de séries chronologiques.
* Il est difficile de l'exploiter au quotidien (sauvegarde, export, scalabilité).
* La précision des données se fait au détriment de la taille de la base.

== ==
Les bases de données suivantes ont toutes ces points communs :
* Une architecture industrielle et scalable.
* Une API permettant le stockage et requetage des données.
* Des fonctions mathématiques intégrées.

=== Whisper ===
* Elle est vue comme la transition entre RRD Tool et les TSDB suivantes.
* Elle est difficilement utilisable sans le projet Graphite.

=== KairosDB ===
* Elle est très similaire à OpenTSDB si ce n'est qu'elle peut s'utiliser avec H2 ou Cassandra en plus d'HBase.

=== InfluxDB ===
* Elle est capable de stocker des événements en plus des points.
* Elle est basée sur LevelDB, la librairie clé / valeur écrite pour être rapide par Google.

== Fonctionnement ==
Les caractéristiques principales d'OpenTSDB sont les suivantes :
* Une architecture scalable.
* Une API pour la lecture et l'écriture des données.
* Des opérations statistiques intégrées.
* Une capacité de stockage à la milliseconde.
* Le stockage d'un milliard de points par jour.

[[Image:NOUGUIER-tsdb-architecture.png|400px|left center|Architecture]]

La lecture et l'écriture des données se fait via les Time Series Daemon. En effet chaque serveur est lié à un TSD et lui communique ses données. Ensuite, le TSD dans un délais d'une seconde maximum, va enregistrer ces informations dans HBase. Des routines internes au TSD peuvent être déclenchées lors du passage des données. Pour permettre la visualisation du contenu de HBase le TSD peut récupérer les données et les envoyer aux utilisateurs via une page internet.

=== Evolutivité ===
* Un TSD par cluster HBase, un cluster HBase par datacenter.
* Capacité d'écriture : 2000 points (minimum) par secondes et par coeur.
* Capacité de lecture : moins de 2 secondes.

=== Fiabilité ===
* Echec : sauvegarde dans un buffer si HBase ne fonctionne plus.
* Persistance des données : les données restent 1 seconde maximum dans le buffer d'un TSD avant d'être enregistrées dans HBase.

= Démonstration =
* La démonstration consiste à lancer une image docker localement contenant OpenTSDB et HBase préconfigués.
sudo docker pull petergrace/opentsdb-docker
sudo docker start --attach container_id

* Ensuite il faut se connecter à OpenTSDB localement via le protocole telnet (ou via http si ce n'est pas du locale).
telnet localhost 4242

* Parallèlement j'ai créé un script bash générant des sorties simulant les connexions, les achats et les ventes d'un site de commerce sur une journée.
# Nombre de connexions par heure
heure=0
valeur=( "1000" "900" "700" "400" "100" "40" "150" "500" "1600" "3700" "600" "4500" "9800" "10000" "9900" "4800" "3100" "2600" "1500" "2500" "2900" "3300" "3100" "2000" )
timestamp=1477954800

while [ "$heure" != 24 ]
do
echo "put connexions $timestamp ${valeur[$heure]} particulier=1"
timestamp=$(( $timestamp + 3600 ))
heure=$(( $heure + 1 ))
done

# Nombre d'achats par heure
heure=0
valeur=( "100" "60" "10" "0" "0" "0" "0" "20" "100" "1000" "300" "1700" "4000" "5300" "4300" "2000" "600" "300" "70" "200" "300" "500" "400" "100" )
timestamp=1477954800

while [ "$heure" != 24 ]
do
echo "put achats $timestamp ${valeur[$heure]} particulier=1"
timestamp=$(( $timestamp + 3600 ))
heure=$(( $heure + 1 ))
done

# Nombre de ventes par heure
heure=0
valeur=( "150" "20" "0" "0" "0" "0" "20" "40" "200" "500" "200" "1000" "2000" "3000" "5800" "4500" "2000" "200" "100" "400" "1000" "700" "100" "150" )
timestamp=1477954800

while [ "$heure" != 24 ]
do
echo "put ventes $timestamp ${valeur[$heure]} particulier=1"
timestamp=$(( $timestamp + 3600 ))
heure=$(( $heure + 1 ))
done

* Ensuite il faut rediriger la sortie du script vers la commande telnet que j'ai lancé avant, ce qui aura pour effet d'ajouter toutes les valeurs dans la base de données.

[[Image:NOUGUIER DEMO OpenTSDB.png|1200px|left center|Demo]]

* Voici donc le résultat dans OpenTSDB. Grâce au graphique différentes analyses et interprétations peuvent être faites :
** Les connexions / achats / ventes en fonctions de l'heure.
** Les achats / ventes en fonctions des connexions.

= Bibliographie =
* http://opentsdb.net/
* https://wooster.checkmy.ws/2013/12/time-series-databases/
* https://en.wikipedia.org/wiki/Time_series_database

VT2016 OpenTSDB

2016-11-01T12:56:46Z

Thibaut.Nouguier: /* Démonstration */

= Présentation =

* Sujet : OpenTSDB
* Auteur : Thibaut NOUGUIER
* Enseignants : Didier DONSEZ, Georges-Pierre BONNEAU

= Mot clés =
Base de données de séries chronologique, Time Series Daemon, HBase.

= Résumé =
OpenTSDB est une base de données de séries chronologique. Chaque serveur communique ses informations à son Time Series Daemon (TSD) qui par la suite les enregistre dans HBase. Les TSDs sont aussi capables de récupérer les données stockées pour permettrent leur visualisation par un utilisateur. Il est aussi possible de mettre en place des routines (alertes, messages, ...), dans le but d'informer l'utilisateur lorsque cela est nécessaire.

= Abstract =
OpenTSDB is a time series database. Each server sends his data to his own Time Series Daemon (TSD), and then it store it into HBase. TSDs are able to get stored data in order to show it to an user. It is also possible to create routines (alerts, messages, ...) in order to inform users of anything.

= Synthèse =
== Contexte ==
De nos jours, le stockage en continue d'importante quantité de données est habituel, cependant il est difficile de le faire via des bases de données relationnelles classiques.

=== Objectifs ===
Les bases de données de séries chronologiques ont principalement deux objectifs :
* Le stockage de données horodatées de source et de nature diverses (températures, humidité, ...).
* La visualisation de celles-ci sous forme de graphique.

=== Problèmatique ===
* Stockage de point : nom + timestamp + valeur + tags.
* Stockage de masse de l'odre de la dizaine de millions par an.
* Fonctionnalités mathématiques telles que : comptages, moyennes, interpolations, lissages, maximums, minimums...

== Historique ==
=== RRD Tool===
* Elle est la première base de données de séries chronologiques.
* Il est difficile de l'exploiter au quotidien (sauvegarde, export, scalabilité).
* La précision des données se fait au détriment de la taille de la base.

== ==
Les bases de données suivantes ont toutes ces points communs :
* Une architecture industrielle et scalable.
* Une API permettant le stockage et requetage des données.
* Des fonctions mathématiques intégrées.

=== Whisper ===
* Elle est vue comme la transition entre RRD Tool et les TSDB suivantes.
* Elle est difficilement utilisable sans le projet Graphite.

=== KairosDB ===
* Elle est très similaire à OpenTSDB si ce n'est qu'elle peut s'utiliser avec H2 ou Cassandra en plus d'HBase.

=== InfluxDB ===
* Elle est capable de stocker des événements en plus des points.
* Elle est basée sur LevelDB, la librairie clé / valeur écrite pour être rapide par Google.

== Fonctionnement ==
Les caractéristiques principales d'OpenTSDB sont les suivantes :
* Une architecture scalable.
* Une API pour la lecture et l'écriture des données.
* Des opérations statistiques intégrées.
* Une capacité de stockage à la milliseconde.
* Le stockage d'un milliard de points par jour.

[[Image:NOUGUIER-tsdb-architecture.png|400px|left center|Architecture]]

La lecture et l'écriture des données se fait via les Time Series Daemon. En effet chaque serveur est lié à un TSD et lui communique ses données. Ensuite, le TSD dans un délais d'une seconde maximum, va enregistrer ces informations dans HBase. Des routines internes au TSD peuvent être déclenchées lors du passage des données. Pour permettre la visualisation du contenu de HBase le TSD peut récupérer les données et les envoyer aux utilisateurs via une page internet.

=== Evolutivité ===
* Un TSD par cluster HBase, un cluster HBase par datacenter.
* Capacité d'écriture : 2000 points (minimum) par secondes et par coeur.
* Capacité de lecture : moins de 2 secondes.

=== Fiabilité ===
* Echec : sauvegarde dans un buffer si HBase ne fonctionne plus.
* Persistance des données : les données restent 1 seconde maximum dans le buffer d'un TSD avant d'être enregistrées dans HBase.

= Démonstration =
* La démonstration consiste à lancer une image docker localement contenant OpenTSDB et HBase préconfigués.
sudo docker pull petergrace/opentsdb-docker
sudo docker start --attach container_id

* Ensuite il faut se connecter à OpenTSDB localement via le protocole telnet (ou via http si ce n'est pas du locale).
telnet localhost 4242

* Parallèlement j'ai créé un script bash générant des sorties simulant les connexions, les achats et les ventes d'un site de commerce sur une journée.
# Nombre de connexions par heure
heure=0
valeur=( "1000" "900" "700" "400" "100" "40" "150" "500" "1600" "3700" "600" "4500" "9800" "10000" "9900" "4800" "3100" "2600" "1500" "2500" "2900" "3300" "3100" "2000" )
timestamp=1477954800

while [ "$heure" != 24 ]
do
echo "put connexions $timestamp ${valeur[$heure]} particulier=1"
timestamp=$(( $timestamp + 3600 ))
heure=$(( $heure + 1 ))
done

# Nombre d'achats par heure
heure=0
valeur=( "100" "60" "10" "0" "0" "0" "0" "20" "100" "1000" "300" "1700" "4000" "5300" "4300" "2000" "600" "300" "70" "200" "300" "500" "400" "100" )
timestamp=1477954800

while [ "$heure" != 24 ]
do
echo "put achats $timestamp ${valeur[$heure]} particulier=1"
timestamp=$(( $timestamp + 3600 ))
heure=$(( $heure + 1 ))
done

# Nombre de ventes par heure
heure=0
valeur=( "150" "20" "0" "0" "0" "0" "20" "40" "200" "500" "200" "1000" "2000" "3000" "5800" "4500" "2000" "200" "100" "400" "1000" "700" "100" "150" )
timestamp=1477954800

while [ "$heure" != 24 ]
do
echo "put ventes $timestamp ${valeur[$heure]} particulier=1"
timestamp=$(( $timestamp + 3600 ))
heure=$(( $heure + 1 ))
done

* Ensuite il faut rediriger la sortie du script vers la commande telnet que j'ai lancé avant, ce qui aura pour effet d'ajouter toutes les valeurs dans la base de données.

[[Image:NOUGUIER DEMO OpenTSDB.png|1200px|left center|Demo]]

* Voici donc le résultat dans OpenTSDB. Grâce au graphique différentes analyses et interprétations peuvent être faites.

= Bibliographie =
* http://opentsdb.net/
* https://wooster.checkmy.ws/2013/12/time-series-databases/
* https://en.wikipedia.org/wiki/Time_series_database

VT2016 OpenTSDB

2016-11-01T12:55:23Z

Thibaut.Nouguier: /* Fonctionnement */

= Présentation =

* Sujet : OpenTSDB
* Auteur : Thibaut NOUGUIER
* Enseignants : Didier DONSEZ, Georges-Pierre BONNEAU

= Mot clés =
Base de données de séries chronologique, Time Series Daemon, HBase.

= Résumé =
OpenTSDB est une base de données de séries chronologique. Chaque serveur communique ses informations à son Time Series Daemon (TSD) qui par la suite les enregistre dans HBase. Les TSDs sont aussi capables de récupérer les données stockées pour permettrent leur visualisation par un utilisateur. Il est aussi possible de mettre en place des routines (alertes, messages, ...), dans le but d'informer l'utilisateur lorsque cela est nécessaire.

= Abstract =
OpenTSDB is a time series database. Each server sends his data to his own Time Series Daemon (TSD), and then it store it into HBase. TSDs are able to get stored data in order to show it to an user. It is also possible to create routines (alerts, messages, ...) in order to inform users of anything.

= Synthèse =
== Contexte ==
De nos jours, le stockage en continue d'importante quantité de données est habituel, cependant il est difficile de le faire via des bases de données relationnelles classiques.

=== Objectifs ===
Les bases de données de séries chronologiques ont principalement deux objectifs :
* Le stockage de données horodatées de source et de nature diverses (températures, humidité, ...).
* La visualisation de celles-ci sous forme de graphique.

=== Problèmatique ===
* Stockage de point : nom + timestamp + valeur + tags.
* Stockage de masse de l'odre de la dizaine de millions par an.
* Fonctionnalités mathématiques telles que : comptages, moyennes, interpolations, lissages, maximums, minimums...

== Historique ==
=== RRD Tool===
* Elle est la première base de données de séries chronologiques.
* Il est difficile de l'exploiter au quotidien (sauvegarde, export, scalabilité).
* La précision des données se fait au détriment de la taille de la base.

== ==
Les bases de données suivantes ont toutes ces points communs :
* Une architecture industrielle et scalable.
* Une API permettant le stockage et requetage des données.
* Des fonctions mathématiques intégrées.

=== Whisper ===
* Elle est vue comme la transition entre RRD Tool et les TSDB suivantes.
* Elle est difficilement utilisable sans le projet Graphite.

=== KairosDB ===
* Elle est très similaire à OpenTSDB si ce n'est qu'elle peut s'utiliser avec H2 ou Cassandra en plus d'HBase.

=== InfluxDB ===
* Elle est capable de stocker des événements en plus des points.
* Elle est basée sur LevelDB, la librairie clé / valeur écrite pour être rapide par Google.

== Fonctionnement ==
Les caractéristiques principales d'OpenTSDB sont les suivantes :
* Une architecture scalable.
* Une API pour la lecture et l'écriture des données.
* Des opérations statistiques intégrées.
* Une capacité de stockage à la milliseconde.
* Le stockage d'un milliard de points par jour.

[[Image:NOUGUIER-tsdb-architecture.png|400px|left center|Architecture]]

La lecture et l'écriture des données se fait via les Time Series Daemon. En effet chaque serveur est lié à un TSD et lui communique ses données. Ensuite, le TSD dans un délais d'une seconde maximum, va enregistrer ces informations dans HBase. Des routines internes au TSD peuvent être déclenchées lors du passage des données. Pour permettre la visualisation du contenu de HBase le TSD peut récupérer les données et les envoyer aux utilisateurs via une page internet.

=== Evolutivité ===
* Un TSD par cluster HBase, un cluster HBase par datacenter.
* Capacité d'écriture : 2000 points (minimum) par secondes et par coeur.
* Capacité de lecture : moins de 2 secondes.

=== Fiabilité ===
* Echec : sauvegarde dans un buffer si HBase ne fonctionne plus.
* Persistance des données : les données restent 1 seconde maximum dans le buffer d'un TSD avant d'être enregistrées dans HBase.

= Démonstration =
* La démonstration consiste à lancer une image docker localement contenant OpenTSDB et HBase préconfigués.
sudo docker pull petergrace/opentsdb-docker
sudo docker start --attach container_id

* Ensuite il faut se connecter à OpenTSDB localement via le protocole telnet (ou via http si ce n'est pas du locale).
telnet localhost 4242

* Parallèlement j'ai créé un script générant des sorties simulant les connexions, les achats et les ventes d'un site de commerce sur une journée.
# Nombre de connexions par heure
heure=0
valeur=( "1000" "900" "700" "400" "100" "40" "150" "500" "1600" "3700" "600" "4500" "9800" "10000" "9900" "4800" "3100" "2600" "1500" "2500" "2900" "3300" "3100" "2000" )
timestamp=1477954800

while [ "$heure" != 24 ]
do
echo "put connexions $timestamp ${valeur[$heure]} particulier=1"
timestamp=$(( $timestamp + 3600 ))
heure=$(( $heure + 1 ))
done

# Nombre d'achats par heure
heure=0
valeur=( "100" "60" "10" "0" "0" "0" "0" "20" "100" "1000" "300" "1700" "4000" "5300" "4300" "2000" "600" "300" "70" "200" "300" "500" "400" "100" )
timestamp=1477954800

while [ "$heure" != 24 ]
do
echo "put achats $timestamp ${valeur[$heure]} particulier=1"
timestamp=$(( $timestamp + 3600 ))
heure=$(( $heure + 1 ))
done

# Nombre de ventes par heure
heure=0
valeur=( "150" "20" "0" "0" "0" "0" "20" "40" "200" "500" "200" "1000" "2000" "3000" "5800" "4500" "2000" "200" "100" "400" "1000" "700" "100" "150" )
timestamp=1477954800

while [ "$heure" != 24 ]
do
echo "put ventes $timestamp ${valeur[$heure]} particulier=1"
timestamp=$(( $timestamp + 3600 ))
heure=$(( $heure + 1 ))
done

* Ensuite il faut rediriger la sortie du script vers la commande telnet que j'ai lancé avant, ce qui aura pour effet d'ajouter toutes les valeurs dans la base de données.

[[Image:NOUGUIER DEMO OpenTSDB.png|1200px|left center|Demo]]

*

= Bibliographie =
* http://opentsdb.net/
* https://wooster.checkmy.ws/2013/12/time-series-databases/
* https://en.wikipedia.org/wiki/Time_series_database

VT2016 OpenTSDB

2016-11-01T12:55:10Z

Thibaut.Nouguier: /* Démonstration */

= Présentation =

* Sujet : OpenTSDB
* Auteur : Thibaut NOUGUIER
* Enseignants : Didier DONSEZ, Georges-Pierre BONNEAU

= Mot clés =
Base de données de séries chronologique, Time Series Daemon, HBase.

= Résumé =
OpenTSDB est une base de données de séries chronologique. Chaque serveur communique ses informations à son Time Series Daemon (TSD) qui par la suite les enregistre dans HBase. Les TSDs sont aussi capables de récupérer les données stockées pour permettrent leur visualisation par un utilisateur. Il est aussi possible de mettre en place des routines (alertes, messages, ...), dans le but d'informer l'utilisateur lorsque cela est nécessaire.

= Abstract =
OpenTSDB is a time series database. Each server sends his data to his own Time Series Daemon (TSD), and then it store it into HBase. TSDs are able to get stored data in order to show it to an user. It is also possible to create routines (alerts, messages, ...) in order to inform users of anything.

= Synthèse =
== Contexte ==
De nos jours, le stockage en continue d'importante quantité de données est habituel, cependant il est difficile de le faire via des bases de données relationnelles classiques.

=== Objectifs ===
Les bases de données de séries chronologiques ont principalement deux objectifs :
* Le stockage de données horodatées de source et de nature diverses (températures, humidité, ...).
* La visualisation de celles-ci sous forme de graphique.

=== Problèmatique ===
* Stockage de point : nom + timestamp + valeur + tags.
* Stockage de masse de l'odre de la dizaine de millions par an.
* Fonctionnalités mathématiques telles que : comptages, moyennes, interpolations, lissages, maximums, minimums...

== Historique ==
=== RRD Tool===
* Elle est la première base de données de séries chronologiques.
* Il est difficile de l'exploiter au quotidien (sauvegarde, export, scalabilité).
* La précision des données se fait au détriment de la taille de la base.

== ==
Les bases de données suivantes ont toutes ces points communs :
* Une architecture industrielle et scalable.
* Une API permettant le stockage et requetage des données.
* Des fonctions mathématiques intégrées.

=== Whisper ===
* Elle est vue comme la transition entre RRD Tool et les TSDB suivantes.
* Elle est difficilement utilisable sans le projet Graphite.

=== KairosDB ===
* Elle est très similaire à OpenTSDB si ce n'est qu'elle peut s'utiliser avec H2 ou Cassandra en plus d'HBase.

=== InfluxDB ===
* Elle est capable de stocker des événements en plus des points.
* Elle est basée sur LevelDB, la librairie clé / valeur écrite pour être rapide par Google.

== Fonctionnement ==
Les caractéristiques principales d'OpenTSDB sont les suivantes :
* Une architecture scalable.
* Une API pour la lecture et l'écriture des données.
* Des opérations statistiques intégrées.
* Une capacité de stockage à la milliseconde.
* Le stockage d'un milliard de points par jour.

[[Image:NOUGUIER-tsdb-architecture.png|400px|left cetnter|Architecture]]

La lecture et l'écriture des données se fait via les Time Series Daemon. En effet chaque serveur est lié à un TSD et lui communique ses données. Ensuite, le TSD dans un délais d'une seconde maximum, va enregistrer ces informations dans HBase. Des routines internes au TSD peuvent être déclenchées lors du passage des données. Pour permettre la visualisation du contenu de HBase le TSD peut récupérer les données et les envoyer aux utilisateurs via une page internet.

=== Evolutivité ===
* Un TSD par cluster HBase, un cluster HBase par datacenter.
* Capacité d'écriture : 2000 points (minimum) par secondes et par coeur.
* Capacité de lecture : moins de 2 secondes.

=== Fiabilité ===
* Echec : sauvegarde dans un buffer si HBase ne fonctionne plus.
* Persistance des données : les données restent 1 seconde maximum dans le buffer d'un TSD avant d'être enregistrées dans HBase.

= Démonstration =
* La démonstration consiste à lancer une image docker localement contenant OpenTSDB et HBase préconfigués.
sudo docker pull petergrace/opentsdb-docker
sudo docker start --attach container_id

* Ensuite il faut se connecter à OpenTSDB localement via le protocole telnet (ou via http si ce n'est pas du locale).
telnet localhost 4242

* Parallèlement j'ai créé un script générant des sorties simulant les connexions, les achats et les ventes d'un site de commerce sur une journée.
# Nombre de connexions par heure
heure=0
valeur=( "1000" "900" "700" "400" "100" "40" "150" "500" "1600" "3700" "600" "4500" "9800" "10000" "9900" "4800" "3100" "2600" "1500" "2500" "2900" "3300" "3100" "2000" )
timestamp=1477954800

while [ "$heure" != 24 ]
do
echo "put connexions $timestamp ${valeur[$heure]} particulier=1"
timestamp=$(( $timestamp + 3600 ))
heure=$(( $heure + 1 ))
done

# Nombre d'achats par heure
heure=0
valeur=( "100" "60" "10" "0" "0" "0" "0" "20" "100" "1000" "300" "1700" "4000" "5300" "4300" "2000" "600" "300" "70" "200" "300" "500" "400" "100" )
timestamp=1477954800

while [ "$heure" != 24 ]
do
echo "put achats $timestamp ${valeur[$heure]} particulier=1"
timestamp=$(( $timestamp + 3600 ))
heure=$(( $heure + 1 ))
done

# Nombre de ventes par heure
heure=0
valeur=( "150" "20" "0" "0" "0" "0" "20" "40" "200" "500" "200" "1000" "2000" "3000" "5800" "4500" "2000" "200" "100" "400" "1000" "700" "100" "150" )
timestamp=1477954800

while [ "$heure" != 24 ]
do
echo "put ventes $timestamp ${valeur[$heure]} particulier=1"
timestamp=$(( $timestamp + 3600 ))
heure=$(( $heure + 1 ))
done

* Ensuite il faut rediriger la sortie du script vers la commande telnet que j'ai lancé avant, ce qui aura pour effet d'ajouter toutes les valeurs dans la base de données.

[[Image:NOUGUIER DEMO OpenTSDB.png|1200px|left center|Demo]]

*

= Bibliographie =
* http://opentsdb.net/
* https://wooster.checkmy.ws/2013/12/time-series-databases/
* https://en.wikipedia.org/wiki/Time_series_database

VT2016 OpenTSDB

2016-11-01T12:38:09Z

Thibaut.Nouguier: /* Démonstration */

VT2016 OpenTSDB

2016-11-01T12:37:21Z

Thibaut.Nouguier: /* Démonstration */

VT2016 OpenTSDB

2016-11-01T12:37:06Z

Thibaut.Nouguier:

File:NOUGUIER DEMO OpenTSDB.png

2016-11-01T12:36:31Z

Thibaut.Nouguier: