air - User contributions [en]

File:Presentation finale NixOs.pdf

2022-03-18T14:57:25Z

Titouan.Minier-Mancini: Titouan.Minier-Mancini uploaded a new version of File:Presentation finale NixOs.pdf

File:Presentation finale NixOs.pdf

2022-03-18T12:49:27Z

Titouan.Minier-Mancini: Titouan.Minier-Mancini uploaded a new version of File:Presentation finale NixOs.pdf

Test Infrastructures NixOS 2021-2022

2022-03-18T11:50:08Z

Titouan.Minier-Mancini:

==Démarrage==

https://github.com/TitouanCao/projet-info5-carnets/blob/master/equipe.md

==Carnet Titouan Minier Mancini==

https://github.com/TitouanCao/projet-info5-carnets/blob/master/titouan-minier-mancini.md

==Carnet Corentin Humbert==

https://github.com/TitouanCao/projet-info5-carnets/blob/master/corentin-humbert.md

==Carnet Corentin Sueur==

https://github.com/TitouanCao/projet-info5-carnets/blob/master/corentin-sueur.md

File:Presentation finale NixOs.pdf

2022-03-18T11:31:42Z

Titouan.Minier-Mancini: Titouan.Minier-Mancini uploaded a new version of File:Presentation finale NixOs.pdf

Projets 2021-2022

2022-03-18T10:53:48Z

Titouan.Minier-Mancini: /* Affectations S10 */

<<[[Projets 2020-2021]] | [[Projets]] | [[Projets 2022-2023]]>>
=INFO=
==INFO3==

==INFO4==
===Projet Semestre S8===

Enseignants responsables : Olivier Richard

* Dates : Lundi après-midi, Mardi après-midi
* Lancement: 10 Janvier 2021 après midi
* Soutenance à mi-parcours: A définir
* Soutenance: A définir

* '''Evaluation à mi-parcours le lundi/mardi ???''': Format: 10min (5min de présentation 3 slides au plus, 5min de discussion). Cette évaluation sera prise en compte dans la note finale.

'''Consignes générales:'''

* '''Vous devez être pro-actifs !!!''': Si des points sont pas ou mals spécifiés, vous le faîtes et vous justifiez vos choix. Pour les problèmes techniques éventuels vous pouvez: creuser la question, contacter l'auteur du code si il y a lieu, écrire un rapport de bug ('''Attention:''' ca se prépare !), soumettre un patch/pull request, contacter l'enseignant ou la personne référente du projet.

* '''Vous devez maintenir une fiche de suivi de projet''': elle doit être mise à jour chaque semaine, elle rassemble les élements essentiels du projet, elle indique les évolutions du projet et présente sa feuille de route. '''Note:''' le nom de la fiche doit être composé du nom du projet et suffixé par info4_2021_2022. '''Cette fiche compte pour la note finale'''

* '''Votre code''' pour doit être hébergé sur le gitlab et à l'URL suivante https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22 , vous utiliserez votre compte UGA.

* Chaque projet doit avoir '''aux moins 2 dépôts git''':
** '''Un pour les documents''' demandés rapport, présentation de pré-soutenante, de soutenance, flyer. '''Il sera appelé documents.'''
** Un ou plusieurs pour le code, les tests, les évaluations, les preuves de concept, la ou les documentations afférentes.

* Les '''documents public doivent être rédigés en anglais (README, documentation, commentaires de code, nom de variables et de fonctions)'''. Le *rapport* sera aussi demandé en *anglais* (il fera la taille d'un rapport de TP). Les transparents des présentation peuvent être en anglais ou en francais, la soutenance sera taire en francais.

* '''La note obtenue''' tiendra compte du '''nombre et de la qualité des commits''' observé dans '''vos dépots git et la branche master''' (or depot documents). La qualité comprend l'intitulé du commit et son contenu. Les notes pourront être différentiées dans un groupe, il n'est pas acceptable de pas avoir de commit dans le(s) dépôt(s) du projet (or dépôt documents).

* Il est fortement conseillé de suivre un '''développement incrémental''' qui permette d'avoir à tout moment un démonstrateur à présenter, un projet peut être constituer d'une succession de '''démonstrateurs présentables séparément'''.

* Vous devez faire aussi des '''schémas d'architectures générales et/ou spéficiques, des diagrammes de séquence''', et autre documents de spécification si nécessaire. Ces documents vous serviront de base de discussion/brainstorming interne ainsi que dans vos différents documents (rapport, présentations, documentation). Ces schémas sont avant tout conceptuels et techniques.

===Propositions de projets S8===

* 1. [https://codimd.math.cnrs.fr/?next=%2Fs%2FB029qfT5Q Courriels à Suppression Programmée] : Michaël Périn
* 2. [[Firmwares open source pour une station de réception de satellites pour l’Internet des Objets isolés]], Didier DONSEZ.
* 3. [[Evaluation du toolkit AI de STM32 pour l'analyse de l'environnement sonore]] (Suite 2022), Didier DONSEZ.
* 4. [[Algorithmes de géolocalisation d’objets par TDOA (Time Difference of Arrival)]] (suite), Didier DONSEZ.
* 5. [[Dashboard pour Overwatch]] Olivier Richard
* 6. [[Application mobile d'enregistrements de noeuds IoT LoRaWAN dans plusieurs réseaux]] (Suite) : Didier DONSEZ
* 7. [[Bluetooth 5.1 Angle of Arrival based Indoor Localization]] (Suite) : Didier DONSEZ
* 8. Intégration de composants de mesures environnementales (eau, air, ...) pour le [[Contribution au projet STM32Python|projet STM32Python]] à destination des lycéens: Didier DONSEZ
* 9. [[Air Quality Station]] (Suite) : Didier DONSEZ
* 10. [[Floating Water Quality Station]] : Didier DONSEZ, Nicolas PALIX
* 12. [[Testeur de terrain pour réseaux LoRaWAN privés et publics (TTN, CampusIoT et Helium)]] (suite 2021), Didier DONSEZ.
* 13. [[Géolocalition Indoor en LoRa 2.4GHz]], Didier DONSEZ.
* 14. [[RealWorld avec Dioxus]] (Rust + web), Olivier Richard
* 15. Poursuite projet 20-21 [[Rust Engine | Executeur de tâche en Rust]], Olivier Richard
* 16. Poursuite projet 20-21 [[Retrocompute simulateur | RetroComputing]]: (vintage style) Coupler le simulateur Digital avec un simulateur de processeur 8bits, Olivier Richard
* 17. Poursuite projet 19-20 [[Portail pour gestionnaire de taches]](react, Typescript), Olivier Richard
* 18. [[Paquets NIX pour Polytech]], Olivier Richard
* 19. [[Mini compilateur C pour mini CPU]], Olivier Richard
* 20. Mode jeu en réseau (Wifi/Bluetooth) pour [[TanksOfFreedom]], Nicolas Palix

Non affecté
* xx. [[Bibliothèque de décodeurs standards et d'afficheurs Grafana pour objets connectés LoRaWAN]] : Didier DONSEZ
* xx. [[ASAC|Agriculture connectée]] en partenariat avec les projets collectifs IESE/MAT : Nicolas Palix
* xx. [[Faults In Linux]], Nicolas Palix

===Affectations===
{|class="wikitable alternance"
|+ Affectation des projets INFO4 21-22
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Enseignant(s)
!scope="col"| Fiche de suivi
!scope="col"| Documents
|-
!scope="row"| 1
| [https://air.imag.fr/index.php/Planned_Deletion_Emails Courriels à Suppression Programmée]
| CANIN CORENTIN,MONTEILLER JOSHUA,WAGNER SAMY
| Michaël PÉRIN
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/01/docs/-/blob/main/%20Courriels%20%C3%A0%20Suppression%20Programm%C3%A9e%20info4_2021_2022.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 2
| [https://air.imag.fr/index.php/Firmwares_open_source_pour_une_station_de_r%C3%A9ception_de_satellites_pour_l%E2%80%99Internet_des_Objets_isol%C3%A9s# Firmwares open source pour une station de réception de satellites pour l’Internet des Objets isolés]
| CARMONA DAMIAN,DA COSTA TOM,WOZNY PIERRE-RAPHAEL
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/02/docs/-/blob/main/Firmwares_open_source_pour_une_station_de_r%C3%A9ception_de_satellites_pour_l_Internet_des_Objets_isol%C3%A9s_info4_2021_2022.md# Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 3
| [https://air.imag.fr/index.php/Evaluation_du_toolkit_AI_de_STM32_pour_l%27analyse_de_l%27environnement_sonore Evaluation du toolkit AI de STM32 pour l'analyse de l'environnement sonore]
| BACH THOMAS,BARBE FLORENT,SIMO YOKAM GEORGES HARRISSO
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/03/docs/ Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:Midterm_presentation_3_2022.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 5
| [https://air.imag.fr/index.php/Dashboard_pour_Overwatch# Dashboard pour Overwatch]
| CAILLES MAXIME,REYGNER ETIENNE,VERRIER MARTIN
| Olivier RICHARD
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/05/docs/-/blob/main/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 6
| [[Application mobile d'enregistrements de noeuds IoT LoRaWAN dans plusieurs réseaux]]
| CHIOTTI MAEL,LAVIROTTE GAETAN,MOTTINO LORIS
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/06/docs/-/tree/main Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 8
| [https://air.imag.fr/index.php/Contribution_au_projet_STM32Python Intégration de composants de mesures environnementales (eau, air...) pour le projet STM32Python à destination des lycéens]
| GUIRGUIS MIRETTE,HADIBY CHEMSSEDDINE,MOHSEN HACHEM
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/08/docs/-/blob/main/README.md#lorawan Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 10
| [[Floating Water Quality Station]]
| BRETON EMERIC,FAGHLOUMI AYMAN,VIALLET CAMILLE
| Didier DONSEZ, Nicolas PALIX
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/10/docs/-/blob/main/info4_2021_2022_Fiche_suivi_projet.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/10/docs/-/blob/main/Soutenance%20mi-parcours%20Projet_S8.pdf Presentation de mi-parcours]
|-
!scope="row"| 13
| [https://air.imag.fr/index.php/G%C3%A9olocalition_Indoor_en_LoRa_2.4GHz Géolocalition Indoor en LoRa 2.4GHz]
| BERNERD CLARA,JARDIN BAPTISTE,NGUYEN JUSTIN
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/13/docs/-/blob/main/Fiche_de_suivi.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 14
| [[RealWorld avec Dioxus]]
| IFAKIREN SAMI,MONTHE DJEUMOU BRICE,NGUYEN CLEMEN
| Olivier RICHARD
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/14/docs Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 15
| [https://air.imag.fr/index.php/Rust_Engine Exécuteur de tâche en Rust]
| CHAPPAZ FLORIAN,DE OLIVEIRA VALENTIN,KURKLU FIKRET
| Olivier RICHARD
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/15/docs/-/blob/main/Rust_Engine_info4_2021_2022.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/15/docs/-/blob/main/rust_engine_mid_presentation.pdf Presentation de mi-parcours]
|-
!scope="row"| 17
| [https://air.imag.fr/index.php/Portail_pour_gestionnaire_de_taches Portail Pour Gestionnaire De Taches]
| KACHA TOM,MAHAMAN NOURY ABDOURAHAMANE,MEIGNEN HUGO,ZHANG KEMING
| Olivier RICHARD
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/17/docs/-/blob/main/Fiche_De_Suivi_17.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/17/docs/-/blob/main/Pr%C3%A9sentation-mi-parcours.pdf Presentation de mi-parcours]
|-
!scope="row"| 18
| [[Paquets NIX pour Polytech]]
| CONJARD SAMUEL,FODOR GERGELY,PELISSE-VERDOUX CYPRIEN
| Olivier RICHARD
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/18/docs/-/blob/master/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 19
| [[Mini compilateur C pour mini CPU]]
| CAPET THEO,POITEVIN EVE,ROYET JULIAN
| Olivier Richard
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/19/docs/-/blob/main/C_compiler_for_MCPU_info4_2021_2022.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 20
| Mode jeu en réseau pour [[TanksOfFreedom]],
| ABECASSIS THOMAS,FOURNIER THOMAS,ZAFFUTO LUCA
| Nicolas Palix
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/20/docs/-/blob/main/fiche_de_suivi.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
|}

==INFO5==
===Projet IoT S9===
Enseignants responsables : Bernard Tourancheau

Calendrier: Octobre à Décembre 2021. Soutenance 24 Janvier 2022.

{|class="wikitable alternance"
|+ Choix des projet des projets INFO5 Réseaux 21-22
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Documents
!scope="col"| Github/Trello
|-
!scope="row"| 1
| [[Réseau de capteur de dichlorométhane]]
| Dorian BARET - Malone JULIENNE - Quentin CAMBUS
| [https://lesjoiesducode.fr/quand-notre-revue-de-sprint-se-passe-nickel Fiche]
| [https://github.com/Cambus-Quentin/DichloWan2021/blob/main/README.md git]
|-
!scope="row"| 2
| [[Création d'un système pour localiser les élèves lors de courses d'orientation]]
| Antoine Gitton, Gilles Mertens, Bertrand Baudeur
| [[Media:2021_2022_INFO5_IOT_Orientation_spec.pdf|Spécification paquets LoRa]]
| [[Media:2021_2022_INFO5_IOT_Orientation_backend.zip|Souces back-end]] - [[Media:2021_2022_INFO5_IOT_Orientation_carte.zip|Souces carte]]
|-
!scope="row"| 3
| [[Harnais animalier permettant de suivre notre animal domestique]]
| Sami ELHADJI TCHIAMBOU, Corentin HUMBERT, Paul LAMBERT, Hugo PRAT CAPILLA
| [[Media:PSP_Presentation.pdf|Présentation finale]]
| [https://github.com/Bicorpro Organisation GitHub]
|-
!scope="row"| 4
| [[Géolocalisation et suivi des transports en commun]]
| Liam ANDRIEUX, Lucas DREZET, Roman REGOUIN
|
| [https://github.com/2021-2022-IoT-INFO5-G4 Organisation GitHub]
|-
!scope="row"| 5
| [[Tracking des déplacements de joueurs sur un terrain]]
| Elias EL YANDOUZI, Lucas CHALOYARD
| [[Media:IOT_Presentation.pdf|Présentation finale]]
| [https://github.com/Indoor-Shadow/ble-experiment Github Repo]
|-
!scope="row"| 6
| [[Beer Pong connecté]]
| Yael PARA, Théo TEYSSIER, Victor MALOD, Alexis LANQUETIN
| [[Media:BeerPong_Presentation.pdf|Présentation finale]]
| [https://github.com/McReaper/BeerPongLora Gitub Repo]
|}

Exposés points techniques 10' - questions 5'
* Nom Sujet
* ??? Python
* ??? MQTT
* ??? COAP
* 26/11/2021 - Elias El Yandouzi - Les différentes techniques de virtualisation

===Projet Semestre S10===

Enseignant responsable : [[user:Donsez|Didier Donsez]]

Convention des projets tutorés externes : Elise Didier.

Calendrier: 27/01 (8H30-12H00) au 18/03.

Séances de Management de projets innovants: A voir dessus.

Réunion de présentation et choix des sujets: 27/01 (8H30-12H00) en salle Polygone P206 (voir ADE)

Démarrage : 27/01

Soutenance à mi-parcours (à définir) : ??/02/2021 13H30-17H30 en distantiel (15 minutes par équipe).

Soutenance finale : 18/03/2021 (8H30-12H00 et 13H30-17H00). 30 minutes par équipe, questions/réponses et démonstration incluse. Prière de rapporter au fablab le matériel emprunté juste après votre soutenance.

====Séances MPI====

Voir ADE qui fait foi).

<pre>

</pre>

==== Soutenance intermédiaire S10 ====
Date: 18/02 Matin. Distantiel (sur Zoom). Créneaux de 10 minutes.

L'objectif de la soutenance intermédiaire est de vérifier si l'équipe projet est en bon ordre de marche

L'équipe présentera en 5-6 transparents en 7 minutes.
* les équipiers et leurs rôles
* le contexte, le sujet et l'objectif du projet
* l'architecture du systèmes à réaliser
* les technologies utilisées
* le plan de travail (backlog, planning, ce qui est fait, ce qu'il reste à faire ...)
* les difficultés (s'il y a)

Prévoyez du temps pour les questions-réponses (3 minutes max).

Respectez bien les créneaux indiqués (par respect pour les autres équipes) et soyez présents un peu en avance dans la salle d'attente.

La présence des porteurs n'est pas obligatoire.

==== Soutenance finale S10 ====
Date provisoire: 18/03/2022 (8H30-12H00 et 13H30-17H00).

'''La présence du(des) porteur(s) est obligatoire. Pensez à les prévenir bien à l'avance'''

Durée: 30 minutes par équipe: présentation, questions/réponses et démonstration incluse.

Les documents devront être en ligne sur le wiki (colonne Documents) la veille (ie avant le 17/03/2021 23:59:59 CET).

La présentation est constituée des chapitres suivants:
* Rappel du sujet/besoin et cahier des charges
* Technologies employées
* Architecture techniques
* Réalisations techniques
* Gestion de projet (méthode, planning prévisionnel et effectif, gestion des risques, rôles des membres ...)
* Outils (collaboration, CD/CI ...)
* Métriques logiciels : lignes de code, langages, performance, temps ingénieur (d'après vos journaux), la répartition des lignes de code et des commits en pourcentage entre les membres du projet ...)
* Conclusion (Retour d'expérience)
* Transparent expliquant la démonstration

L'ensemble des documents doit être accessible depuis le tableau ci-dessus et dans chaque fiche de suivi.

Le screencast (réalisé lors de la dernière répétition) sera rendu disponible via un partage caché (wetransfer, google drive …) dont le lien sera ajouté dans le devoir idoine sur Moodle et également envoyé par mail à votre tuteur.

Le rapport final contient les mêmes chapitres que la présentation ainsi qu'un glossaire et une bibliographie. Le rapport ne doit pas dépasser 15 pages (schémas et figures compris). Vous pourrez référencer les autres documents que vous avez produits au cours du projet (spécifications détaillées, algorithmes, conception d'écrans ...).

Le rapport final est au format Markdown et doit être placé dans un des dépôts Git de votre groupe/organisation.

Votre fiche d'auto-évaluation doit être déposée sur [https://im2ag-moodle.univ-grenoble-alpes.fr/course/view.php?id=99 Moodle]

NB: le rapport technique listé dans la colonne Documents contient tout ce qui ne tient pas dans les 15 pages du rapport final : cahier des charges, diagrammes UML, enquêtes utilisateurs design UI, API, technologies employées (détail), plan de tests, term of services, conformance RPGD, audits/diagnostiques sécurité, MTBR, rapport de vulnérabilité, plan de charge, rapports de charge, manuel d'installation … : ça dépend un peu de la nature de votre projet.

Conseil : 30 minutes c'est très court alors répétez la soutenance auparavant ! Prévoyez des transparents supplémentaires en annexe pour répondre aux questions.

'''Prière de rapporter au fablab le matériel emprunté juste après votre soutenance'''.

==== Affectations S10====
{|class="wikitable alternance"
|+ Affectation des projets INFO5 2021-2022
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Porteur(s)
!scope="col"| Fiche de suivi
!scope="col"| Documents
!scope="col"| Dépôt Git
!scope="col"| Soutenance intermédiaire
|-

!scope="row"| 1
| [[Test d'infrastructures avec NixOS]]
| HUMBERT CORENTIN, MINIER MANCINI TITOUAN (Chef de projet), SUEUR CORENTIN (Scrum master)
| Olivier RICHARD et Quentin GUILLETEAU
| [[Test Infrastructures NixOS 2021-2022|Fiche de suivi]]
| [[Rapport Test Infrastructures NixOS 2021-2022|Rapport final]] - [[Media:Presentation_finale_NixOs.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:Test infrastructures nixos Flyer.pdf|Flyer]] - [[Media:Presentation_mi_parcours_NixOs.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:English_Poster_NixOS.pdf|Poster EN]] - [[Media:Pitch_NixOS-Compose.pdf|Pitch]]
| [https://git/xxx Dépot Git]
| [[Media:Presentation_mi_parcours_NixOs.pdf|Presentation intermédiaire]]
|-

!scope="row"| 2
| [[Plan dynamique d’un appartement connecté]]
| GRANGER OSCAR (Chef de projet), NOERIE SOPHIE, SARRE MARGAUX, SALMON AMAD, TEYSSIER THEO (Scrum master)
| Sybille CAFFIAU
| [[Projet INFO5 2022 - Plan d'un appartement connecté | Fiche de suivi ]]
| [[Media:Rapport_de_projet_Plan_de_lappartement_connecte_DOMUS.pdf|Rapport final]] - [[Media:Presentation_finale_FR_DOMUS.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:Presentation_intermediaire_DOMUS.pdf|Presentation de mi-parcours]] - [[Media:Poster_DOMUS_FR.pdf|Poster FR]] - [[Media:Poster_DOMUS_EN.pdf|Poster EN]] - [[Media:Pitch_Plan_dynamique_appartement_connecte.pdf|Pitch]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/plateforme-domus/appartementdynamique Dépot Git]
| [[Media:Presentation_intermediaire_DOMUS.pdf|Presentation intermédiaire]]
|-

!scope="row"| 3
| [[Suivi de troupeaux (ovins, bovins) en zone montagneuse avec un réseau LoRaWAN : expérimentation dans la Matheysine]]
| GITTON ANTOINE, MALOD VICTOR, MUTEL MATHIS
| Fabrice FOREST
| [[PROJET-INFO5 2022 AgriLoRa|Fiche de suivi]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/-/snippets/237 Rapport final] [[Media:INFO5_AgriConnect_presentation_finale.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Flyer]] - [[Media:INFO5_AgriConnect_presentation_miparcours.pdf|Presentation de mi-parcours]] - [[Media:INFO5_AgriConnect_poster_fr.pdf|Poster FR]] - [[Media:INFO5_AgriConnect_poster_en.pdf|Poster EN]] - [[Media:INFO5_AgriConnect_pitch.pdf|Pitch]] - [https://drive.google.com/file/d/15bZaHscxOSBFGXu1xTfehl1Fqa0u_POn/view?usp=sharing Screencast]
| [https://gitlab.com/agrilora Dépot Git]
| [[Media:INFO5_AgriConnect_presentation_miparcours.pdf|Presentation intermédiaire]]
|-

!scope="row"| 4
| [[FitSize]]
| GEITNER TEVA , GONZALEZ JULES, PARA YAEL
| Fidèle Eya'a
| [XXXX Fiche]
| [https://github.com/pfefitsize/DOCS/tree/main/Rapport Rapport final] - [[Media:presentation_fitsize.pdf|Presentation finale FR]] - [[Media:PrésentationFitSize.pdf|Presentation de mi-parcours]] - [[Media:poster_fitsize.pdf|Poster EN]] - [[Media:pitch_fitsize.pdf|Pitch]] - [[Media:rapport_technique.pdf|Rapport technique]]
| [https://github.com/pfefitsize Dépot Git]
| [[Media:PrésentationFitSize.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 5
| [[GenderedNews]]
| AGUIAR MATHILDE (Chef de projet), HAJJI OUMAIMA (SCRUM Master), SIDIBE ROKIATOU DITE ROSE
| François PORTET, Gilles BASTIN, Ange RICHARD
| [[PROJET-INFO5 2022 GenderedNews|Fiche de suivi]]
| [[Media:Genderednews_rapport_.pdf|Rapport final]] - [[Media:Soutenance_finale_genderednews_.pdf|Présentation finale FR]] - [[Media:GenderedNews_final_presentation_.pdf|Final Presentation EN]] - [[Media:flyer_genderednews.pdf|Flyer]] - [[Media: Soutenance_interm_genderednews.pdf|Presentation de mi-parcours]] - [[Media:Poster-genderednews-fr.pdf|Poster FR]] - [[Media:Poster-genderednews-en.pdf|Poster EN]] - [[Media: Pitch_genderednews.pdf | Pitch 180 secondes]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/getalp/genderednews Dépot Git]
| [[Media: Soutenance_interm_genderednews.pdf|Presentation intermédiaire]]
|-

!scope="row"| 6
| [[Système d'analyse de traces sportives]]
| HERQUE ERIC (Scrum Master), VACHERIAS GUILLAUME (Chef de projet)
| Vivien QUEMA
| [[PROJET-INFO5 2022 Systeme d'analyse de traces sportive fiche suivis | Fiche de suivi]]
| [[Media:Rapport_Final_systeme_analyse_trace_sportive.pdf|Rapport final]] - [[Media:Presentation_Final_systeme_analyse_trace_sportive.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Flyer]] - [[Media:Presentation_mi_parcours_systeme_analyse_trace_sportive.pdf|Presentation de mi-parcours]]- [[Media:Poster_systeme_analyse_trace_sportive.pdf|Poster FR]] - [[Media:Poster_systeme_analyse_trace_sportive.pdf|Poster EN]] - [[PROJET-INFO5 2022 Systeme d'analyse de traces sportive pitch | Pitch 180 secondes]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/vacherig/systeme-analyse-de-traces-sportives Dépot Git]
| [[Media:Presentation_mi_parcours_systeme_analyse_trace_sportive.pdf|Presentation intermédiaire]]
|-

!scope="row"| 7
| [[Qualité de l'Air et Santé des Populations]]
| BAUDEUR BERTRAND (Scrum Master), MERTENS GILLES (Chef)
| Marie-Laure AIX
| [[Qualité de l'Air et Santé des Populations | Fiche de suivi]]
| [https://github.com/Air-Quality-LoRa/docs/blob/main/README.md Rapport final] - [[Media:presentation_finale_qualite_air.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:Presentation_mi_parcours_qualite_air_baudeur_mertens.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:Poster-Air-Quality-en.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://github.com/Air-Quality-LoRa Dépot Git]
| [[Media:Presentation_mi_parcours_qualite_air_baudeur_mertens.pdf|Presentation intermédiaire]]
|-

!scope="row"| 8
| [[Artiphonie(saison 3)]] extension de la [[Artiphonie (saison 2)]]
| BUISINE JULIEN (Chef de Projet), ELHADJI TCHIAMBOU SAMI, LAMBERT DAPHNE (Scrum Master), LAMBERT PAUL
| Olivier Richard, Estelle Gillet Perret
| [[Media: JournalDeBord_2022.pdf|Fiche de suivi]]
| [[Media:Rapport_final.pdf|Rapport final]] - [[Media:Présentation_finale_-_Artiphonie.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:Poster_Artiphonie_FR.pdf|Flyer]] - [[Media: Artiphonie-Presentation_mi-parcours.pdf|Presentation intermédiaire]] - [[Media:Poster_Artiphonie_FR.pdf|Poster FR]] - [[Media:Poster_Artiphonie_-_LAMBERT,_BUISINE,_ELHADJI_TCHIAMBOU.pdf|Poster EN]] - [[Media: Pitch_Artiphonie_2022.pdf|Pitch Artiphonie 2022]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/artiphonie/projet-info5-21-22 Dépot Git]
| [[Media: Artiphonie-Presentation_mi-parcours.pdf|Presentation intermédiaire]]
|-

!scope="row"| 9
| [[Quark Project]]
| CHALOYARD LUCAS, EL YANDOUZI ELIAS
| Olivier Gruber
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:Quark_defense.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:Soutenance QuarkV3.pdf|Presentation de mi-parcours]] - [[Media:POSTER QUARK.pdf|Poster FR]] - [[Media:POSTER QUARK.pdf|Poster EN]] - [[Media:ProjetQuark Pitch.pdf|Pitch]]
| [https://git/xxx Dépot Git]
| [[Media:Soutenance QuarkV3.pdf|Presentation intermédiaire]]
|-

!scope="row"| 10
| [[Jorigine]]
| BLANQUET ANTOINE ('''Scrum Master'''), LANQUETIN ALEXIS ('''Chef de projet'''), MALECOT ETHAN, PRAT-CAPILLA HUGO
| Sylvain Delangue
| [[Media:Fiche_Suivi_Jorigine_Grp10.pdf|Fiche de Suivi]]
| [[Media:Rapport_Jorigine_Grp10.pdf|Rapport Final]] - [[Media:Presentation_finale_jorigine_2022.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:JorigineFlyer.pdf|Flyer]] - [[Media:Presentation_Projet_miparcours_S10.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:PosterJorigine2022_vfinal.pdf|Poster EN]] - [[Media:Pitch_Jorigine_grp10.pdf|Pitch en 180 secondes]] - [https://drive.google.com/file/d/1fUGc38NtNAAjlsfBPqPdwKDNI5l7g1vs/view?usp=sharing Screencast]
| [https://git/xxx Dépot Git]
| [[Media:Presentation_Projet_miparcours_S10.pdf|Presentation intermédiaire]]
|-

!scope="row"| 11
| [[Contributions open source au projet EdCampus|EdCampus]]
| ANDRIEUX LIAM, COSOTTI KEVIN, DREZET LUCAS ('''Chef de projet'''), REGOUIN ROMAN ('''Scrum Master''')
| Anthony GEOURJON
| [https://c.tenor.com/x8v1oNUOmg4AAAAd/rickroll-roll.gif Fiche]
| [[Rapport EDCampus 2021-2022|Rapport final]] - [https://air.imag.fr/images/2/23/Soutenance_finale_-_EDCampus.pdf Presentation finale FR] - [https://air.imag.fr/images/5/5a/Soutenance_finale_EN_-_EDCampus.pdf Final Presentation EN] - [https://c.tenor.com/x8v1oNUOmg4AAAAd/rickroll-roll.gif Flyer] - [https://air.imag.fr/images/c/ca/Soutenance_interm%C3%A9diaire_-_EDCampus_2021-2022.pdf Presentation de mi-parcours] - [https://air.imag.fr/images/0/00/PosterFREDCampus20212022.pdf Poster FR] - [https://air.imag.fr/images/d/df/EDCampus_-_2021_2022.pdf Poster EN] - [https://air.imag.fr/images/d/d5/PitchEDCampus20212022.pdf Pitch]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/edcampus Dépot Git]
| [https://air.imag.fr/images/c/ca/Soutenance_interm%C3%A9diaire_-_EDCampus_2021-2022.pdf Presentation intermédiaire]
|-

!scope="row"| 12
| [[Contributions open source au projet LabnBook|LabnBook]]
| CIRSTEA PAUL, SOULARD ALEXANDRE (Chef de projet), TONDEUX EMILIE (Scrum master), YUNG KEVIN
| Anthony GEOURJON, Cédric DHAM
| [[PROJET-INFO5 2022 LabNbook|Fiche de suivi]]
| [https://github.com/AlexandreSoulard/Groupe-LabnBook/blob/main/rapportLabNbook.md Rapport final] - [[Media:LabnBook_Presentation_finale.pdf|Presentation finale FR]] - [[Media:LabNbook_flyer.pdf|Flyer]] - [[Media:LabnBook.pdf|Presentation de mi-parcours]] - [[Media:Poster_GroupLabnBook_Cirstea_Soulard_Tondeux_Yung.pdf|Poster EN]] - [https://drive.google.com/file/d/102KIVqH-wFF7UYggyVtJiUww-lcN7oXY/view?usp=sharing Pitch 180 secondes] - [https://drive.google.com/file/d/1eWU090ieX3dC8vweB4UKzwfu9E7jk1vI/view?usp=sharing Screencast]
| [https://github.com/AlexandreSoulard/Groupe-LabnBook Dépot Git]
| [[Media:LabnBook.pdf|Presentation intermédiaire]]
|-

!scope="row"| 13
| [[Green collect]]
| BARET DORIAN, CAMBUS QUENTIN (Chef de projet), JULIENNE MALONE, MALLEN GUILLAUME (Scrum master)
| Bernard TOURANCHEAU
| [https://github.com/GreenCollects/docs/blob/main/project_managment/Fiche%20de%20suivis.pdf Fiche]
| [https://github.com/GreenCollects/docs/blob/main/report/CR-Final-Report.md Rapport final] - [https://github.com/GreenCollects/docs/blob/main/soutenance/Soutenance%20final.pdf Presentation finale FR] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [https://github.com/GreenCollects/docs/blob/main/soutenance/Soutenance%20de%20mi-parcours.pdf Presentation de mi-parcours] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [https://github.com/GreenCollects/docs/blob/main/report/PosterEN.pdf Poster EN] - [https://github.com/GreenCollects/docs/blob/main/report/CR-MPI-seance2.md Pitch 180 secondes]
| [https://github.com/GreenCollects Dépot Git]
| [https://github.com/GreenCollects/docs/blob/main/soutenance/Soutenance%20de%20mi-parcours.pdf Presentation intermédiaire]
|-

|}

Sujets non choisis

# [[LoRaWAN Roaming]] avec [[Chirpstack]], [[TheThingStack]] et [[Actility]] pour le projet [https://gricad-gitlab.univ-grenoble-alpes.fr/thingsat/public/-/blob/master/cubesat_mission/README.md Thingsat]: Didier DONSEZ, Olivier ALPHAND.
# [[Contributions logicielles au projet RIOT OS pour le New Space]] : Francois-Xavier MOLINA, Olivier ALPHAND, Didier DONSEZ
# [[Réseaux social d'organisation de sortie (saison 2)]] refonte [[Réseaux social d'organisation de sortie]], Olivier Richard
# [[Experiment Process Management]], Olivier Richard
# [[Language Server for Visual Studio]]: Olivier Gruber
# ABANDONNé [[Réseau d'Alumni de formations]] (à confirmer), Gérard POLLIER ([https://disrupt-campus.univ-grenoble-alpes.fr/design-factory-grenoble/ Design Factory Grenoble])
# [[Evaluation du kit IA embarqué Wio Terminal]]: Louis CLOSSON, Didier DONSEZ (sous réserve de réception du matériel commandé)

File:Test infrastructures nixos Flyer.pdf

2022-03-18T10:53:21Z

Titouan.Minier-Mancini:

File:Nixos-kubernetes-architecture.png

2022-03-18T10:06:38Z

Titouan.Minier-Mancini: Titouan.Minier-Mancini uploaded a new version of File:Nixos-kubernetes-architecture.png

Rapport Test Infrastructures NixOS 2021-2022

2022-03-17T22:57:59Z

Titouan.Minier-Mancini: /* Démonstration */

=Rappel du sujet et cahier des charges=

L’objectif est d’expérimenter et de manipuler une technologie récente : NixOS et le projet de recherche NixOS-Compose. Nix est un outil de gestion de paquets (bibliothèques, morceau logiciel offrant certaines fonctionnalités), et NixOS est un système d'exploitation Linux qui utilise Nix dans son architecture. Nous parlerons plus en détails des différentes technologiques manipulées dans la prochaine partie.

Nos expérimentations ont consistées à déployer trois projets différents : Kubernetes, ELK et Hadoop en utilisant l'outil NixOS-Compose. La partie la plus importante n'étant pas de déployer une version aboutie et complête pour chacun de projets mais de documenter nos expériences pour fournir des retours utilisateurs permettant l'amélioration de NixOS-Compose.

=Technologies employées=

==Nix==

Nix est un gestionnaire de paquets et un langage fonctionnel qui se différencie de l'approche classique avec sa grande reproductibilité qu'il trouve incompatible avec le Filesystem Hierarchy Standard. Il dénonce l'enfer des dépendances que l'on retrouve avec cette approche où l'on ne peut pas déterminer les versions utilisées. Nix repose sur son store, où il stocke toutes les dérivations pour chaque paquet. Ces dérivations contiennent des informations sur toutes les dépendances (d'autres dérivations) et les instructions de build. Le nom de la dérivation indique le nom du paquet et un hash qui la rend unique mais surtout qui l'identifie : une même dérivation produira toujours la même sortie.

Avec cette approche, Nix permet plusieurs choses, notamment :
* La reproductibilité due au déterminisme des dérivations
* La possibilité d'utiliser plusieurs versions d'un même paquet en parallèle
* Comme le nom de la dérivation l'identifie, il est possible de mettre en cache la sortie et la récupérer sans avoir à la reconstruire

Nixpkgs est un répertoire en ligne contenant de nombreux paquets (80 000 actuellement) construits à partir de dérivations fournies par la communauté et accessibles à tous.

==NixOS==

NixOS est une distribution GNU/Linux reposant sur Nix en tant que gestionnaire de paquets mais également de gestionnaire de configuration. L'ensemble du système et toutes les configurations sont considérés comme des dérivations. Cela permet entre autres de faire des restorations du système à des versions précédentes simplement, chaque modification du système occasionne la création d'une nouvelle version atomique. Par ailleurs, le système d'exploitation hérite ainsi de la propriété déterministe et reproductible que Nix offre.

NixOS-test est une librairie de test qui permet, à partir d'un ensemble de fichiers de configuration Nix, de fournir une interface python pour manipuler ces configurations sur une/des machines virtuelles avec QEMU.

==NixOS-Compose==

NixOS-Compose est un projet de l’équipe Datamove qui étend l’utilisation de NixOS vers d’autres supports que les machines virtuelles, comme notamment la plateforme Grid'5000 et des solutions de conteneurs comme Docker.

==Kubernetes==

Kubernetes est un orchestrateur de conteneurs permettant de déployer, mettre à l'échelle et surveiller des applications conteneurisées sur un cluster de machines. Développé en Go et rendu open source en 2015 par Google inspiré de leur solution privée Borg, Kubernetes est maintenant l'outil central du monde du DevOps dans l'industrie. Il apporte une couche d'abstraction au dessus d'un datacenter, dont la mise en place a également été facilitée par le cloud, pour fournir une plateforme de déploiement fortement disponible aux développeurs. Kubernetes dispose également d'un large écosystème d'outils et plugins améliorant différents aspects de son utilisation : routage, monitoring, sécurité, gitops, déploiements (vert/bleu, canary...), serverless etc.

En cette qualité, Kubernetes est une plateforme de choix dans le cadre d'expériences nécessitant notamment un certain nombre de services ou applications, comme dans le cas d'architectures microservices par exemple. De plus, malgré ses nombreux atouts, Kubernetes est une solution souvent difficile et longue à mettre initialement en place pour cause d'une configuration complexe liée à l'architecture microservice de la plateforme elle-même. (Il faut reconnaître qu'avec le cloud il est maintenant très simple de déployer un cluster Kubernetes, Terraform est notamment un concurrent potentiel de NixOS-Compose)

Dans le cadre de notre projet, être en mesure de fournir un cluster Kubernetes de la taille voulue, simplement, rapidemment et de manière reproductible, est un objectif très intéressant, non seulement pour l'aspect apprentissage mais également pour son utilisation dans le contextes d'expériences scientifiques avec NixOS-Compose. Kubernetes est en lui même un solution qui permet une forte reproductibilité au niveau des déploiements internes, mais c'est la phase de déploiement des machines et de bootstrap du cluster qui manque cette qualité, et c'est là que nous nous positionnons.

==ELK==

"ELK" est l'acronyme de trois projets open source : Elasticsearch, Logstash et Kibana.

===Elasticsearch===

Elasticsearch est un outil de recherche et d'analyse de données fonctionnant de manière distribuée et basé sur [Apache Lucene](https://lucene.apache.org/). Créé par Shay Banon en 2004, au fil des années, Elasticsearch n'a cessé d'évoluer et aujourd'hui c'est l'outil de référence pour réaliser une recherche performante sur une large quantité de données.

Technologiquement parlant, il s'agit d'une base de données programmée en Java et spécialisée dans la recherche et l'indexation de documents. Si Elasticsearch est aussi performant c'est grâce à son fonctionnement en mode distribué. La tâche de recherche est exécutée en parallèle par plusieurs nœuds Elasticsearch, ce qui améliore la réactivité du système. Elasticsearch a aussi la force d'être facilement configurable et mis à l'échelle.

===Logstash===

Logstash est un outil écrit en Java et en Ruby permettant de **centraliser des traces** provenant de plusieurs systèmes, de les analyser et de les stocker. Conceptuellement, Logstash peut être vu comme un "pipe" où les données rentrent d'un bout, et sont traitées avant de ressortir de l'autre bout. Logstash est plus qu'un simple "pipe" puisqu'il peut prendre une multitude de sources différentes en entrées et renvoyées les données traitées vers différentes sorties. Il sert généralement à filtrer/analyser des messages avant de les envoyer à Elasticsearch qui va, lui, se charger de les stocker et de les indexer.

===Kibana===

Kibana est un outil permettant la visualisation de données écrit en JavaScript est la dernière composante majeure de la stack ELK. Il est similaire à d'autres outils de visualisation tel que [Grafana](https://grafana.com/), mais a la particularité d'être spécialisé pour une utilisation au sein de la stack ELK. Le rôle de Kibana est donc de récupérer les données indexées par Elasticsearch et de les rendre visuellement exploitables pour un humain.

===Beats===

Bien que la stack ELK soit l'acronyme des trois projets majeurs dont nous avons parlé précédemment, ELK est consistué d'un autre projet nommé Beats. Il y a d'ailleurs quelques discussions autour du renommage de la stack ELK en stack BELK pour inclure le projet Beats. Beats est une plateforme réunissant une multitude de petits outils permettant d'expédier des données vers Logstash ou Elasticsearch. Chaque outil vise un type de données spécifiques. On retrouvera par exemple l'outil Filebeat pour l'expédition de traces systèmes, Metricbeat pour les métriques, Packetbeat pour le réseau ou encore Heartbeat pour le monitoring. Cette liste est non exhaustive, il existe plein d'autres beats, chacun spécialisé pour des données de nature différente.

==Hadoop==

Hadoop est un framework open source Java destiné à faciliter la création d'applications distribuées (au niveau du stockage des données et de leur traitement) et scalables permettant aux applications de travailler avec des milliers de nœuds et des masses importantes de données. Ainsi chaque nœud est constitué de machines standard regroupées en grappe. Hadoop fonctionne avec de nombreux modules ou services conçus selon l'idée que les pannes matérielles sont fréquentes et qu'en conséquence elles doivent être gérées automatiquement par le framework. Cet aspect de redondance n'est pas traité dans ce projet.

=Architectures techniques=

==Kubernetes==

L'architecture de Kubernetes est distribuée sous forme de microservices avec plusieurs composants, chacun responsable d'une certaine tâche pour contrôler le cluster et les applications qui y vivent. Tout d'abord, les composants sont à séparer en deux groupes: le control plane, tête pensante du cluster, et les composants des nodes, responsables de faire fonctionner les conteneurs. Une machine est dite nœud maître dès lors qu'elle est membre du control plane (elle exécute les composants du control plane, seule ou en communication avec les autres maîtres). Une machine peut à la fois être maître et exécuter des conteneurs (control plane et *Node*), ce n'est toutefois pas recommandé au vu de l'importance du rôle du control plane.

[[File:nixos-kubernetes-architecture.png|center]]

Source : https://kubernetes.io/docs/concepts/overview/components

===Control plane===

Le control plane est un ensemble de composants responsable du bon fonctionnement du cluster. Ces composants sont présents sur chaque nœud maître du cluster. Dans le cas d'un cluster à haute disponibilité (plusieurs maîtres), ces composants fonctionnent de manière distribuée, et nécessitent un load balancer.

Le composant principal est l'apiserver, qui est donc une API permettant la communication entre les différents composants. L'apiserver est le seul composant avec qui les autres composants communiquent. Ensuite le controller manager, regroupe les différents contrôleurs dont le rôle est de gérer les resources qui leur corresponde (le contrôleur des *Pod* veille au bon fonctionnement des Pod, pareil pour les ReplicasSet, Endpoint, Node...). Le scheduler est responsable de l'attribution des resources (machines) aux applications (Pod, Deployment...) selon les disponibilités et besoins. Enfin, etcd est une base de données distribuée de configuration qui conserve l'état du cluster. C'est une solution tiers et elle peut être exécutée sur un cluster à part des nœuds maître.

===Node===

Pour Kubernetes, un Node (ou nœud en français) est l'abstraction d'une machine (réelle ou virtuelle). Chaque machine représentant un Node doit faire tourner trois services: le kubelet, le kube-proxy et un environnement d'exécution de conteneurs.

Le kubelet est véritablement le responsable des conteneurs en pratique, il est le contremaître obéissant au control plane, chargé de faire appliquer ses directives. Le kubelet ordonne à l'environnement d'exécution de conteneurs et fait ses rapports de situation au control plane. Le kube-proxy est chargé de mettre en place les règles de réseau (iptables ou IPVS) pour veiller au bon fonctionnement notamment des Service et Endpoint. Enfin, l'environnement d'exécution de conteneurs peut être n'importe quel solution respectant la CRI (container runtime interface) comme containerd ou CRI-O.

Non-obligatoire mais également souvent présent est un plugin de CNI (container network interface) qui met en place le plan de réseau exigé par Kubernetes (à savoir un réseau où les Pod disposent d'une adresse IP et peuvent communiquer entre eux) à ne pas confondre avec le réseau connectant les machines entre elles. On peut citer notamment Calico, Weave et celui qui est utilisé dans notre projet est Flannel (moins puissant). Parmi les addons on retrouve également un serveur DNS (nécessaire au bon fonctionnement des Services), anciennement kube-dns et maintenant plutôt coredns.

==ELK==

En ce qui concerne ELK, il ne s'agit non pas d'un système ou d'un outil en lui-même mais de la collaboration d'une multitude d'outils open source ayant chacun leurs particularités et un fonctionnement qui leur est propre. Pour visualiser plus aisément l'intéraction entre les différentes composantes de la stack ELK, on pourra s'intéresser à l'exemple suivant:

[[File:nixos-elk-architecture.png|center]]

Source : https://fr.wikipedia.org/wiki/Logstash

Dans l'exemple ci-dessus, on distingue trois sources indépendantes: MediaWiki, des services Node.js et Hadoop. Chacune des trois sources envoie des données à une instance différente de Logstash. Les instances de Logstash ne communiquent pas entre elles, toutefois, une fois le traitement des données effectué, chaque instance envoie ses données à un nœud Elasticsearch. Dans le schéma ci-dessus, les trois nœuds font partie d'un même cluster, ce qui permet donc la mise en commun de l'intégralité des données pouvant ensuite être visualisées via Kibana.

==Hadoop==

Hadoop est un environement distribué de par son stockage mais également son traitement de données. C'est une suite de solution open source pour le big data. The goal is to instanciate the different kind of nodes from one of the two possible implementation below, and make them communicate to run a job on the cluster.

[[File:nixos-hadoop-architecture-1.png|center]]

[[File:nixos-hadoop-architecture-2.png|center]]

Source : https://www.geeksforgeeks.org/hadoop-introduction

=Réalisations techniques=

==Kubernetes==

L'expérience avec Kubernetes consiste avant tout à déployer un cluster Kubernetes fonctionnel, utilisable comme n'importe quel autre cluster. Pour cela nous nous reposons donc tout d'abord sur la dérivation de Kubernetes sur nixpkgs. Ensuite nous utilisons d'autres outils comme Helm et Istio pour enrichir l'expérience.

La dérivations de Kubernetes propose la version 1.21.6, avec certains aspects de configuration qui sont cependant déprécié (notamment au niveau des ports uti lisés et des flags devenus déconseillés) car non mis à jour depuis 4 ans. La configuration de cette dérivation peut se faire de deux manière: en précisant la configuration de tous les composants (cf. partie II), ou en précisant uniquement le rôle de la machine. Avec la première approche non pouvons avoir un contrôle complet sur la configuration alors que dans le second tout est plus abstrait. En revanche la deuxième manière est plus simple et plus claire. Nous avons opté pour la seconde en ajoutant un certain nombre d'options supplémentaires.

La composition de l'expérience commence avec la description des machines ainsi que leur rôle dans le cluster. Nous utilisons généralement un nœud maître et deux nœuds de travail, sachant qu'il n'est pas possible actuellement de déployer un cluster à haute disponibilité dont le bootstrap des certificats est automatisé dans le déploiement, autrement il faut le faire manuellement ce qui est hors de question dans le cadre d'un environnement reproductible.

Ensuite nous disposons d'une fonction pour générer la configuration des machines du cluster. Cette configuration contient donc le rôle du node mais également des ajustements sur les ports et addresses IP de certains composants pour permettre la bonne communication des composants entre eux.

Nous ajoutons également une machine supplémentaire hors-cluster, c'est une serveur NFS, une solution parmis d'autres pour fournir au cluster un moyen de créer des volumes (PersistentVolume) accessibles par tous les nœuds. Ce serveur est monté sur toutes les machines, ce qui permet à l'expérimentateur de soit utiliser des volumes NFS, soit des volumes locaux pour plus de simplicité.

Avec Istio nous pouvons suivre le guide d'exemple présent dans la documentation pour déployer une application microservice et vérifier le bon fonctionnement du cluster.

Cette composition est fonctionnelle pour la plateforme de nixos-test et nixos-test-driver, toutes deux reposant sur QEMU, et également sur Grid'5000 où elle dévoile son vrai potentielle car les machines sont réelles et véritablement utilisables pour administrer le cluster. Elle n'est pas fonctionnelle sur Docker pour des raisons propres à NixOS-Compose qui ne permettent pas de modifier les noms d'hôtes (/etc/hosts), ce qui empêche la dérivation de fonctionner correctement.

Certains éléments de bootstrap se révèlent être difficilement applicable lors du déploiement avec NixOS-Compose et nous reposons donc en partie sur un script d'initialisation du cluster. Ce script est créé dans la composition et accessible dans le path. Il redémarre les composants éventuellement échoués et affiche une commande à l'utilisateur permettant d'ajouter des machines au cluster, cette étape n'tant pas automatisable simplement (l'approche est la même que kubeadm).

==ELK==

Pour ce qui est de l'expérience ELK, une grande partie du temps a été passée à comprendre la stack ELK et ses différentes composantes. Pour réaliser une composition fonctionnelle via NixOS-Compose, nous nous sommes basés sur une composition pré-existante écrite pour NixOS-Tests. La composition a ensuite été modifiée de manière à fonctionner correctement pour les différents modes de déploiement (Docker, Grid'5000).

==Hadoop==

Un paquet hadoop existe deja et il s'agit principalement d'en faire sa configuration. Plusieurs configurations différentes ont été réalisées, une minimale afin de comprendre le fonctionnement général, puis une se servant de yarn afin de maitriser la multiplicité des nœuds de travail.

Dans la composition minimale nous avons pu mettre, comme le premier shéma de la partie précédente, créer un node de front (namenode) ainsi qu'un datanode fonctionnant avec le filesystem.

=Gestion de projet=

Ce projet relève en partie d’un travail de recherche au vu du manque de documentation, du développement toujours en cours de l’OS et de sa faible utilisation de la part de la communauté d’utilisateurs.

Une importante partie de ce projet repose sur la communication entre notre équipe et l’équipe Datamove pour recevoir des consignes et fournir des retours. Pour fluidifier ces échanges nous avons organisé des réunions régulières et mis en place des solutions de communication en permanence à travers des outils comme Telegram et Zoom pour les réunions.

Nous avons mis en place deux types de réunions : des réunions quotidiennes avec un membre de l’équipe Datamove et des réunions hebdomadaires en équipe complète. Les réunions quotidiennes servent principalement à partager l’avancement et exprimer des éventuels blocages. Les réunions hebdomadaires visent davantage à faire un point global et à définir les prochaines étapes.

==Planification==

Pour ce qui est de la planification, il nous paraissait essentiel pour un projet comme le nôtre dans lequel énormément de temps est alloué à l'apprentissage d'une technologie plutôt qu'à la production réelle de code de définir une roadmap.

Cette roadmap avait pour but de planifier nos actions sur l’ensemble de la durée du projet. Nous avons fait évoluer la roadmap au fur et à mesure de notre avancement réel. Celle-ci nous a permis non seulement de travailler avec un objectif en tête mais également de partager ces objectifs avec l’équipe Datamove.

==Organisation du travail==

Au commencement de projet, notre objectif à tous était de se former rapidement sur Nix afin de comprendre l'étendu des possibilités de l'outil NixOS-Compose et de commencer à le tester.

Notre première tâche a consisté à écrire une composition k3s compatible avec NixOS-Compose de manière à découvrir la puissance de l'outil.

Ensuite, nous sommes chacun parti sur un projet différent dans l'optique de fournir trois expériences utilisateurs distinctes. La répartition des projets était la suivante :
* Titouan Minier Mancini : Kubernetes
* Corentin Humbert : Stack ELK
* Corentin Sueur : Hadoop

Nous avons donc progressé chacun de notre côté sur nos projets respectifs tout en restant en contact constant de manière à éviter de passer trop temps bloqué sur une partie du projet. La communication a été impérative pour un tel projet au vu de sa complexité et du temps dont nous disposions pour le mener à terme.

==Suivi du travail==

En parallèle nous avons suivi la rédaction de carnets de route individuels où nous expliquons toutes nos actions dans la journée, avec un maximum de détails notamment sur les erreurs. L’objectif est de permettre aux membres de l’équipe Datamove de suivre notre avancée individuelle et d’aider sur les problèmes techniques éventuels. Ces carnet doivent permettre un maximum la reproductibilité des situations pour faciliter la correction.

=Outils de travail=

Au cours de notre projet, nous avons été amenés à utiliser de nombreux outils nous permettant d’échanger entre nous et avec l’équipe Datamove que ce soit pour poser des questions ou partager nos productions.

* Communication écrite/orale :
** Au sein du groupe : Discord
** Avec l’équipe Datamove : Telegram, BBB, Zoom
* Échanges d’informations :
** Google docs, CodiMD
* Stockage des documents et du code produit :
** Dépôt GitLab

=Métriques logiciels=

Ce projet ne rentre pas dans le cadre d'une production logicielle, la quantité de code produit est faible car le travail est avant tout un travail de compréhension et de recherche. Nous avons produit un fichier de composition pour chaque pile logicielle, ce qui correspond à une centaine de lignes chacune. Le temps était principalement accordé à l'essai, l'avancement à tâtons pour explorer les différentes options disponibles, et à la compréhension du fonctionnement de NixOS-Compose.

Nous avons tous travaillé 35 heures par semaine, à l'exception des première semaines en parallèle avec le projet ECOM où Titouan et Corention Humbert n'étaient plus disponibles qu'à hauteur de 21 à 28 heures par semaine.

=Conclusion=

Ce projet nous a avant tout permis de découvrir l'environnement Nix et la solution NixOS-Compose, qui promet d'être intéressante et un candidat potentiel à l'*Infrastructure as Code* de demain. L'approche est différente de ce que l'on peut rencontrer avec d'autres outils comme Terraform et il est enrichissant de s'y pencher pour élargir sa pensée.

Nous avons également pu travailler sur des piles logicielles que nous ne connaissions pas forcément, ce qui a aussi été très enrichissant. Nous avons appris à utiliser ces piles logicielles et à les configurer, ce qui est généralement le plus important pour ce genre de système. Nous avons appris ou réappris des technologies, et amélioré notre capacité à appréhender un système distribué, savoir d'où viennent les problèmes et comment les résoudre.

Les compositions que nous avons pu fournir à l'issue du projet sont très satisfaisantes. Elles sont fonctionnelles et permettent à d'autres utilisateurs d'appréhender la solution NixOS-Compose. Nous avons également fourni des tutoriels et explications avec ces compositions pour exprimer des retours utilisateur au projet NixOS-Compose, ce qui, nous espérons, permettra de mettre en valeur ce beau projet.

=Démonstration=

La démonstration que nous proposons est de présenter le déploiement de chacune des piles logicielles.

Vidéo de démonstration sur Kubernetes: https://www.youtube.com/watch?v=uOh8BJPj7MU

Rapport Test Infrastructures NixOS 2021-2022

2022-03-17T21:45:04Z

Titouan.Minier-Mancini: /* Kubernetes */

Test Infrastructures NixOS 2021-2022

2022-03-17T21:33:03Z

Titouan.Minier-Mancini: Created page with "==Carnet Titouan Minier Mancini== https://gitlab.inria.fr/nixos-compose/projet-info5/carnet/-/blob/main/titouan-minier-mancini.md ==Carnet Corentin Humbert== https://gitlab..."

==Carnet Titouan Minier Mancini==

https://gitlab.inria.fr/nixos-compose/projet-info5/carnet/-/blob/main/titouan-minier-mancini.md

==Carnet Corentin Humbert==

https://gitlab.inria.fr/nixos-compose/projet-info5/carnet/-/blob/main/corentin-humbert.md

==Carnet Corentin Sueur==

https://gitlab.inria.fr/nixos-compose/projet-info5/carnet/-/blob/main/corentin-sueur.md

Projets 2021-2022

2022-03-17T21:17:27Z

Titouan.Minier-Mancini: /* Affectations S10 */

<<[[Projets 2020-2021]] | [[Projets]] | [[Projets 2022-2023]]>>
=INFO=
==INFO3==

==INFO4==
===Projet Semestre S8===

Enseignants responsables : Olivier Richard

* Dates : Lundi après-midi, Mardi après-midi
* Lancement: 10 Janvier 2021 après midi
* Soutenance à mi-parcours: A définir
* Soutenance: A définir

* '''Evaluation à mi-parcours le lundi/mardi ???''': Format: 10min (5min de présentation 3 slides au plus, 5min de discussion). Cette évaluation sera prise en compte dans la note finale.

'''Consignes générales:'''

* '''Vous devez être pro-actifs !!!''': Si des points sont pas ou mals spécifiés, vous le faîtes et vous justifiez vos choix. Pour les problèmes techniques éventuels vous pouvez: creuser la question, contacter l'auteur du code si il y a lieu, écrire un rapport de bug ('''Attention:''' ca se prépare !), soumettre un patch/pull request, contacter l'enseignant ou la personne référente du projet.

* '''Vous devez maintenir une fiche de suivi de projet''': elle doit être mise à jour chaque semaine, elle rassemble les élements essentiels du projet, elle indique les évolutions du projet et présente sa feuille de route. '''Note:''' le nom de la fiche doit être composé du nom du projet et suffixé par info4_2021_2022. '''Cette fiche compte pour la note finale'''

* '''Votre code''' pour doit être hébergé sur le gitlab et à l'URL suivante https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22 , vous utiliserez votre compte UGA.

* Chaque projet doit avoir '''aux moins 2 dépôts git''':
** '''Un pour les documents''' demandés rapport, présentation de pré-soutenante, de soutenance, flyer. '''Il sera appelé documents.'''
** Un ou plusieurs pour le code, les tests, les évaluations, les preuves de concept, la ou les documentations afférentes.

* Les '''documents public doivent être rédigés en anglais (README, documentation, commentaires de code, nom de variables et de fonctions)'''. Le *rapport* sera aussi demandé en *anglais* (il fera la taille d'un rapport de TP). Les transparents des présentation peuvent être en anglais ou en francais, la soutenance sera taire en francais.

* '''La note obtenue''' tiendra compte du '''nombre et de la qualité des commits''' observé dans '''vos dépots git et la branche master''' (or depot documents). La qualité comprend l'intitulé du commit et son contenu. Les notes pourront être différentiées dans un groupe, il n'est pas acceptable de pas avoir de commit dans le(s) dépôt(s) du projet (or dépôt documents).

* Il est fortement conseillé de suivre un '''développement incrémental''' qui permette d'avoir à tout moment un démonstrateur à présenter, un projet peut être constituer d'une succession de '''démonstrateurs présentables séparément'''.

* Vous devez faire aussi des '''schémas d'architectures générales et/ou spéficiques, des diagrammes de séquence''', et autre documents de spécification si nécessaire. Ces documents vous serviront de base de discussion/brainstorming interne ainsi que dans vos différents documents (rapport, présentations, documentation). Ces schémas sont avant tout conceptuels et techniques.

===Propositions de projets S8===

* 1. [https://codimd.math.cnrs.fr/?next=%2Fs%2FB029qfT5Q Courriels à Suppression Programmée] : Michaël Périn
* 2. [[Firmwares open source pour une station de réception de satellites pour l’Internet des Objets isolés]], Didier DONSEZ.
* 3. [[Evaluation du toolkit AI de STM32 pour l'analyse de l'environnement sonore]] (Suite 2022), Didier DONSEZ.
* 4. [[Algorithmes de géolocalisation d’objets par TDOA (Time Difference of Arrival)]] (suite), Didier DONSEZ.
* 5. [[Dashboard pour Overwatch]] Olivier Richard
* 6. [[Application mobile d'enregistrements de noeuds IoT LoRaWAN dans plusieurs réseaux]] (Suite) : Didier DONSEZ
* 7. [[Bluetooth 5.1 Angle of Arrival based Indoor Localization]] (Suite) : Didier DONSEZ
* 8. Intégration de composants de mesures environnementales (eau, air, ...) pour le [[Contribution au projet STM32Python|projet STM32Python]] à destination des lycéens: Didier DONSEZ
* 9. [[Air Quality Station]] (Suite) : Didier DONSEZ
* 10. [[Floating Water Quality Station]] : Didier DONSEZ, Nicolas PALIX
* 12. [[Testeur de terrain pour réseaux LoRaWAN privés et publics (TTN, CampusIoT et Helium)]] (suite 2021), Didier DONSEZ.
* 13. [[Géolocalition Indoor en LoRa 2.4GHz]], Didier DONSEZ.
* 14. [[RealWorld avec Dioxus]] (Rust + web), Olivier Richard
* 15. Poursuite projet 20-21 [[Rust Engine | Executeur de tâche en Rust]], Olivier Richard
* 16. Poursuite projet 20-21 [[Retrocompute simulateur | RetroComputing]]: (vintage style) Coupler le simulateur Digital avec un simulateur de processeur 8bits, Olivier Richard
* 17. Poursuite projet 19-20 [[Portail pour gestionnaire de taches]](react, Typescript), Olivier Richard
* 18. [[Paquets NIX pour Polytech]], Olivier Richard
* 19. [[Mini compilateur C pour mini CPU]], Olivier Richard
* 20. Mode jeu en réseau (Wifi/Bluetooth) pour [[TanksOfFreedom]], Nicolas Palix

Non affecté
* xx. [[Bibliothèque de décodeurs standards et d'afficheurs Grafana pour objets connectés LoRaWAN]] : Didier DONSEZ
* xx. [[ASAC|Agriculture connectée]] en partenariat avec les projets collectifs IESE/MAT : Nicolas Palix
* xx. [[Faults In Linux]], Nicolas Palix

===Affectations===
{|class="wikitable alternance"
|+ Affectation des projets INFO4 21-22
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Enseignant(s)
!scope="col"| Fiche de suivi
!scope="col"| Documents
|-
!scope="row"| 1
| [https://air.imag.fr/index.php/Planned_Deletion_Emails Courriels à Suppression Programmée]
| CANIN CORENTIN,MONTEILLER JOSHUA,WAGNER SAMY
| Michaël PÉRIN
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/01/docs/-/blob/main/%20Courriels%20%C3%A0%20Suppression%20Programm%C3%A9e%20info4_2021_2022.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 2
| [https://air.imag.fr/index.php/Firmwares_open_source_pour_une_station_de_r%C3%A9ception_de_satellites_pour_l%E2%80%99Internet_des_Objets_isol%C3%A9s# Firmwares open source pour une station de réception de satellites pour l’Internet des Objets isolés]
| CARMONA DAMIAN,DA COSTA TOM,WOZNY PIERRE-RAPHAEL
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/02/docs/-/blob/main/Firmwares_open_source_pour_une_station_de_r%C3%A9ception_de_satellites_pour_l_Internet_des_Objets_isol%C3%A9s_info4_2021_2022.md# Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 3
| [https://air.imag.fr/index.php/Evaluation_du_toolkit_AI_de_STM32_pour_l%27analyse_de_l%27environnement_sonore Evaluation du toolkit AI de STM32 pour l'analyse de l'environnement sonore]
| BACH THOMAS,BARBE FLORENT,SIMO YOKAM GEORGES HARRISSO
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/03/docs/ Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:Midterm_presentation_3_2022.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 5
| [https://air.imag.fr/index.php/Dashboard_pour_Overwatch# Dashboard pour Overwatch]
| CAILLES MAXIME,REYGNER ETIENNE,VERRIER MARTIN
| Olivier RICHARD
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/05/docs/-/blob/main/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 6
| [[Application mobile d'enregistrements de noeuds IoT LoRaWAN dans plusieurs réseaux]]
| CHIOTTI MAEL,LAVIROTTE GAETAN,MOTTINO LORIS
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/06/docs/-/tree/main Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 8
| [https://air.imag.fr/index.php/Contribution_au_projet_STM32Python Intégration de composants de mesures environnementales (eau, air...) pour le projet STM32Python à destination des lycéens]
| GUIRGUIS MIRETTE,HADIBY CHEMSSEDDINE,MOHSEN HACHEM
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/08/docs/-/blob/main/README.md#lorawan Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 10
| [[Floating Water Quality Station]]
| BRETON EMERIC,FAGHLOUMI AYMAN,VIALLET CAMILLE
| Didier DONSEZ, Nicolas PALIX
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/10/docs/-/blob/main/info4_2021_2022_Fiche_suivi_projet.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/10/docs/-/blob/main/Soutenance%20mi-parcours%20Projet_S8.pdf Presentation de mi-parcours]
|-
!scope="row"| 13
| [https://air.imag.fr/index.php/G%C3%A9olocalition_Indoor_en_LoRa_2.4GHz Géolocalition Indoor en LoRa 2.4GHz]
| BERNERD CLARA,JARDIN BAPTISTE,NGUYEN JUSTIN
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/13/docs/-/blob/main/Fiche_de_suivi.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 14
| [[RealWorld avec Dioxus]]
| IFAKIREN SAMI,MONTHE DJEUMOU BRICE,NGUYEN CLEMEN
| Olivier RICHARD
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/14/docs Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 15
| [https://air.imag.fr/index.php/Rust_Engine Exécuteur de tâche en Rust]
| CHAPPAZ FLORIAN,DE OLIVEIRA VALENTIN,KURKLU FIKRET
| Olivier RICHARD
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/15/docs/-/blob/main/Rust_Engine_info4_2021_2022.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/15/docs/-/blob/main/rust_engine_mid_presentation.pdf Presentation de mi-parcours]
|-
!scope="row"| 17
| [https://air.imag.fr/index.php/Portail_pour_gestionnaire_de_taches Portail Pour Gestionnaire De Taches]
| KACHA TOM,MAHAMAN NOURY ABDOURAHAMANE,MEIGNEN HUGO,ZHANG KEMING
| Olivier RICHARD
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/17/docs/-/blob/main/Fiche_De_Suivi_17.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/17/docs/-/blob/main/Pr%C3%A9sentation-mi-parcours.pdf Presentation de mi-parcours]
|-
!scope="row"| 18
| [[Paquets NIX pour Polytech]]
| CONJARD SAMUEL,FODOR GERGELY,PELISSE-VERDOUX CYPRIEN
| Olivier RICHARD
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/18/docs/-/blob/master/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 19
| [[Mini compilateur C pour mini CPU]]
| CAPET THEO,POITEVIN EVE,ROYET JULIAN
| Olivier Richard
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/19/docs/-/blob/main/C_compiler_for_MCPU_info4_2021_2022.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 20
| Mode jeu en réseau pour [[TanksOfFreedom]],
| ABECASSIS THOMAS,FOURNIER THOMAS,ZAFFUTO LUCA
| Nicolas Palix
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/20/docs/-/blob/main/fiche_de_suivi.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
|}

==INFO5==
===Projet IoT S9===
Enseignants responsables : Bernard Tourancheau

Calendrier: Octobre à Décembre 2021. Soutenance 24 Janvier 2022.

{|class="wikitable alternance"
|+ Choix des projet des projets INFO5 Réseaux 21-22
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Documents
!scope="col"| Github/Trello
|-
!scope="row"| 1
| [[Réseau de capteur de dichlorométhane]]
| Dorian BARET - Malone JULIENNE - Quentin CAMBUS
| [https://lesjoiesducode.fr/quand-notre-revue-de-sprint-se-passe-nickel Fiche]
| [https://github.com/Cambus-Quentin/DichloWan2021/blob/main/README.md git]
|-
!scope="row"| 2
| [[Création d'un système pour localiser les élèves lors de courses d'orientation]]
| Antoine Gitton, Gilles Mertens, Bertrand Baudeur
| [[Media:2021_2022_INFO5_IOT_Orientation_spec.pdf|Spécification paquets LoRa]]
| [[Media:2021_2022_INFO5_IOT_Orientation_backend.zip|Souces back-end]] - [[Media:2021_2022_INFO5_IOT_Orientation_carte.zip|Souces carte]]
|-
!scope="row"| 3
| [[Harnais animalier permettant de suivre notre animal domestique]]
| Sami ELHADJI TCHIAMBOU, Corentin HUMBERT, Paul LAMBERT, Hugo PRAT CAPILLA
| [[Media:PSP_Presentation.pdf|Présentation finale]]
| [https://github.com/Bicorpro Organisation GitHub]
|-
!scope="row"| 4
| [[Géolocalisation et suivi des transports en commun]]
| Liam ANDRIEUX, Lucas DREZET, Roman REGOUIN
|
| [https://github.com/2021-2022-IoT-INFO5-G4 Organisation GitHub]
|-
!scope="row"| 5
| [[Tracking des déplacements de joueurs sur un terrain]]
| Elias EL YANDOUZI, Lucas CHALOYARD
| [[Media:IOT_Presentation.pdf|Présentation finale]]
| [https://github.com/Indoor-Shadow/ble-experiment Github Repo]
|-
!scope="row"| 6
| [[Beer Pong connecté]]
| Yael PARA, Théo TEYSSIER, Victor MALOD, Alexis LANQUETIN
| [[Media:BeerPong_Presentation.pdf|Présentation finale]]
| [https://github.com/McReaper/BeerPongLora Gitub Repo]
|}

Exposés points techniques 10' - questions 5'
* Nom Sujet
* ??? Python
* ??? MQTT
* ??? COAP
* 26/11/2021 - Elias El Yandouzi - Les différentes techniques de virtualisation

===Projet Semestre S10===

Enseignant responsable : [[user:Donsez|Didier Donsez]]

Convention des projets tutorés externes : Elise Didier.

Calendrier: 27/01 (8H30-12H00) au 18/03.

Séances de Management de projets innovants: A voir dessus.

Réunion de présentation et choix des sujets: 27/01 (8H30-12H00) en salle Polygone P206 (voir ADE)

Démarrage : 27/01

Soutenance à mi-parcours (à définir) : ??/02/2021 13H30-17H30 en distantiel (15 minutes par équipe).

Soutenance finale : 18/03/2021 (8H30-12H00 et 13H30-17H00). 30 minutes par équipe, questions/réponses et démonstration incluse. Prière de rapporter au fablab le matériel emprunté juste après votre soutenance.

====Séances MPI====

Voir ADE qui fait foi).

<pre>

</pre>

==== Soutenance intermédiaire S10 ====
Date: 18/02 Matin. Distantiel (sur Zoom). Créneaux de 10 minutes.

L'objectif de la soutenance intermédiaire est de vérifier si l'équipe projet est en bon ordre de marche

L'équipe présentera en 5-6 transparents en 7 minutes.
* les équipiers et leurs rôles
* le contexte, le sujet et l'objectif du projet
* l'architecture du systèmes à réaliser
* les technologies utilisées
* le plan de travail (backlog, planning, ce qui est fait, ce qu'il reste à faire ...)
* les difficultés (s'il y a)

Prévoyez du temps pour les questions-réponses (3 minutes max).

Respectez bien les créneaux indiqués (par respect pour les autres équipes) et soyez présents un peu en avance dans la salle d'attente.

La présence des porteurs n'est pas obligatoire.

==== Soutenance finale S10 ====
Date provisoire: 18/03/2022 (8H30-12H00 et 13H30-17H00).

'''La présence du(des) porteur(s) est obligatoire. Pensez à les prévenir bien à l'avance'''

Durée: 30 minutes par équipe: présentation, questions/réponses et démonstration incluse.

Les documents devront être en ligne sur le wiki (colonne Documents) la veille (ie avant le 17/03/2021 23:59:59 CET).

La présentation est constituée des chapitres suivants:
* Rappel du sujet/besoin et cahier des charges
* Technologies employées
* Architecture techniques
* Réalisations techniques
* Gestion de projet (méthode, planning prévisionnel et effectif, gestion des risques, rôles des membres ...)
* Outils (collaboration, CD/CI ...)
* Métriques logiciels : lignes de code, langages, performance, temps ingénieur (d'après vos journaux), la répartition des lignes de code et des commits en pourcentage entre les membres du projet ...)
* Conclusion (Retour d'expérience)
* Transparent expliquant la démonstration

L'ensemble des documents doit être accessible depuis le tableau ci-dessus et dans chaque fiche de suivi.

Le screencast (réalisé lors de la dernière répétition) sera rendu disponible via un partage caché (wetransfer, google drive …) dont le lien sera ajouté dans le devoir idoine sur Moodle et également envoyé par mail à votre tuteur.

Le rapport final contient les mêmes chapitres que la présentation ainsi qu'un glossaire et une bibliographie. Le rapport ne doit pas dépasser 15 pages (schémas et figures compris). Vous pourrez référencer les autres documents que vous avez produits au cours du projet (spécifications détaillées, algorithmes, conception d'écrans ...).

Le rapport final est au format Markdown et doit être placé dans un des dépôts Git de votre groupe/organisation.

NB: le rapport technique listé dans la colonne Documents contient tout ce qui ne tient pas dans les 15 pages du rapport final : cahier des charges, diagrammes UML, enquêtes utilisateurs design UI, API, technologies employées (détail), plan de tests, term of services, conformance RPGD, audits/diagnostiques sécurité, MTBR, rapport de vulnérabilité, plan de charge, rapports de charge, manuel d'installation … : ça dépend un peu de la nature de votre projet.

Conseil : 30 minutes c'est très court alors répétez la soutenance auparavant ! Prévoyez des transparents supplémentaires en annexe pour répondre aux questions.

'''Prière de rapporter au fablab le matériel emprunté juste après votre soutenance'''.

==== Affectations S10====
{|class="wikitable alternance"
|+ Affectation des projets INFO5 2021-2022
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Porteur(s)
!scope="col"| Fiche de suivi
!scope="col"| Documents
!scope="col"| Dépôt Git
!scope="col"| Soutenance intermédiaire
|-

!scope="row"| 1
| [[Test d'infrastructures avec NixOS]]
| HUMBERT CORENTIN, MINIER MANCINI TITOUAN (Chef de projet), SUEUR CORENTIN (Scrum master)
| Olivier RICHARD et Quentin GUILLETEAU
| [[Test Infrastructures NixOS 2021-2022|Fiche de suivi]]
| [[Rapport Test Infrastructures NixOS 2021-2022|Rapport final]] - [[Media:Presentation_finale_NixOs.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:Presentation_mi_parcours_NixOs.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:English_Poster_NixOS.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://git/xxx Dépot Git]
| [[Media:Presentation_mi_parcours_NixOs.pdf|Presentation intermédiaire]]
|-

!scope="row"| 2
| [[Plan dynamique d’un appartement connecté]]
| GRANGER OSCAR (Chef de projet), NOERIE SOPHIE, SARRE MARGAUX, SALMON AMAD, TEYSSIER THEO (Scrum master)
| Sybille CAFFIAU
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:Presentation_intermediaire_DOMUS.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:Poster-xxx-en.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://git/xxx Dépot Git]
| [[Media:Presentation_intermediaire_DOMUS.pdf|Presentation intermédiaire]]
|-

!scope="row"| 3
| [[Suivi de troupeaux (ovins, bovins) en zone montagneuse avec un réseau LoRaWAN : expérimentation dans la Matheysine]]
| GITTON ANTOINE, MALOD VICTOR, MUTEL MATHIS
| Fabrice FOREST
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:INFO5_AgriConnect_presentation_miparcours.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:Poster-xxx-en.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://git/xxx Dépot Git]
| [[Media:xxx.pdf|Presentation intermédiaire]]
|-

!scope="row"| 4
| [[FitSize]]
| GEITNER TEVA , GONZALEZ JULES, PARA YAEL
| Fidèle Eya'a
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:PrésentationFitSize.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:Poster-xxx-en.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://git/xxx Dépot Git]
| [[Media:PrésentationFitSize.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 5
| [[GenderedNews]]
| AGUIAR MATHILDE (Chef de projet), HAJJI OUMAIMA (SCRUM Master), SIDIBE ROKIATOU DITE ROSE
| François PORTET, Gilles BASTIN, Ange RICHARD
| [[PROJET-INFO5 2022 GenderedNews|Fiche de suivi]]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:flyer_genderednews.pdf|Flyer]] - [[Media: Soutenance_interm_genderednews.pdf|Presentation de mi-parcours]] - [[Media:Poster-genderednews-fr.pdf|Poster FR]] - [[Media:Poster-genderednews-en.pdf|Poster EN]] - [[Media: Pitch_genderednews.pdf | Pitch 180 secondes]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/getalp/genderednews Dépot Git]
| [[Media: Soutenance_interm_genderednews.pdf|Presentation intermédiaire]]
|-

!scope="row"| 6
| [[Système d'analyse de traces sportives]]
| HERQUE ERIC (Scrum Master), VACHERIAS GUILLAUME (Chef de projet)
| Vivien QUEMA
| [[PROJET-INFO5 2022 Systeme d'analyse de traces sportive fiche suivis | Fiche de suivi]]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:Presentation_mi_parcours_systeme_analyse_trace_sportive.pdf|Presentation de mi-parcours]]- [[Media:Poster_systeme_analyse_trace_sportive.pdf|Poster FR]] - [[Media:Poster_systeme_analyse_trace_sportive.pdf|Poster EN]] - [[PROJET-INFO5 2022 Systeme d'analyse de traces sportive pitch | Pitch 180 secondes]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/vacherig/systeme-analyse-de-traces-sportives Dépot Git]
| [[Media:Presentation_mi_parcours_systeme_analyse_trace_sportive.pdf|Presentation intermédiaire]]
|-

!scope="row"| 7
| [[Qualité de l'Air et Santé des Populations]]
| BAUDEUR BERTRAND (Scrum Master), MERTENS GILLES (Chef)
| Marie-Laure AIX
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:Presentation_mi_parcours_qualite_air_baudeur_mertens.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:Poster-xxx-en.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://github.com/Air-Quality-LoRa Dépot Git]
| [[Media:Presentation_mi_parcours_qualite_air_baudeur_mertens.pdf|Presentation intermédiaire]]
|-

!scope="row"| 8
| [[Artiphonie(saison 3)]] extension de la [[Artiphonie (saison 2)]]
| BUISINE JULIEN (Chef de Projet), ELHADJI TCHIAMBOU SAMI, LAMBERT DAPHNE (Scrum Master), LAMBERT PAUL
| Olivier Richard
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media: Artiphonie-Presentation_mi-parcours.pdf|Presentation intermédiaire]] - [[Media:Poster_Artiphonie_FR.pdf|Poster FR]] - [[Media:Poster_Artiphonie_-_LAMBERT,_BUISINE,_ELHADJI_TCHIAMBOU.pdf|Poster EN]] - [[Media: Pitch_Artiphonie_2022.pdf|Pitch Artiphonie 2022]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/artiphonie/projet-info5-21-22 Dépot Git]
| [[Media: Artiphonie-Presentation_mi-parcours.pdf|Presentation intermédiaire]]
|-

!scope="row"| 9
| [[Quark Project]]
| CHALOYARD LUCAS, EL YANDOUZI ELIAS
| Olivier Gruber
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:Soutenance QuarkV3.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:Poster-xxx-en.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://git/xxx Dépot Git]
| [[Media:Soutenance QuarkV3.pdf|Presentation intermédiaire]]
|-

!scope="row"| 10
| [[Jorigine]]
| BLANQUET ANTOINE ('''Scrum Master'''), LANQUETIN ALEXIS ('''Chef de projet'''), MALECOT ETHAN, PRAT-CAPILLA HUGO
| Sylvain Delangue
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:Presentation_Projet_miparcours_S10.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:PosterJorigine2022_vfinal.pdf|Poster EN]] - [[Media:Pitch_Jorigine_grp10.pdf|Pitch en 180 secondes]]
| [https://git/xxx Dépot Git]
| [[Media:Presentation_Projet_miparcours_S10.pdf|Presentation intermédiaire]]
|-

!scope="row"| 11
| [[Contributions open source au projet EdCampus|EdCampus]]
| ANDRIEUX LIAM, COSOTTI KEVIN, DREZET LUCAS ('''Chef de projet'''), REGOUIN ROMAN ('''Scrum Master''')
| Anthony GEOURJON
| [XXXX Fiche]
| [[Rapport EDCampus 2021-2022|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [https://air.imag.fr/images/c/ca/Soutenance_interm%C3%A9diaire_-_EDCampus_2021-2022.pdf Presentation de mi-parcours] - [https://air.imag.fr/images/0/00/PosterFREDCampus20212022.pdf Poster FR] - [https://air.imag.fr/images/d/df/EDCampus_-_2021_2022.pdf Poster EN] - [https://air.imag.fr/images/d/d5/PitchEDCampus20212022.pdf Pitch]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/edcampus Dépot Git]
| [https://air.imag.fr/images/c/ca/Soutenance_interm%C3%A9diaire_-_EDCampus_2021-2022.pdf Presentation intermédiaire]
|-

!scope="row"| 12
| [[Contributions open source au projet LabnBook|LabnBook]]
| CIRSTEA PAUL, SOULARD ALEXANDRE (Chef de projet), TONDEUX EMILIE (Scrum master), YUNG KEVIN
| Anthony GEOURJON, Cédric DHAM
| [[PROJET-INFO5 2022 LabNbook|Fiche de suivi]]
| [https://github.com/AlexandreSoulard/Groupe-LabnBook/blob/main/rapportLabNbook.md Rapport final] - [[Media:LabnBook_Presentation_finale.pdf|Presentation finale FR]] - [[Media:LabNbook_flyer.pdf|Flyer]] - [[Media:LabnBook.pdf|Presentation de mi-parcours]] - [[Media:Poster_GroupLabnBook_Cirstea_Soulard_Tondeux_Yung.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes] - [https://drive.google.com/file/d/1eWU090ieX3dC8vweB4UKzwfu9E7jk1vI/view?usp=sharing Screencast]
| [https://github.com/AlexandreSoulard/Groupe-LabnBook Dépot Git]
| [[Media:LabnBook.pdf|Presentation intermédiaire]]
|-

!scope="row"| 13
| [[Green collect]]
| BARET DORIAN, CAMBUS QUENTIN (Chef de projet), JULIENNE MALONE, MALLEN GUILLAUME (Scrum master)
| Bernard TOURANCHEAU
| [XXXX Fiche]
| [https://github.com/GreenCollects/docs/blob/main/report/CR-Final-Report.md Rapport final] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [https://github.com/GreenCollects/docs/blob/main/soutenance/Soutenance%20de%20mi-parcours.pdf Presentation de mi-parcours] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:Poster-xxx-en.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://github.com/GreenCollects Dépot Git]
| [https://github.com/GreenCollects/docs/blob/main/soutenance/Soutenance%20de%20mi-parcours.pdf Presentation intermédiaire]
|-

|}

Sujets non choisis

# [[LoRaWAN Roaming]] avec [[Chirpstack]], [[TheThingStack]] et [[Actility]] pour le projet [https://gricad-gitlab.univ-grenoble-alpes.fr/thingsat/public/-/blob/master/cubesat_mission/README.md Thingsat]: Didier DONSEZ, Olivier ALPHAND.
# [[Contributions logicielles au projet RIOT OS pour le New Space]] : Francois-Xavier MOLINA, Olivier ALPHAND, Didier DONSEZ
# [[Réseaux social d'organisation de sortie (saison 2)]] refonte [[Réseaux social d'organisation de sortie]], Olivier Richard
# [[Experiment Process Management]], Olivier Richard
# [[Language Server for Visual Studio]]: Olivier Gruber
# ABANDONNé [[Réseau d'Alumni de formations]] (à confirmer), Gérard POLLIER ([https://disrupt-campus.univ-grenoble-alpes.fr/design-factory-grenoble/ Design Factory Grenoble])
# [[Evaluation du kit IA embarqué Wio Terminal]]: Louis CLOSSON, Didier DONSEZ (sous réserve de réception du matériel commandé)

Projets 2021-2022

2022-03-17T21:15:42Z

Titouan.Minier-Mancini: /* Affectations S10 */

<<[[Projets 2020-2021]] | [[Projets]] | [[Projets 2022-2023]]>>
=INFO=
==INFO3==

==INFO4==
===Projet Semestre S8===

Enseignants responsables : Olivier Richard

* Dates : Lundi après-midi, Mardi après-midi
* Lancement: 10 Janvier 2021 après midi
* Soutenance à mi-parcours: A définir
* Soutenance: A définir

* '''Evaluation à mi-parcours le lundi/mardi ???''': Format: 10min (5min de présentation 3 slides au plus, 5min de discussion). Cette évaluation sera prise en compte dans la note finale.

'''Consignes générales:'''

* '''Vous devez être pro-actifs !!!''': Si des points sont pas ou mals spécifiés, vous le faîtes et vous justifiez vos choix. Pour les problèmes techniques éventuels vous pouvez: creuser la question, contacter l'auteur du code si il y a lieu, écrire un rapport de bug ('''Attention:''' ca se prépare !), soumettre un patch/pull request, contacter l'enseignant ou la personne référente du projet.

* '''Vous devez maintenir une fiche de suivi de projet''': elle doit être mise à jour chaque semaine, elle rassemble les élements essentiels du projet, elle indique les évolutions du projet et présente sa feuille de route. '''Note:''' le nom de la fiche doit être composé du nom du projet et suffixé par info4_2021_2022. '''Cette fiche compte pour la note finale'''

* '''Votre code''' pour doit être hébergé sur le gitlab et à l'URL suivante https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22 , vous utiliserez votre compte UGA.

* Chaque projet doit avoir '''aux moins 2 dépôts git''':
** '''Un pour les documents''' demandés rapport, présentation de pré-soutenante, de soutenance, flyer. '''Il sera appelé documents.'''
** Un ou plusieurs pour le code, les tests, les évaluations, les preuves de concept, la ou les documentations afférentes.

* Les '''documents public doivent être rédigés en anglais (README, documentation, commentaires de code, nom de variables et de fonctions)'''. Le *rapport* sera aussi demandé en *anglais* (il fera la taille d'un rapport de TP). Les transparents des présentation peuvent être en anglais ou en francais, la soutenance sera taire en francais.

* '''La note obtenue''' tiendra compte du '''nombre et de la qualité des commits''' observé dans '''vos dépots git et la branche master''' (or depot documents). La qualité comprend l'intitulé du commit et son contenu. Les notes pourront être différentiées dans un groupe, il n'est pas acceptable de pas avoir de commit dans le(s) dépôt(s) du projet (or dépôt documents).

* Il est fortement conseillé de suivre un '''développement incrémental''' qui permette d'avoir à tout moment un démonstrateur à présenter, un projet peut être constituer d'une succession de '''démonstrateurs présentables séparément'''.

* Vous devez faire aussi des '''schémas d'architectures générales et/ou spéficiques, des diagrammes de séquence''', et autre documents de spécification si nécessaire. Ces documents vous serviront de base de discussion/brainstorming interne ainsi que dans vos différents documents (rapport, présentations, documentation). Ces schémas sont avant tout conceptuels et techniques.

===Propositions de projets S8===

* 1. [https://codimd.math.cnrs.fr/?next=%2Fs%2FB029qfT5Q Courriels à Suppression Programmée] : Michaël Périn
* 2. [[Firmwares open source pour une station de réception de satellites pour l’Internet des Objets isolés]], Didier DONSEZ.
* 3. [[Evaluation du toolkit AI de STM32 pour l'analyse de l'environnement sonore]] (Suite 2022), Didier DONSEZ.
* 4. [[Algorithmes de géolocalisation d’objets par TDOA (Time Difference of Arrival)]] (suite), Didier DONSEZ.
* 5. [[Dashboard pour Overwatch]] Olivier Richard
* 6. [[Application mobile d'enregistrements de noeuds IoT LoRaWAN dans plusieurs réseaux]] (Suite) : Didier DONSEZ
* 7. [[Bluetooth 5.1 Angle of Arrival based Indoor Localization]] (Suite) : Didier DONSEZ
* 8. Intégration de composants de mesures environnementales (eau, air, ...) pour le [[Contribution au projet STM32Python|projet STM32Python]] à destination des lycéens: Didier DONSEZ
* 9. [[Air Quality Station]] (Suite) : Didier DONSEZ
* 10. [[Floating Water Quality Station]] : Didier DONSEZ, Nicolas PALIX
* 12. [[Testeur de terrain pour réseaux LoRaWAN privés et publics (TTN, CampusIoT et Helium)]] (suite 2021), Didier DONSEZ.
* 13. [[Géolocalition Indoor en LoRa 2.4GHz]], Didier DONSEZ.
* 14. [[RealWorld avec Dioxus]] (Rust + web), Olivier Richard
* 15. Poursuite projet 20-21 [[Rust Engine | Executeur de tâche en Rust]], Olivier Richard
* 16. Poursuite projet 20-21 [[Retrocompute simulateur | RetroComputing]]: (vintage style) Coupler le simulateur Digital avec un simulateur de processeur 8bits, Olivier Richard
* 17. Poursuite projet 19-20 [[Portail pour gestionnaire de taches]](react, Typescript), Olivier Richard
* 18. [[Paquets NIX pour Polytech]], Olivier Richard
* 19. [[Mini compilateur C pour mini CPU]], Olivier Richard
* 20. Mode jeu en réseau (Wifi/Bluetooth) pour [[TanksOfFreedom]], Nicolas Palix

Non affecté
* xx. [[Bibliothèque de décodeurs standards et d'afficheurs Grafana pour objets connectés LoRaWAN]] : Didier DONSEZ
* xx. [[ASAC|Agriculture connectée]] en partenariat avec les projets collectifs IESE/MAT : Nicolas Palix
* xx. [[Faults In Linux]], Nicolas Palix

===Affectations===
{|class="wikitable alternance"
|+ Affectation des projets INFO4 21-22
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Enseignant(s)
!scope="col"| Fiche de suivi
!scope="col"| Documents
|-
!scope="row"| 1
| [https://air.imag.fr/index.php/Planned_Deletion_Emails Courriels à Suppression Programmée]
| CANIN CORENTIN,MONTEILLER JOSHUA,WAGNER SAMY
| Michaël PÉRIN
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/01/docs/-/blob/main/%20Courriels%20%C3%A0%20Suppression%20Programm%C3%A9e%20info4_2021_2022.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 2
| [https://air.imag.fr/index.php/Firmwares_open_source_pour_une_station_de_r%C3%A9ception_de_satellites_pour_l%E2%80%99Internet_des_Objets_isol%C3%A9s# Firmwares open source pour une station de réception de satellites pour l’Internet des Objets isolés]
| CARMONA DAMIAN,DA COSTA TOM,WOZNY PIERRE-RAPHAEL
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/02/docs/-/blob/main/Firmwares_open_source_pour_une_station_de_r%C3%A9ception_de_satellites_pour_l_Internet_des_Objets_isol%C3%A9s_info4_2021_2022.md# Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 3
| [https://air.imag.fr/index.php/Evaluation_du_toolkit_AI_de_STM32_pour_l%27analyse_de_l%27environnement_sonore Evaluation du toolkit AI de STM32 pour l'analyse de l'environnement sonore]
| BACH THOMAS,BARBE FLORENT,SIMO YOKAM GEORGES HARRISSO
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/03/docs/ Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:Midterm_presentation_3_2022.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 5
| [https://air.imag.fr/index.php/Dashboard_pour_Overwatch# Dashboard pour Overwatch]
| CAILLES MAXIME,REYGNER ETIENNE,VERRIER MARTIN
| Olivier RICHARD
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/05/docs/-/blob/main/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 6
| [[Application mobile d'enregistrements de noeuds IoT LoRaWAN dans plusieurs réseaux]]
| CHIOTTI MAEL,LAVIROTTE GAETAN,MOTTINO LORIS
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/06/docs/-/tree/main Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 8
| [https://air.imag.fr/index.php/Contribution_au_projet_STM32Python Intégration de composants de mesures environnementales (eau, air...) pour le projet STM32Python à destination des lycéens]
| GUIRGUIS MIRETTE,HADIBY CHEMSSEDDINE,MOHSEN HACHEM
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/08/docs/-/blob/main/README.md#lorawan Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 10
| [[Floating Water Quality Station]]
| BRETON EMERIC,FAGHLOUMI AYMAN,VIALLET CAMILLE
| Didier DONSEZ, Nicolas PALIX
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/10/docs/-/blob/main/info4_2021_2022_Fiche_suivi_projet.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/10/docs/-/blob/main/Soutenance%20mi-parcours%20Projet_S8.pdf Presentation de mi-parcours]
|-
!scope="row"| 13
| [https://air.imag.fr/index.php/G%C3%A9olocalition_Indoor_en_LoRa_2.4GHz Géolocalition Indoor en LoRa 2.4GHz]
| BERNERD CLARA,JARDIN BAPTISTE,NGUYEN JUSTIN
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/13/docs/-/blob/main/Fiche_de_suivi.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 14
| [[RealWorld avec Dioxus]]
| IFAKIREN SAMI,MONTHE DJEUMOU BRICE,NGUYEN CLEMEN
| Olivier RICHARD
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/14/docs Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 15
| [https://air.imag.fr/index.php/Rust_Engine Exécuteur de tâche en Rust]
| CHAPPAZ FLORIAN,DE OLIVEIRA VALENTIN,KURKLU FIKRET
| Olivier RICHARD
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/15/docs/-/blob/main/Rust_Engine_info4_2021_2022.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/15/docs/-/blob/main/rust_engine_mid_presentation.pdf Presentation de mi-parcours]
|-
!scope="row"| 17
| [https://air.imag.fr/index.php/Portail_pour_gestionnaire_de_taches Portail Pour Gestionnaire De Taches]
| KACHA TOM,MAHAMAN NOURY ABDOURAHAMANE,MEIGNEN HUGO,ZHANG KEMING
| Olivier RICHARD
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/17/docs/-/blob/main/Fiche_De_Suivi_17.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/17/docs/-/blob/main/Pr%C3%A9sentation-mi-parcours.pdf Presentation de mi-parcours]
|-
!scope="row"| 18
| [[Paquets NIX pour Polytech]]
| CONJARD SAMUEL,FODOR GERGELY,PELISSE-VERDOUX CYPRIEN
| Olivier RICHARD
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/18/docs/-/blob/master/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 19
| [[Mini compilateur C pour mini CPU]]
| CAPET THEO,POITEVIN EVE,ROYET JULIAN
| Olivier Richard
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/19/docs/-/blob/main/C_compiler_for_MCPU_info4_2021_2022.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 20
| Mode jeu en réseau pour [[TanksOfFreedom]],
| ABECASSIS THOMAS,FOURNIER THOMAS,ZAFFUTO LUCA
| Nicolas Palix
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/20/docs/-/blob/main/fiche_de_suivi.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
|}

==INFO5==
===Projet IoT S9===
Enseignants responsables : Bernard Tourancheau

Calendrier: Octobre à Décembre 2021. Soutenance 24 Janvier 2022.

{|class="wikitable alternance"
|+ Choix des projet des projets INFO5 Réseaux 21-22
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Documents
!scope="col"| Github/Trello
|-
!scope="row"| 1
| [[Réseau de capteur de dichlorométhane]]
| Dorian BARET - Malone JULIENNE - Quentin CAMBUS
| [https://lesjoiesducode.fr/quand-notre-revue-de-sprint-se-passe-nickel Fiche]
| [https://github.com/Cambus-Quentin/DichloWan2021/blob/main/README.md git]
|-
!scope="row"| 2
| [[Création d'un système pour localiser les élèves lors de courses d'orientation]]
| Antoine Gitton, Gilles Mertens, Bertrand Baudeur
| [[Media:2021_2022_INFO5_IOT_Orientation_spec.pdf|Spécification paquets LoRa]]
| [[Media:2021_2022_INFO5_IOT_Orientation_backend.zip|Souces back-end]] - [[Media:2021_2022_INFO5_IOT_Orientation_carte.zip|Souces carte]]
|-
!scope="row"| 3
| [[Harnais animalier permettant de suivre notre animal domestique]]
| Sami ELHADJI TCHIAMBOU, Corentin HUMBERT, Paul LAMBERT, Hugo PRAT CAPILLA
| [[Media:PSP_Presentation.pdf|Présentation finale]]
| [https://github.com/Bicorpro Organisation GitHub]
|-
!scope="row"| 4
| [[Géolocalisation et suivi des transports en commun]]
| Liam ANDRIEUX, Lucas DREZET, Roman REGOUIN
|
| [https://github.com/2021-2022-IoT-INFO5-G4 Organisation GitHub]
|-
!scope="row"| 5
| [[Tracking des déplacements de joueurs sur un terrain]]
| Elias EL YANDOUZI, Lucas CHALOYARD
| [[Media:IOT_Presentation.pdf|Présentation finale]]
| [https://github.com/Indoor-Shadow/ble-experiment Github Repo]
|-
!scope="row"| 6
| [[Beer Pong connecté]]
| Yael PARA, Théo TEYSSIER, Victor MALOD, Alexis LANQUETIN
| [[Media:BeerPong_Presentation.pdf|Présentation finale]]
| [https://github.com/McReaper/BeerPongLora Gitub Repo]
|}

Exposés points techniques 10' - questions 5'
* Nom Sujet
* ??? Python
* ??? MQTT
* ??? COAP
* 26/11/2021 - Elias El Yandouzi - Les différentes techniques de virtualisation

===Projet Semestre S10===

Enseignant responsable : [[user:Donsez|Didier Donsez]]

Convention des projets tutorés externes : Elise Didier.

Calendrier: 27/01 (8H30-12H00) au 18/03.

Séances de Management de projets innovants: A voir dessus.

Réunion de présentation et choix des sujets: 27/01 (8H30-12H00) en salle Polygone P206 (voir ADE)

Démarrage : 27/01

Soutenance à mi-parcours (à définir) : ??/02/2021 13H30-17H30 en distantiel (15 minutes par équipe).

Soutenance finale : 18/03/2021 (8H30-12H00 et 13H30-17H00). 30 minutes par équipe, questions/réponses et démonstration incluse. Prière de rapporter au fablab le matériel emprunté juste après votre soutenance.

====Séances MPI====

Voir ADE qui fait foi).

<pre>

</pre>

==== Soutenance intermédiaire S10 ====
Date: 18/02 Matin. Distantiel (sur Zoom). Créneaux de 10 minutes.

L'objectif de la soutenance intermédiaire est de vérifier si l'équipe projet est en bon ordre de marche

L'équipe présentera en 5-6 transparents en 7 minutes.
* les équipiers et leurs rôles
* le contexte, le sujet et l'objectif du projet
* l'architecture du systèmes à réaliser
* les technologies utilisées
* le plan de travail (backlog, planning, ce qui est fait, ce qu'il reste à faire ...)
* les difficultés (s'il y a)

Prévoyez du temps pour les questions-réponses (3 minutes max).

Respectez bien les créneaux indiqués (par respect pour les autres équipes) et soyez présents un peu en avance dans la salle d'attente.

La présence des porteurs n'est pas obligatoire.

==== Soutenance finale S10 ====
Date provisoire: 18/03/2022 (8H30-12H00 et 13H30-17H00).

'''La présence du(des) porteur(s) est obligatoire. Pensez à les prévenir bien à l'avance'''

Durée: 30 minutes par équipe: présentation, questions/réponses et démonstration incluse.

Les documents devront être en ligne sur le wiki (colonne Documents) la veille (ie avant le 17/03/2021 23:59:59 CET).

La présentation est constituée des chapitres suivants:
* Rappel du sujet/besoin et cahier des charges
* Technologies employées
* Architecture techniques
* Réalisations techniques
* Gestion de projet (méthode, planning prévisionnel et effectif, gestion des risques, rôles des membres ...)
* Outils (collaboration, CD/CI ...)
* Métriques logiciels : lignes de code, langages, performance, temps ingénieur (d'après vos journaux), la répartition des lignes de code et des commits en pourcentage entre les membres du projet ...)
* Conclusion (Retour d'expérience)
* Transparent expliquant la démonstration

L'ensemble des documents doit être accessible depuis le tableau ci-dessus et dans chaque fiche de suivi.

Le screencast (réalisé lors de la dernière répétition) sera rendu disponible via un partage caché (wetransfer, google drive …) dont le lien sera ajouté dans le devoir idoine sur Moodle et également envoyé par mail à votre tuteur.

Le rapport final contient les mêmes chapitres que la présentation ainsi qu'un glossaire et une bibliographie. Le rapport ne doit pas dépasser 15 pages (schémas et figures compris). Vous pourrez référencer les autres documents que vous avez produits au cours du projet (spécifications détaillées, algorithmes, conception d'écrans ...).

Le rapport final est au format Markdown et doit être placé dans un des dépôts Git de votre groupe/organisation.

NB: le rapport technique listé dans la colonne Documents contient tout ce qui ne tient pas dans les 15 pages du rapport final : cahier des charges, diagrammes UML, enquêtes utilisateurs design UI, API, technologies employées (détail), plan de tests, term of services, conformance RPGD, audits/diagnostiques sécurité, MTBR, rapport de vulnérabilité, plan de charge, rapports de charge, manuel d'installation … : ça dépend un peu de la nature de votre projet.

Conseil : 30 minutes c'est très court alors répétez la soutenance auparavant ! Prévoyez des transparents supplémentaires en annexe pour répondre aux questions.

'''Prière de rapporter au fablab le matériel emprunté juste après votre soutenance'''.

==== Affectations S10====
{|class="wikitable alternance"
|+ Affectation des projets INFO5 2021-2022
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Porteur(s)
!scope="col"| Fiche de suivi
!scope="col"| Documents
!scope="col"| Dépôt Git
!scope="col"| Soutenance intermédiaire
|-

!scope="row"| 1
| [[Test d'infrastructures avec NixOS]]
| HUMBERT CORENTIN, MINIER MANCINI TITOUAN (Chef de projet), SUEUR CORENTIN (Scrum master)
| Olivier RICHARD et Quentin GUILLETEAU
| [XXXX Fiche]
| [[Rapport Test Infrastructures NixOS 2021-2022|Rapport final]] - [[Media:Presentation_finale_NixOs.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:Presentation_mi_parcours_NixOs.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:English_Poster_NixOS.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://git/xxx Dépot Git]
| [[Media:Presentation_mi_parcours_NixOs.pdf|Presentation intermédiaire]]
|-

!scope="row"| 2
| [[Plan dynamique d’un appartement connecté]]
| GRANGER OSCAR (Chef de projet), NOERIE SOPHIE, SARRE MARGAUX, SALMON AMAD, TEYSSIER THEO (Scrum master)
| Sybille CAFFIAU
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:Presentation_intermediaire_DOMUS.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:Poster-xxx-en.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://git/xxx Dépot Git]
| [[Media:Presentation_intermediaire_DOMUS.pdf|Presentation intermédiaire]]
|-

!scope="row"| 3
| [[Suivi de troupeaux (ovins, bovins) en zone montagneuse avec un réseau LoRaWAN : expérimentation dans la Matheysine]]
| GITTON ANTOINE, MALOD VICTOR, MUTEL MATHIS
| Fabrice FOREST
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:INFO5_AgriConnect_presentation_miparcours.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:Poster-xxx-en.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://git/xxx Dépot Git]
| [[Media:xxx.pdf|Presentation intermédiaire]]
|-

!scope="row"| 4
| [[FitSize]]
| GEITNER TEVA , GONZALEZ JULES, PARA YAEL
| Fidèle Eya'a
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:PrésentationFitSize.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:Poster-xxx-en.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://git/xxx Dépot Git]
| [[Media:PrésentationFitSize.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 5
| [[GenderedNews]]
| AGUIAR MATHILDE (Chef de projet), HAJJI OUMAIMA (SCRUM Master), SIDIBE ROKIATOU DITE ROSE
| François PORTET, Gilles BASTIN, Ange RICHARD
| [[PROJET-INFO5 2022 GenderedNews|Fiche de suivi]]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:flyer_genderednews.pdf|Flyer]] - [[Media: Soutenance_interm_genderednews.pdf|Presentation de mi-parcours]] - [[Media:Poster-genderednews-fr.pdf|Poster FR]] - [[Media:Poster-genderednews-en.pdf|Poster EN]] - [[Media: Pitch_genderednews.pdf | Pitch 180 secondes]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/getalp/genderednews Dépot Git]
| [[Media: Soutenance_interm_genderednews.pdf|Presentation intermédiaire]]
|-

!scope="row"| 6
| [[Système d'analyse de traces sportives]]
| HERQUE ERIC (Scrum Master), VACHERIAS GUILLAUME (Chef de projet)
| Vivien QUEMA
| [[PROJET-INFO5 2022 Systeme d'analyse de traces sportive fiche suivis | Fiche de suivi]]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:Presentation_mi_parcours_systeme_analyse_trace_sportive.pdf|Presentation de mi-parcours]]- [[Media:Poster_systeme_analyse_trace_sportive.pdf|Poster FR]] - [[Media:Poster_systeme_analyse_trace_sportive.pdf|Poster EN]] - [[PROJET-INFO5 2022 Systeme d'analyse de traces sportive pitch | Pitch 180 secondes]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/vacherig/systeme-analyse-de-traces-sportives Dépot Git]
| [[Media:Presentation_mi_parcours_systeme_analyse_trace_sportive.pdf|Presentation intermédiaire]]
|-

!scope="row"| 7
| [[Qualité de l'Air et Santé des Populations]]
| BAUDEUR BERTRAND (Scrum Master), MERTENS GILLES (Chef)
| Marie-Laure AIX
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:Presentation_mi_parcours_qualite_air_baudeur_mertens.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:Poster-xxx-en.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://github.com/Air-Quality-LoRa Dépot Git]
| [[Media:Presentation_mi_parcours_qualite_air_baudeur_mertens.pdf|Presentation intermédiaire]]
|-

!scope="row"| 8
| [[Artiphonie(saison 3)]] extension de la [[Artiphonie (saison 2)]]
| BUISINE JULIEN (Chef de Projet), ELHADJI TCHIAMBOU SAMI, LAMBERT DAPHNE (Scrum Master), LAMBERT PAUL
| Olivier Richard
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media: Artiphonie-Presentation_mi-parcours.pdf|Presentation intermédiaire]] - [[Media:Poster_Artiphonie_FR.pdf|Poster FR]] - [[Media:Poster_Artiphonie_-_LAMBERT,_BUISINE,_ELHADJI_TCHIAMBOU.pdf|Poster EN]] - [[Media: Pitch_Artiphonie_2022.pdf|Pitch Artiphonie 2022]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/artiphonie/projet-info5-21-22 Dépot Git]
| [[Media: Artiphonie-Presentation_mi-parcours.pdf|Presentation intermédiaire]]
|-

!scope="row"| 9
| [[Quark Project]]
| CHALOYARD LUCAS, EL YANDOUZI ELIAS
| Olivier Gruber
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:Soutenance QuarkV3.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:Poster-xxx-en.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://git/xxx Dépot Git]
| [[Media:Soutenance QuarkV3.pdf|Presentation intermédiaire]]
|-

!scope="row"| 10
| [[Jorigine]]
| BLANQUET ANTOINE ('''Scrum Master'''), LANQUETIN ALEXIS ('''Chef de projet'''), MALECOT ETHAN, PRAT-CAPILLA HUGO
| Sylvain Delangue
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:Presentation_Projet_miparcours_S10.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:PosterJorigine2022_vfinal.pdf|Poster EN]] - [[Media:Pitch_Jorigine_grp10.pdf|Pitch en 180 secondes]]
| [https://git/xxx Dépot Git]
| [[Media:Presentation_Projet_miparcours_S10.pdf|Presentation intermédiaire]]
|-

!scope="row"| 11
| [[Contributions open source au projet EdCampus|EdCampus]]
| ANDRIEUX LIAM, COSOTTI KEVIN, DREZET LUCAS ('''Chef de projet'''), REGOUIN ROMAN ('''Scrum Master''')
| Anthony GEOURJON
| [XXXX Fiche]
| [[Rapport EDCampus 2021-2022|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [https://air.imag.fr/images/c/ca/Soutenance_interm%C3%A9diaire_-_EDCampus_2021-2022.pdf Presentation de mi-parcours] - [https://air.imag.fr/images/0/00/PosterFREDCampus20212022.pdf Poster FR] - [https://air.imag.fr/images/d/df/EDCampus_-_2021_2022.pdf Poster EN] - [https://air.imag.fr/images/d/d5/PitchEDCampus20212022.pdf Pitch]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/edcampus Dépot Git]
| [https://air.imag.fr/images/c/ca/Soutenance_interm%C3%A9diaire_-_EDCampus_2021-2022.pdf Presentation intermédiaire]
|-

!scope="row"| 12
| [[Contributions open source au projet LabnBook|LabnBook]]
| CIRSTEA PAUL, SOULARD ALEXANDRE (Chef de projet), TONDEUX EMILIE (Scrum master), YUNG KEVIN
| Anthony GEOURJON, Cédric DHAM
| [[PROJET-INFO5 2022 LabNbook|Fiche de suivi]]
| [https://github.com/AlexandreSoulard/Groupe-LabnBook/blob/main/rapportLabNbook.md Rapport final] - [[Media:LabnBook_Presentation_finale.pdf|Presentation finale FR]] - [[Media:LabNbook_flyer.pdf|Flyer]] - [[Media:LabnBook.pdf|Presentation de mi-parcours]] - [[Media:Poster_GroupLabnBook_Cirstea_Soulard_Tondeux_Yung.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes] - [https://drive.google.com/file/d/1eWU090ieX3dC8vweB4UKzwfu9E7jk1vI/view?usp=sharing Screencast]
| [https://github.com/AlexandreSoulard/Groupe-LabnBook Dépot Git]
| [[Media:LabnBook.pdf|Presentation intermédiaire]]
|-

!scope="row"| 13
| [[Green collect]]
| BARET DORIAN, CAMBUS QUENTIN (Chef de projet), JULIENNE MALONE, MALLEN GUILLAUME (Scrum master)
| Bernard TOURANCHEAU
| [XXXX Fiche]
| [https://github.com/GreenCollects/docs/blob/main/report/CR-Final-Report.md Rapport final] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [https://github.com/GreenCollects/docs/blob/main/soutenance/Soutenance%20de%20mi-parcours.pdf Presentation de mi-parcours] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:Poster-xxx-en.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://github.com/GreenCollects Dépot Git]
| [https://github.com/GreenCollects/docs/blob/main/soutenance/Soutenance%20de%20mi-parcours.pdf Presentation intermédiaire]
|-

|}

Sujets non choisis

# [[LoRaWAN Roaming]] avec [[Chirpstack]], [[TheThingStack]] et [[Actility]] pour le projet [https://gricad-gitlab.univ-grenoble-alpes.fr/thingsat/public/-/blob/master/cubesat_mission/README.md Thingsat]: Didier DONSEZ, Olivier ALPHAND.
# [[Contributions logicielles au projet RIOT OS pour le New Space]] : Francois-Xavier MOLINA, Olivier ALPHAND, Didier DONSEZ
# [[Réseaux social d'organisation de sortie (saison 2)]] refonte [[Réseaux social d'organisation de sortie]], Olivier Richard
# [[Experiment Process Management]], Olivier Richard
# [[Language Server for Visual Studio]]: Olivier Gruber
# ABANDONNé [[Réseau d'Alumni de formations]] (à confirmer), Gérard POLLIER ([https://disrupt-campus.univ-grenoble-alpes.fr/design-factory-grenoble/ Design Factory Grenoble])
# [[Evaluation du kit IA embarqué Wio Terminal]]: Louis CLOSSON, Didier DONSEZ (sous réserve de réception du matériel commandé)

File:Presentation finale NixOs.pdf

2022-03-17T21:14:47Z

Titouan.Minier-Mancini:

File:Nixos-hadoop-architecture-2.png

2022-03-17T21:02:19Z

Titouan.Minier-Mancini: Titouan.Minier-Mancini uploaded a new version of File:Nixos-hadoop-architecture-2.png

File:Nixos-hadoop-architecture-2.png

2022-03-17T20:59:57Z

Titouan.Minier-Mancini:

File:Nixos-hadoop-architecture-1.png

2022-03-17T20:59:44Z

Titouan.Minier-Mancini:

File:Nixos-elk-architecture.png

2022-03-17T20:58:23Z

Titouan.Minier-Mancini:

File:Nixos-kubernetes-architecture.png

2022-03-17T20:57:29Z

Titouan.Minier-Mancini:

Rapport Test Infrastructures NixOS 2021-2022

2022-03-17T20:56:07Z

Titouan.Minier-Mancini: Created page with "=Rappel du sujet et cahier des charges= L’objectif est d’expérimenter et de manipuler une technologie récente : NixOS et le projet de recherche NixOS-Compose. Nix est u..."

=Rappel du sujet et cahier des charges=

L’objectif est d’expérimenter et de manipuler une technologie récente : NixOS et le projet de recherche NixOS-Compose. Nix est un outil de gestion de paquets (bibliothèques, morceau logiciel offrant certaines fonctionnalités), et NixOS est un système d'exploitation Linux qui utilise Nix dans son architecture. Nous parlerons plus en détails des différentes technologiques manipulées dans la prochaine partie.

Nos expérimentations ont consistées à déployer trois projets différents : Kubernetes, ELK et Hadoop en utilisant l'outil NixOS-Compose. La partie la plus importante n'étant pas de déployer une version aboutie et complête pour chacun de projets mais de documenter nos expériences pour fournir des retours utilisateurs permettant l'amélioration de NixOS-Compose.

=Technologies employées=

==Nix==

Nix est un gestionnaire de paquets et un langage fonctionnel qui se différencie de l'approche classique avec sa grande reproductibilité qu'il trouve incompatible avec le Filesystem Hierarchy Standard. Il dénonce l'enfer des dépendances que l'on retrouve avec cette approche où l'on ne peut pas déterminer les versions utilisées. Nix repose sur son store, où il stocke toutes les dérivations pour chaque paquet. Ces dérivations contiennent des informations sur toutes les dépendances (d'autres dérivations) et les instructions de build. Le nom de la dérivation indique le nom du paquet et un hash qui la rend unique mais surtout qui l'identifie : une même dérivation produira toujours la même sortie.

Avec cette approche, Nix permet plusieurs choses, notamment :
* La reproductibilité due au déterminisme des dérivations
* La possibilité d'utiliser plusieurs versions d'un même paquet en parallèle
* Comme le nom de la dérivation l'identifie, il est possible de mettre en cache la sortie et la récupérer sans avoir à la reconstruire

Nixpkgs est un répertoire en ligne contenant de nombreux paquets (80 000 actuellement) construits à partir de dérivations fournies par la communauté et accessibles à tous.

==NixOS==

NixOS est une distribution GNU/Linux reposant sur Nix en tant que gestionnaire de paquets mais également de gestionnaire de configuration. L'ensemble du système et toutes les configurations sont considérés comme des dérivations. Cela permet entre autres de faire des restorations du système à des versions précédentes simplement, chaque modification du système occasionne la création d'une nouvelle version atomique. Par ailleurs, le système d'exploitation hérite ainsi de la propriété déterministe et reproductible que Nix offre.

NixOS-test est une librairie de test qui permet, à partir d'un ensemble de fichiers de configuration Nix, de fournir une interface python pour manipuler ces configurations sur une/des machines virtuelles avec QEMU.

==NixOS-Compose==

NixOS-Compose est un projet de l’équipe Datamove qui étend l’utilisation de NixOS vers d’autres supports que les machines virtuelles, comme notamment la plateforme Grid'5000 et des solutions de conteneurs comme Docker.

==Kubernetes==

Kubernetes est un orchestrateur de conteneurs permettant de déployer, mettre à l'échelle et surveiller des applications conteneurisées sur un cluster de machines. Développé en Go et rendu open source en 2015 par Google inspiré de leur solution privée Borg, Kubernetes est maintenant l'outil central du monde du DevOps dans l'industrie. Il apporte une couche d'abstraction au dessus d'un datacenter, dont la mise en place a également été facilitée par le cloud, pour fournir une plateforme de déploiement fortement disponible aux développeurs. Kubernetes dispose également d'un large écosystème d'outils et plugins améliorant différents aspects de son utilisation : routage, monitoring, sécurité, gitops, déploiements (vert/bleu, canary...), serverless etc.

En cette qualité, Kubernetes est une plateforme de choix dans le cadre d'expériences nécessitant notamment un certain nombre de services ou applications, comme dans le cas d'architectures microservices par exemple. De plus, malgré ses nombreux atouts, Kubernetes est une solution souvent difficile et longue à mettre initialement en place pour cause d'une configuration complexe liée à l'architecture microservice de la plateforme elle-même. (Il faut reconnaître qu'avec le cloud il est maintenant très simple de déployer un cluster Kubernetes, Terraform est notamment un concurrent potentiel de NixOS-Compose)

Dans le cadre de notre projet, être en mesure de fournir un cluster Kubernetes de la taille voulue, simplement, rapidemment et de manière reproductible, est un objectif très intéressant, non seulement pour l'aspect apprentissage mais également pour son utilisation dans le contextes d'expériences scientifiques avec NixOS-Compose. Kubernetes est en lui même un solution qui permet une forte reproductibilité au niveau des déploiements internes, mais c'est la phase de déploiement des machines et de bootstrap du cluster qui manque cette qualité, et c'est là que nous nous positionnons.

==ELK==

"ELK" est l'acronyme de trois projets open source : Elasticsearch, Logstash et Kibana.

===Elasticsearch===

Elasticsearch est un outil de recherche et d'analyse de données fonctionnant de manière distribuée et basé sur [Apache Lucene](https://lucene.apache.org/). Créé par Shay Banon en 2004, au fil des années, Elasticsearch n'a cessé d'évoluer et aujourd'hui c'est l'outil de référence pour réaliser une recherche performante sur une large quantité de données.

Technologiquement parlant, il s'agit d'une base de données programmée en Java et spécialisée dans la recherche et l'indexation de documents. Si Elasticsearch est aussi performant c'est grâce à son fonctionnement en mode distribué. La tâche de recherche est exécutée en parallèle par plusieurs nœuds Elasticsearch, ce qui améliore la réactivité du système. Elasticsearch a aussi la force d'être facilement configurable et mis à l'échelle.

===Logstash===

Logstash est un outil écrit en Java et en Ruby permettant de **centraliser des traces** provenant de plusieurs systèmes, de les analyser et de les stocker. Conceptuellement, Logstash peut être vu comme un "pipe" où les données rentrent d'un bout, et sont traitées avant de ressortir de l'autre bout. Logstash est plus qu'un simple "pipe" puisqu'il peut prendre une multitude de sources différentes en entrées et renvoyées les données traitées vers différentes sorties. Il sert généralement à filtrer/analyser des messages avant de les envoyer à Elasticsearch qui va, lui, se charger de les stocker et de les indexer.

===Kibana===

Kibana est un outil permettant la visualisation de données écrit en JavaScript est la dernière composante majeure de la stack ELK. Il est similaire à d'autres outils de visualisation tel que [Grafana](https://grafana.com/), mais a la particularité d'être spécialisé pour une utilisation au sein de la stack ELK. Le rôle de Kibana est donc de récupérer les données indexées par Elasticsearch et de les rendre visuellement exploitables pour un humain.

===Beats===

Bien que la stack ELK soit l'acronyme des trois projets majeurs dont nous avons parlé précédemment, ELK est consistué d'un autre projet nommé Beats. Il y a d'ailleurs quelques discussions autour du renommage de la stack ELK en stack BELK pour inclure le projet Beats. Beats est une plateforme réunissant une multitude de petits outils permettant d'expédier des données vers Logstash ou Elasticsearch. Chaque outil vise un type de données spécifiques. On retrouvera par exemple l'outil Filebeat pour l'expédition de traces systèmes, Metricbeat pour les métriques, Packetbeat pour le réseau ou encore Heartbeat pour le monitoring. Cette liste est non exhaustive, il existe plein d'autres beats, chacun spécialisé pour des données de nature différente.

==Hadoop==

Hadoop est un framework open source Java destiné à faciliter la création d'applications distribuées (au niveau du stockage des données et de leur traitement) et scalables permettant aux applications de travailler avec des milliers de nœuds et des masses importantes de données. Ainsi chaque nœud est constitué de machines standard regroupées en grappe. Hadoop fonctionne avec de nombreux modules ou services conçus selon l'idée que les pannes matérielles sont fréquentes et qu'en conséquence elles doivent être gérées automatiquement par le framework. Cet aspect de redondance n'est pas traité dans ce projet.

=Architectures techniques=

==Kubernetes==

L'architecture de Kubernetes est distribuée sous forme de microservices avec plusieurs composants, chacun responsable d'une certaine tâche pour contrôler le cluster et les applications qui y vivent. Tout d'abord, les composants sont à séparer en deux groupes: le control plane, tête pensante du cluster, et les composants des nodes, responsables de faire fonctionner les conteneurs. Une machine est dite nœud maître dès lors qu'elle est membre du control plane (elle exécute les composants du control plane, seule ou en communication avec les autres maîtres). Une machine peut à la fois être maître et exécuter des conteneurs (control plane et *Node*), ce n'est toutefois pas recommandé au vu de l'importance du rôle du control plane.

[[File:nixos-kubernetes-architecture.png|center]]

Source : https://kubernetes.io/docs/concepts/overview/components

===Control plane===

Le control plane est un ensemble de composants responsable du bon fonctionnement du cluster. Ces composants sont présents sur chaque nœud maître du cluster. Dans le cas d'un cluster à haute disponibilité (plusieurs maîtres), ces composants fonctionnent de manière distribuée, et nécessitent un load balancer.

Le composant principal est l'apiserver, qui est donc une API permettant la communication entre les différents composants. L'apiserver est le seul composant avec qui les autres composants communiquent. Ensuite le controller manager, regroupe les différents contrôleurs dont le rôle est de gérer les resources qui leur corresponde (le contrôleur des *Pod* veille au bon fonctionnement des Pod, pareil pour les ReplicasSet, Endpoint, Node...). Le scheduler est responsable de l'attribution des resources (machines) aux applications (Pod, Deployment...) selon les disponibilités et besoins. Enfin, etcd est une base de données distribuée de configuration qui conserve l'état du cluster. C'est une solution tiers et elle peut être exécutée sur un cluster à part des nœuds maître.

===Node===

Pour Kubernetes, un Node (ou nœud en français) est l'abstraction d'une machine (réelle ou virtuelle). Chaque machine représentant un Node doit faire tourner trois services: le kubelet, le kube-proxy et un environnement d'exécution de conteneurs.

Le kubelet est véritablement le responsable des conteneurs en pratique, il est le contremaître obéissant au control plane, chargé de faire appliquer ses directives. Le kubelet ordonne à l'environnement d'exécution de conteneurs et fait ses rapports de situation au control plane. Le kube-proxy est chargé de mettre en place les règles de réseau (iptables ou IPVS) pour veiller au bon fonctionnement notamment des Service et Endpoint. Enfin, l'environnement d'exécution de conteneurs peut être n'importe quel solution respectant la CRI (container runtime interface) comme containerd ou CRI-O.

Non-obligatoire mais également souvent présent est un plugin de CNI (container network interface) qui met en place le plan de réseau exigé par Kubernetes (à savoir un réseau où les Pod disposent d'une adresse IP et peuvent communiquer entre eux) à ne pas confondre avec le réseau connectant les machines entre elles. On peut citer notamment Calico, Weave et celui qui est utilisé dans notre projet est Flannel (moins puissant). Parmi les addons on retrouve également un serveur DNS (nécessaire au bon fonctionnement des Services), anciennement kube-dns et maintenant plutôt coredns.

==ELK==

En ce qui concerne ELK, il ne s'agit non pas d'un système ou d'un outil en lui-même mais de la collaboration d'une multitude d'outils open source ayant chacun leurs particularités et un fonctionnement qui leur est propre. Pour visualiser plus aisément l'intéraction entre les différentes composantes de la stack ELK, on pourra s'intéresser à l'exemple suivant:

[[File:nixos-elk-architecture.png|center]]

Source : https://fr.wikipedia.org/wiki/Logstash

Dans l'exemple ci-dessus, on distingue trois sources indépendantes: MediaWiki, des services Node.js et Hadoop. Chacune des trois sources envoie des données à une instance différente de Logstash. Les instances de Logstash ne communiquent pas entre elles, toutefois, une fois le traitement des données effectué, chaque instance envoie ses données à un nœud Elasticsearch. Dans le schéma ci-dessus, les trois nœuds font partie d'un même cluster, ce qui permet donc la mise en commun de l'intégralité des données pouvant ensuite être visualisées via Kibana.

==Hadoop==

Hadoop est un environement distribué de par son stockage mais également son traitement de données. C'est une suite de solution open source pour le big data. The goal is to instanciate the different kind of nodes from one of the two possible implementation below, and make them communicate to run a job on the cluster.

[[File:nixos-hadoop-architecture-1.png|center]]

[[File:nixos-hadoop-architecture-2.png|center]]

Source : https://www.geeksforgeeks.org/hadoop-introduction

=Réalisations techniques=

==Kubernetes==

L'expérience avec Kubernetes consiste avant tout à déployer un cluster Kubernetes fonctionnel, utilisable comme n'importe quel autre cluster. Pour cela nous nous reposons donc tout d'abord sur la dérivation de Kubernetes sur nixpkgs. Ensuite nous utilisons d'autres outils comme Helm et *Istio* pour enrichir l'expérience.

La dérivations de Kubernetes propose la version 1.21.6, avec certains aspects de configuration qui sont cependant déprécié (notamment au niveau des ports uti lisés et des flags devenus déconseillés) car non mis à jour depuis 4 ans. La configuration de cette dérivation peut se faire de deux manière: en précisant la configuration de tous les composants (cf. partie II), ou en précisant uniquement le rôle de la machine. Avec la première approche non pouvons avoir un contrôle complet sur la configuration alors que dans le second tout est plus abstrait. En revanche la deuxième manière est plus simple et plus claire. Nous avons opté pour la seconde en ajoutant un certain nombre d'options supplémentaires.

La composition de l'expérience commence avec la description des machines ainsi que leur rôle dans le cluster. Nous utilisons généralement un nœud maître et deux nœuds de travail, sachant qu'il n'est pas possible actuellement de déployer un cluster à haute disponibilité dont le bootstrap des certificats est automatisé dans le déploiement, autrement il faut le faire manuellement ce qui est hors de question dans le cadre d'un environnement reproductible.

Ensuite nous disposons d'une fonction pour générer la configuration des machines du cluster. Cette configuration contient donc le rôle du node mais également des ajustements sur les ports et addresses IP de certains composants pour permettre la bonne communication des composants entre eux.

Nous ajoutons également une machine supplémentaire hors-cluster, c'est une serveur NFS, une solution parmis d'autres pour fournir au cluster un moyen de créer des volumes (*PersistentVolume*) accessibles par tous les nœuds. Ce serveur est monté sur toutes les machines, ce qui permet à l'expérimentateur de soit utiliser des volumes NFS, soit des volumes locaux pour plus de simplicité.

Avec Istio nous pouvons suivre le guide d'exemple présent dans la documentation pour déployer une application microservice et vérifier le bon fonctionnement du cluster.

Cette composition est fonctionnelle pour la plateforme de nixos-test et nixos-test-driver, toutes deux reposant sur QEMU, et également sur Grid'5000 où elle dévoile son vrai potentielle car les machines sont réelles et véritablement utilisables pour administrer le cluster. Elle n'est pas fonctionnelle sur Docker pour des raisons propres à NixOS-Compose qui ne permettent pas de modifier les noms d'hôtes (/etc/hosts), ce qui empêche la dérivation de fonctionner correctement.

Certains éléments de bootstrap se révèlent être difficilement applicable lors du déploiement avec NixOS-Compose et nous reposons donc en partie sur un script d'initialisation du cluster. Ce script est créé dans la composition et accessible dans le path. Il redémarre les composants éventuellement échoués et affiche une commande à l'utilisateur permettant d'ajouter des machines au cluster, cette étape n'tant pas automatisable simplement (l'approche est la même que kubeadm).

==ELK==

Pour ce qui est de l'expérience ELK, une grande partie du temps a été passée à comprendre la stack ELK et ses différentes composantes. Pour réaliser une composition fonctionnelle via NixOS-Compose, nous nous sommes basés sur une composition pré-existante écrite pour NixOS-Tests. La composition a ensuite été modifiée de manière à fonctionner correctement pour les différents modes de déploiement (Docker, Grid'5000).

==Hadoop==

Un paquet hadoop existe deja et il s'agit principalement d'en faire sa configuration. Plusieurs configurations différentes ont été réalisées, une minimale afin de comprendre le fonctionnement général, puis une se servant de yarn afin de maitriser la multiplicité des nœuds de travail.

Dans la composition minimale nous avons pu mettre, comme le premier shéma de la partie précédente, créer un node de front (namenode) ainsi qu'un datanode fonctionnant avec le filesystem.

=Gestion de projet=

Ce projet relève en partie d’un travail de recherche au vu du manque de documentation, du développement toujours en cours de l’OS et de sa faible utilisation de la part de la communauté d’utilisateurs.

Une importante partie de ce projet repose sur la communication entre notre équipe et l’équipe Datamove pour recevoir des consignes et fournir des retours. Pour fluidifier ces échanges nous avons organisé des réunions régulières et mis en place des solutions de communication en permanence à travers des outils comme Telegram et Zoom pour les réunions.

Nous avons mis en place deux types de réunions : des réunions quotidiennes avec un membre de l’équipe Datamove et des réunions hebdomadaires en équipe complète. Les réunions quotidiennes servent principalement à partager l’avancement et exprimer des éventuels blocages. Les réunions hebdomadaires visent davantage à faire un point global et à définir les prochaines étapes.

==Planification==

Pour ce qui est de la planification, il nous paraissait essentiel pour un projet comme le nôtre dans lequel énormément de temps est alloué à l'apprentissage d'une technologie plutôt qu'à la production réelle de code de définir une roadmap.

Cette roadmap avait pour but de planifier nos actions sur l’ensemble de la durée du projet. Nous avons fait évoluer la roadmap au fur et à mesure de notre avancement réel. Celle-ci nous a permis non seulement de travailler avec un objectif en tête mais également de partager ces objectifs avec l’équipe Datamove.

==Organisation du travail==

Au commencement de projet, notre objectif à tous était de se former rapidement sur Nix afin de comprendre l'étendu des possibilités de l'outil NixOS-Compose et de commencer à le tester.

Notre première tâche a consisté à écrire une composition k3s compatible avec NixOS-Compose de manière à découvrir la puissance de l'outil.

Ensuite, nous sommes chacun parti sur un projet différent dans l'optique de fournir trois expériences utilisateurs distinctes. La répartition des projets était la suivante :
* Titouan Minier Mancini : Kubernetes
* Corentin Humbert : Stack ELK
* Corentin Sueur : Hadoop

Nous avons donc progressé chacun de notre côté sur nos projets respectifs tout en restant en contact constant de manière à éviter de passer trop temps bloqué sur une partie du projet. La communication a été impérative pour un tel projet au vu de sa complexité et du temps dont nous disposions pour le mener à terme.

==Suivi du travail==

En parallèle nous avons suivi la rédaction de carnets de route individuels où nous expliquons toutes nos actions dans la journée, avec un maximum de détails notamment sur les erreurs. L’objectif est de permettre aux membres de l’équipe Datamove de suivre notre avancée individuelle et d’aider sur les problèmes techniques éventuels. Ces carnet doivent permettre un maximum la reproductibilité des situations pour faciliter la correction.

=Outils de travail=

Au cours de notre projet, nous avons été amenés à utiliser de nombreux outils nous permettant d’échanger entre nous et avec l’équipe Datamove que ce soit pour poser des questions ou partager nos productions.

* Communication écrite/orale :
** Au sein du groupe : Discord
** Avec l’équipe Datamove : Telegram, BBB, Zoom
* Échanges d’informations :
** Google docs, CodiMD
* Stockage des documents et du code produit :
** Dépôt GitLab

=Métriques logiciels=

Ce projet ne rentre pas dans le cadre d'une production logicielle, la quantité de code produit est faible car le travail est avant tout un travail de compréhension et de recherche. Nous avons produit un fichier de composition pour chaque pile logicielle, ce qui correspond à une centaine de lignes chacune. Le temps était principalement accordé à l'essai, l'avancement à tâtons pour explorer les différentes options disponibles, et à la compréhension du fonctionnement de NixOS-Compose.

Nous avons tous travaillé 35 heures par semaine, à l'exception des première semaines en parallèle avec le projet ECOM où Titouan et Corention Humbert n'étaient plus disponibles qu'à hauteur de 21 à 28 heures par semaine.

=Conclusion=

Ce projet nous a avant tout permis de découvrir l'environnement Nix et la solution NixOS-Compose, qui promet d'être intéressante et un candidat potentiel à l'*Infrastructure as Code* de demain. L'approche est différente de ce que l'on peut rencontrer avec d'autres outils comme Terraform et il est enrichissant de s'y pencher pour élargir sa pensée.

Nous avons également pu travailler sur des piles logicielles que nous ne connaissions pas forcément, ce qui a aussi été très enrichissant. Nous avons appris à utiliser ces piles logicielles et à les configurer, ce qui est généralement le plus important pour ce genre de système. Nous avons appris ou réappris des technologies, et amélioré notre capacité à appréhender un système distribué, savoir d'où viennent les problèmes et comment les résoudre.

Les compositions que nous avons pu fournir à l'issue du projet sont très satisfaisantes. Elles sont fonctionnelles et permettent à d'autres utilisateurs d'appréhender la solution NixOS-Compose. Nous avons également fourni des tutoriels et explications avec ces compositions pour exprimer des retours utilisateur au projet NixOS-Compose, ce qui, nous espérons, permettra de mettre en valeur ce beau projet.

=Démonstration=

La démonstration que nous proposons est de présenter le déploiement de chacune des piles logicielles.

Projets 2021-2022

2022-03-17T20:33:29Z

Titouan.Minier-Mancini: /* Affectations S10 */

<<[[Projets 2020-2021]] | [[Projets]] | [[Projets 2022-2023]]>>
=INFO=
==INFO3==

==INFO4==
===Projet Semestre S8===

Enseignants responsables : Olivier Richard

* Dates : Lundi après-midi, Mardi après-midi
* Lancement: 10 Janvier 2021 après midi
* Soutenance à mi-parcours: A définir
* Soutenance: A définir

* '''Evaluation à mi-parcours le lundi/mardi ???''': Format: 10min (5min de présentation 3 slides au plus, 5min de discussion). Cette évaluation sera prise en compte dans la note finale.

'''Consignes générales:'''

* '''Vous devez être pro-actifs !!!''': Si des points sont pas ou mals spécifiés, vous le faîtes et vous justifiez vos choix. Pour les problèmes techniques éventuels vous pouvez: creuser la question, contacter l'auteur du code si il y a lieu, écrire un rapport de bug ('''Attention:''' ca se prépare !), soumettre un patch/pull request, contacter l'enseignant ou la personne référente du projet.

* '''Vous devez maintenir une fiche de suivi de projet''': elle doit être mise à jour chaque semaine, elle rassemble les élements essentiels du projet, elle indique les évolutions du projet et présente sa feuille de route. '''Note:''' le nom de la fiche doit être composé du nom du projet et suffixé par info4_2021_2022. '''Cette fiche compte pour la note finale'''

* '''Votre code''' pour doit être hébergé sur le gitlab et à l'URL suivante https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22 , vous utiliserez votre compte UGA.

* Chaque projet doit avoir '''aux moins 2 dépôts git''':
** '''Un pour les documents''' demandés rapport, présentation de pré-soutenante, de soutenance, flyer. '''Il sera appelé documents.'''
** Un ou plusieurs pour le code, les tests, les évaluations, les preuves de concept, la ou les documentations afférentes.

* Les '''documents public doivent être rédigés en anglais (README, documentation, commentaires de code, nom de variables et de fonctions)'''. Le *rapport* sera aussi demandé en *anglais* (il fera la taille d'un rapport de TP). Les transparents des présentation peuvent être en anglais ou en francais, la soutenance sera taire en francais.

* '''La note obtenue''' tiendra compte du '''nombre et de la qualité des commits''' observé dans '''vos dépots git et la branche master''' (or depot documents). La qualité comprend l'intitulé du commit et son contenu. Les notes pourront être différentiées dans un groupe, il n'est pas acceptable de pas avoir de commit dans le(s) dépôt(s) du projet (or dépôt documents).

* Il est fortement conseillé de suivre un '''développement incrémental''' qui permette d'avoir à tout moment un démonstrateur à présenter, un projet peut être constituer d'une succession de '''démonstrateurs présentables séparément'''.

* Vous devez faire aussi des '''schémas d'architectures générales et/ou spéficiques, des diagrammes de séquence''', et autre documents de spécification si nécessaire. Ces documents vous serviront de base de discussion/brainstorming interne ainsi que dans vos différents documents (rapport, présentations, documentation). Ces schémas sont avant tout conceptuels et techniques.

===Propositions de projets S8===

* 1. [https://codimd.math.cnrs.fr/?next=%2Fs%2FB029qfT5Q Courriels à Suppression Programmée] : Michaël Périn
* 2. [[Firmwares open source pour une station de réception de satellites pour l’Internet des Objets isolés]], Didier DONSEZ.
* 3. [[Evaluation du toolkit AI de STM32 pour l'analyse de l'environnement sonore]] (Suite 2022), Didier DONSEZ.
* 4. [[Algorithmes de géolocalisation d’objets par TDOA (Time Difference of Arrival)]] (suite), Didier DONSEZ.
* 5. [[Dashboard pour Overwatch]] Olivier Richard
* 6. [[Application mobile d'enregistrements de noeuds IoT LoRaWAN dans plusieurs réseaux]] (Suite) : Didier DONSEZ
* 7. [[Bluetooth 5.1 Angle of Arrival based Indoor Localization]] (Suite) : Didier DONSEZ
* 8. Intégration de composants de mesures environnementales (eau, air, ...) pour le [[Contribution au projet STM32Python|projet STM32Python]] à destination des lycéens: Didier DONSEZ
* 9. [[Air Quality Station]] (Suite) : Didier DONSEZ
* 10. [[Floating Water Quality Station]] : Didier DONSEZ, Nicolas PALIX
* 12. [[Testeur de terrain pour réseaux LoRaWAN privés et publics (TTN, CampusIoT et Helium)]] (suite 2021), Didier DONSEZ.
* 13. [[Géolocalition Indoor en LoRa 2.4GHz]], Didier DONSEZ.
* 14. [[RealWorld avec Dioxus]] (Rust + web), Olivier Richard
* 15. Poursuite projet 20-21 [[Rust Engine | Executeur de tâche en Rust]], Olivier Richard
* 16. Poursuite projet 20-21 [[Retrocompute simulateur | RetroComputing]]: (vintage style) Coupler le simulateur Digital avec un simulateur de processeur 8bits, Olivier Richard
* 17. Poursuite projet 19-20 [[Portail pour gestionnaire de taches]](react, Typescript), Olivier Richard
* 18. [[Paquets NIX pour Polytech]], Olivier Richard
* 19. [[Mini compilateur C pour mini CPU]], Olivier Richard
* 20. Mode jeu en réseau (Wifi/Bluetooth) pour [[TanksOfFreedom]], Nicolas Palix

Non affecté
* xx. [[Bibliothèque de décodeurs standards et d'afficheurs Grafana pour objets connectés LoRaWAN]] : Didier DONSEZ
* xx. [[ASAC|Agriculture connectée]] en partenariat avec les projets collectifs IESE/MAT : Nicolas Palix
* xx. [[Faults In Linux]], Nicolas Palix

===Affectations===
{|class="wikitable alternance"
|+ Affectation des projets INFO4 21-22
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Enseignant(s)
!scope="col"| Fiche de suivi
!scope="col"| Documents
|-
!scope="row"| 1
| [https://air.imag.fr/index.php/Planned_Deletion_Emails Courriels à Suppression Programmée]
| CANIN CORENTIN,MONTEILLER JOSHUA,WAGNER SAMY
| Michaël PÉRIN
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/01/docs/-/blob/main/%20Courriels%20%C3%A0%20Suppression%20Programm%C3%A9e%20info4_2021_2022.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 2
| [https://air.imag.fr/index.php/Firmwares_open_source_pour_une_station_de_r%C3%A9ception_de_satellites_pour_l%E2%80%99Internet_des_Objets_isol%C3%A9s# Firmwares open source pour une station de réception de satellites pour l’Internet des Objets isolés]
| CARMONA DAMIAN,DA COSTA TOM,WOZNY PIERRE-RAPHAEL
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/02/docs/-/blob/main/Firmwares_open_source_pour_une_station_de_r%C3%A9ception_de_satellites_pour_l_Internet_des_Objets_isol%C3%A9s_info4_2021_2022.md# Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 3
| [https://air.imag.fr/index.php/Evaluation_du_toolkit_AI_de_STM32_pour_l%27analyse_de_l%27environnement_sonore Evaluation du toolkit AI de STM32 pour l'analyse de l'environnement sonore]
| BACH THOMAS,BARBE FLORENT,SIMO YOKAM GEORGES HARRISSO
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/03/docs/ Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:Midterm_presentation_3_2022.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 5
| [https://air.imag.fr/index.php/Dashboard_pour_Overwatch# Dashboard pour Overwatch]
| CAILLES MAXIME,REYGNER ETIENNE,VERRIER MARTIN
| Olivier RICHARD
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/05/docs/-/blob/main/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 6
| [[Application mobile d'enregistrements de noeuds IoT LoRaWAN dans plusieurs réseaux]]
| CHIOTTI MAEL,LAVIROTTE GAETAN,MOTTINO LORIS
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/06/docs/-/tree/main Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 8
| [https://air.imag.fr/index.php/Contribution_au_projet_STM32Python Intégration de composants de mesures environnementales (eau, air...) pour le projet STM32Python à destination des lycéens]
| GUIRGUIS MIRETTE,HADIBY CHEMSSEDDINE,MOHSEN HACHEM
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/08/docs/-/blob/main/README.md#lorawan Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 10
| [[Floating Water Quality Station]]
| BRETON EMERIC,FAGHLOUMI AYMAN,VIALLET CAMILLE
| Didier DONSEZ, Nicolas PALIX
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/10/docs/-/blob/main/info4_2021_2022_Fiche_suivi_projet.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/10/docs/-/blob/main/Soutenance%20mi-parcours%20Projet_S8.pdf Presentation de mi-parcours]
|-
!scope="row"| 13
| [https://air.imag.fr/index.php/G%C3%A9olocalition_Indoor_en_LoRa_2.4GHz Géolocalition Indoor en LoRa 2.4GHz]
| BERNERD CLARA,JARDIN BAPTISTE,NGUYEN JUSTIN
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/13/docs/-/blob/main/Fiche_de_suivi.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 14
| [[RealWorld avec Dioxus]]
| IFAKIREN SAMI,MONTHE DJEUMOU BRICE,NGUYEN CLEMEN
| Olivier RICHARD
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/14/docs Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 15
| [https://air.imag.fr/index.php/Rust_Engine Exécuteur de tâche en Rust]
| CHAPPAZ FLORIAN,DE OLIVEIRA VALENTIN,KURKLU FIKRET
| Olivier RICHARD
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/15/docs/-/blob/main/Rust_Engine_info4_2021_2022.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/15/docs/-/blob/main/rust_engine_mid_presentation.pdf Presentation de mi-parcours]
|-
!scope="row"| 17
| [https://air.imag.fr/index.php/Portail_pour_gestionnaire_de_taches Portail Pour Gestionnaire De Taches]
| KACHA TOM,MAHAMAN NOURY ABDOURAHAMANE,MEIGNEN HUGO,ZHANG KEMING
| Olivier RICHARD
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/17/docs/-/blob/main/Fiche_De_Suivi_17.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/17/docs/-/blob/main/Pr%C3%A9sentation-mi-parcours.pdf Presentation de mi-parcours]
|-
!scope="row"| 18
| [[Paquets NIX pour Polytech]]
| CONJARD SAMUEL,FODOR GERGELY,PELISSE-VERDOUX CYPRIEN
| Olivier RICHARD
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/18/docs/-/blob/master/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 19
| [[Mini compilateur C pour mini CPU]]
| CAPET THEO,POITEVIN EVE,ROYET JULIAN
| Olivier Richard
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/19/docs/-/blob/main/C_compiler_for_MCPU_info4_2021_2022.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 20
| Mode jeu en réseau pour [[TanksOfFreedom]],
| ABECASSIS THOMAS,FOURNIER THOMAS,ZAFFUTO LUCA
| Nicolas Palix
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/20/docs/-/blob/main/fiche_de_suivi.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
|}

==INFO5==
===Projet IoT S9===
Enseignants responsables : Bernard Tourancheau

Calendrier: Octobre à Décembre 2021. Soutenance 24 Janvier 2022.

{|class="wikitable alternance"
|+ Choix des projet des projets INFO5 Réseaux 21-22
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Documents
!scope="col"| Github/Trello
|-
!scope="row"| 1
| [[Réseau de capteur de dichlorométhane]]
| Dorian BARET - Malone JULIENNE - Quentin CAMBUS
| [https://lesjoiesducode.fr/quand-notre-revue-de-sprint-se-passe-nickel Fiche]
| [https://github.com/Cambus-Quentin/DichloWan2021/blob/main/README.md git]
|-
!scope="row"| 2
| [[Création d'un système pour localiser les élèves lors de courses d'orientation]]
| Antoine Gitton, Gilles Mertens, Bertrand Baudeur
| [[Media:2021_2022_INFO5_IOT_Orientation_spec.pdf|Spécification paquets LoRa]]
| [[Media:2021_2022_INFO5_IOT_Orientation_backend.zip|Souces back-end]] - [[Media:2021_2022_INFO5_IOT_Orientation_carte.zip|Souces carte]]
|-
!scope="row"| 3
| [[Harnais animalier permettant de suivre notre animal domestique]]
| Sami ELHADJI TCHIAMBOU, Corentin HUMBERT, Paul LAMBERT, Hugo PRAT CAPILLA
| [[Media:PSP_Presentation.pdf|Présentation finale]]
| [https://github.com/Bicorpro Organisation GitHub]
|-
!scope="row"| 4
| [[Géolocalisation et suivi des transports en commun]]
| Liam ANDRIEUX, Lucas DREZET, Roman REGOUIN
|
| [https://github.com/2021-2022-IoT-INFO5-G4 Organisation GitHub]
|-
!scope="row"| 5
| [[Tracking des déplacements de joueurs sur un terrain]]
| Elias EL YANDOUZI, Lucas CHALOYARD
| [[Media:IOT_Presentation.pdf|Présentation finale]]
| [https://github.com/Indoor-Shadow/ble-experiment Github Repo]
|-
!scope="row"| 6
| [[Beer Pong connecté]]
| Yael PARA, Théo TEYSSIER, Victor MALOD, Alexis LANQUETIN
| [[Media:BeerPong_Presentation.pdf|Présentation finale]]
| [https://github.com/McReaper/BeerPongLora Gitub Repo]
|}

Exposés points techniques 10' - questions 5'
* Nom Sujet
* ??? Python
* ??? MQTT
* ??? COAP
* 26/11/2021 - Elias El Yandouzi - Les différentes techniques de virtualisation

===Projet Semestre S10===

Enseignant responsable : [[user:Donsez|Didier Donsez]]

Convention des projets tutorés externes : Elise Didier.

Calendrier: 27/01 (8H30-12H00) au 18/03.

Séances de Management de projets innovants: A voir dessus.

Réunion de présentation et choix des sujets: 27/01 (8H30-12H00) en salle Polygone P206 (voir ADE)

Démarrage : 27/01

Soutenance à mi-parcours (à définir) : ??/02/2021 13H30-17H30 en distantiel (15 minutes par équipe).

Soutenance finale : 18/03/2021 (8H30-12H00 et 13H30-17H00). 30 minutes par équipe, questions/réponses et démonstration incluse. Prière de rapporter au fablab le matériel emprunté juste après votre soutenance.

====Séances MPI====

Voir ADE qui fait foi).

<pre>

</pre>

==== Soutenance intermédiaire S10 ====
Date: 18/02 Matin. Distantiel (sur Zoom). Créneaux de 10 minutes.

L'objectif de la soutenance intermédiaire est de vérifier si l'équipe projet est en bon ordre de marche

L'équipe présentera en 5-6 transparents en 7 minutes.
* les équipiers et leurs rôles
* le contexte, le sujet et l'objectif du projet
* l'architecture du systèmes à réaliser
* les technologies utilisées
* le plan de travail (backlog, planning, ce qui est fait, ce qu'il reste à faire ...)
* les difficultés (s'il y a)

Prévoyez du temps pour les questions-réponses (3 minutes max).

Respectez bien les créneaux indiqués (par respect pour les autres équipes) et soyez présents un peu en avance dans la salle d'attente.

La présence des porteurs n'est pas obligatoire.

==== Soutenance finale S10 ====
Date provisoire: 18/03/2022 (8H30-12H00 et 13H30-17H00).

'''La présence du(des) porteur(s) est obligatoire. Pensez à les prévenir bien à l'avance'''

Durée: 30 minutes par équipe: présentation, questions/réponses et démonstration incluse.

Les documents devront être en ligne sur le wiki (colonne Documents) la veille (ie avant le 17/03/2021 23:59:59 CET).

La présentation est constituée des chapitres suivants:
* Rappel du sujet/besoin et cahier des charges
* Technologies employées
* Architecture techniques
* Réalisations techniques
* Gestion de projet (méthode, planning prévisionnel et effectif, gestion des risques, rôles des membres ...)
* Outils (collaboration, CD/CI ...)
* Métriques logiciels : lignes de code, langages, performance, temps ingénieur (d'après vos journaux), la répartition des lignes de code et des commits en pourcentage entre les membres du projet ...)
* Conclusion (Retour d'expérience)
* Transparent expliquant la démonstration

L'ensemble des documents doit être accessible depuis le tableau ci-dessus et dans chaque fiche de suivi.

Le screencast (réalisé lors de la dernière répétition) sera rendu disponible via un partage caché (wetransfer, google drive …) dont le lien sera ajouté dans le devoir idoine sur Moodle et également envoyé par mail à votre tuteur.

Le rapport final contient les mêmes chapitres que la présentation ainsi qu'un glossaire et une bibliographie. Le rapport ne doit pas dépasser 15 pages (schémas et figures compris). Vous pourrez référencer les autres documents que vous avez produits au cours du projet (spécifications détaillées, algorithmes, conception d'écrans ...).

Le rapport final est au format Markdown et doit être placé dans un des dépôts Git de votre groupe/organisation.

NB: le rapport technique listé dans la colonne Documents contient tout ce qui ne tient pas dans les 15 pages du rapport final : cahier des charges, diagrammes UML, enquêtes utilisateurs design UI, API, technologies employées (détail), plan de tests, term of services, conformance RPGD, audits/diagnostiques sécurité, MTBR, rapport de vulnérabilité, plan de charge, rapports de charge, manuel d'installation … : ça dépend un peu de la nature de votre projet.

Conseil : 30 minutes c'est très court alors répétez la soutenance auparavant ! Prévoyez des transparents supplémentaires en annexe pour répondre aux questions.

'''Prière de rapporter au fablab le matériel emprunté juste après votre soutenance'''.

==== Affectations S10====
{|class="wikitable alternance"
|+ Affectation des projets INFO5 2021-2022
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Porteur(s)
!scope="col"| Fiche de suivi
!scope="col"| Documents
!scope="col"| Dépôt Git
!scope="col"| Soutenance intermédiaire
|-

!scope="row"| 1
| [[Test d'infrastructures avec NixOS]]
| HUMBERT CORENTIN, MINIER MANCINI TITOUAN (Chef de projet), SUEUR CORENTIN (Scrum master)
| Olivier RICHARD et Quentin GUILLETEAU
| [XXXX Fiche]
| [[Rapport Test Infrastructures NixOS 2021-2022|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:Presentation_mi_parcours_NixOs.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:English_Poster_NixOS.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://git/xxx Dépot Git]
| [[Media:Presentation_mi_parcours_NixOs.pdf|Presentation intermédiaire]]
|-

!scope="row"| 2
| [[Plan dynamique d’un appartement connecté]]
| GRANGER OSCAR (Chef de projet), NOERIE SOPHIE, SARRE MARGAUX, SALMON AMAD, TEYSSIER THEO (Scrum master)
| Sybille CAFFIAU
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:Presentation_intermediaire_DOMUS.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:Poster-xxx-en.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://git/xxx Dépot Git]
| [[Media:Presentation_intermediaire_DOMUS.pdf|Presentation intermédiaire]]
|-

!scope="row"| 3
| [[Suivi de troupeaux (ovins, bovins) en zone montagneuse avec un réseau LoRaWAN : expérimentation dans la Matheysine]]
| GITTON ANTOINE, MALOD VICTOR, MUTEL MATHIS
| Fabrice FOREST
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:INFO5_AgriConnect_presentation_miparcours.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:Poster-xxx-en.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://git/xxx Dépot Git]
| [[Media:xxx.pdf|Presentation intermédiaire]]
|-

!scope="row"| 4
| [[FitSize]]
| GEITNER TEVA , GONZALEZ JULES, PARA YAEL
| Fidèle Eya'a
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:PrésentationFitSize.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:Poster-xxx-en.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://git/xxx Dépot Git]
| [[Media:PrésentationFitSize.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 5
| [[GenderedNews]]
| AGUIAR MATHILDE (Chef de projet), HAJJI OUMAIMA (SCRUM Master), SIDIBE ROKIATOU DITE ROSE
| François PORTET, Gilles BASTIN, Ange RICHARD
| [[PROJET-INFO5 2022 GenderedNews|Fiche de suivi]]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:flyer_genderednews.pdf|Flyer]] - [[Media: Soutenance_interm_genderednews.pdf|Presentation de mi-parcours]] - [[Media:Poster-genderednews-fr.pdf|Poster FR]] - [[Media:Poster-genderednews-en.pdf|Poster EN]] - [[Media: Pitch_genderednews.pdf | Pitch 180 secondes]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/getalp/genderednews Dépot Git]
| [[Media: Soutenance_interm_genderednews.pdf|Presentation intermédiaire]]
|-

!scope="row"| 6
| [[Système d'analyse de traces sportives]]
| HERQUE ERIC (Scrum Master), VACHERIAS GUILLAUME (Chef de projet)
| Vivien QUEMA
| [[PROJET-INFO5 2022 Systeme d'analyse de traces sportive fiche suivis | Fiche de suivi]]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:Presentation_mi_parcours_systeme_analyse_trace_sportive.pdf|Presentation de mi-parcours]]- [[Media:Poster_systeme_analyse_trace_sportive.pdf|Poster FR]] - [[Media:Poster_systeme_analyse_trace_sportive.pdf|Poster EN]] - [[PROJET-INFO5 2022 Systeme d'analyse de traces sportive pitch | Pitch 180 secondes]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/vacherig/systeme-analyse-de-traces-sportives Dépot Git]
| [[Media:Presentation_mi_parcours_systeme_analyse_trace_sportive.pdf|Presentation intermédiaire]]
|-

!scope="row"| 7
| [[Qualité de l'Air et Santé des Populations]]
| BAUDEUR BERTRAND (Scrum Master), MERTENS GILLES (Chef)
| Marie-Laure AIX
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:Presentation_mi_parcours_qualite_air_baudeur_mertens.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:Poster-xxx-en.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://github.com/Air-Quality-LoRa Dépot Git]
| [[Media:Presentation_mi_parcours_qualite_air_baudeur_mertens.pdf|Presentation intermédiaire]]
|-

!scope="row"| 8
| [[Artiphonie(saison 3)]] extension de la [[Artiphonie (saison 2)]]
| BUISINE JULIEN (Chef de Projet), ELHADJI TCHIAMBOU SAMI, LAMBERT DAPHNE (Scrum Master), LAMBERT PAUL
| Olivier Richard
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media: Artiphonie-Presentation_mi-parcours.pdf|Presentation intermédiaire]] - [[Media:Poster_Artiphonie_FR.pdf|Poster FR]] - [[Media:Poster_Artiphonie_-_LAMBERT,_BUISINE,_ELHADJI_TCHIAMBOU.pdf|Poster EN]] - [[Media: Pitch_Artiphonie_2022.pdf|Pitch Artiphonie 2022]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/artiphonie/projet-info5-21-22 Dépot Git]
| [[Media: Artiphonie-Presentation_mi-parcours.pdf|Presentation intermédiaire]]
|-

!scope="row"| 9
| [[Quark Project]]
| CHALOYARD LUCAS, EL YANDOUZI ELIAS
| Olivier Gruber
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:Soutenance QuarkV3.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:Poster-xxx-en.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://git/xxx Dépot Git]
| [[Media:Soutenance QuarkV3.pdf|Presentation intermédiaire]]
|-

!scope="row"| 10
| [[Jorigine]]
| BLANQUET ANTOINE ('''Scrum Master'''), LANQUETIN ALEXIS ('''Chef de projet'''), MALECOT ETHAN, PRAT-CAPILLA HUGO
| Sylvain Delangue
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:Presentation_Projet_miparcours_S10.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:PosterJorigine2022_vfinal.pdf|Poster EN]] - [[Media:Pitch_Jorigine_grp10.pdf|Pitch en 180 secondes]]
| [https://git/xxx Dépot Git]
| [[Media:Presentation_Projet_miparcours_S10.pdf|Presentation intermédiaire]]
|-

!scope="row"| 11
| [[Contributions open source au projet EdCampus|EdCampus]]
| ANDRIEUX LIAM, COSOTTI KEVIN, DREZET LUCAS ('''Chef de projet'''), REGOUIN ROMAN ('''Scrum Master''')
| Anthony GEOURJON
| [XXXX Fiche]
| [[Rapport EDCampus 2021-2022|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [https://air.imag.fr/images/c/ca/Soutenance_interm%C3%A9diaire_-_EDCampus_2021-2022.pdf Presentation de mi-parcours] - [https://air.imag.fr/images/0/00/PosterFREDCampus20212022.pdf Poster FR] - [https://air.imag.fr/images/d/df/EDCampus_-_2021_2022.pdf Poster EN] - [https://air.imag.fr/images/d/d5/PitchEDCampus20212022.pdf Pitch]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/edcampus Dépot Git]
| [https://air.imag.fr/images/c/ca/Soutenance_interm%C3%A9diaire_-_EDCampus_2021-2022.pdf Presentation intermédiaire]
|-

!scope="row"| 12
| [[Contributions open source au projet LabnBook|LabnBook]]
| CIRSTEA PAUL, SOULARD ALEXANDRE (Chef de projet), TONDEUX EMILIE (Scrum master), YUNG KEVIN
| Anthony GEOURJON, Cédric DHAM
| [[PROJET-INFO5 2022 LabNbook|Fiche de suivi]]
| [[Rapport LabNbook 2021-2022|Rapport final]] - [[Media:LabnBook_Presentation_finale.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Flyer]] - [[Media:LabnBook.pdf|Presentation de mi-parcours]] - [[Media:Poster_GroupLabnBook_Cirstea_Soulard_Tondeux_Yung.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes] - [https://drive.google.com/file/d/1eWU090ieX3dC8vweB4UKzwfu9E7jk1vI/view?usp=sharing Screencast]
| [https://git/xxx Dépot Git]
| [[Media:LabnBook.pdf|Presentation intermédiaire]]
|-

!scope="row"| 13
| [[Green collect]]
| BARET DORIAN, CAMBUS QUENTIN (Chef de projet), JULIENNE MALONE, MALLEN GUILLAUME (Scrum master)
| Bernard TOURANCHEAU
| [XXXX Fiche]
| [https://github.com/GreenCollects/docs/blob/main/report/CR-Final-Report.md Rapport final] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [https://github.com/GreenCollects/docs/blob/main/soutenance/Soutenance%20de%20mi-parcours.pdf Presentation de mi-parcours] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:Poster-xxx-en.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://github.com/GreenCollects Dépot Git]
| [https://github.com/GreenCollects/docs/blob/main/soutenance/Soutenance%20de%20mi-parcours.pdf Presentation intermédiaire]
|-

|}

Sujets non choisis

# [[LoRaWAN Roaming]] avec [[Chirpstack]], [[TheThingStack]] et [[Actility]] pour le projet [https://gricad-gitlab.univ-grenoble-alpes.fr/thingsat/public/-/blob/master/cubesat_mission/README.md Thingsat]: Didier DONSEZ, Olivier ALPHAND.
# [[Contributions logicielles au projet RIOT OS pour le New Space]] : Francois-Xavier MOLINA, Olivier ALPHAND, Didier DONSEZ
# [[Réseaux social d'organisation de sortie (saison 2)]] refonte [[Réseaux social d'organisation de sortie]], Olivier Richard
# [[Experiment Process Management]], Olivier Richard
# [[Language Server for Visual Studio]]: Olivier Gruber
# ABANDONNé [[Réseau d'Alumni de formations]] (à confirmer), Gérard POLLIER ([https://disrupt-campus.univ-grenoble-alpes.fr/design-factory-grenoble/ Design Factory Grenoble])
# [[Evaluation du kit IA embarqué Wio Terminal]]: Louis CLOSSON, Didier DONSEZ (sous réserve de réception du matériel commandé)

Projets 2021-2022

2022-03-17T19:26:56Z

Titouan.Minier-Mancini: /* Affectations S10 */

<<[[Projets 2020-2021]] | [[Projets]] | [[Projets 2022-2023]]>>
=INFO=
==INFO3==

==INFO4==
===Projet Semestre S8===

Enseignants responsables : Olivier Richard

* Dates : Lundi après-midi, Mardi après-midi
* Lancement: 10 Janvier 2021 après midi
* Soutenance à mi-parcours: A définir
* Soutenance: A définir

* '''Evaluation à mi-parcours le lundi/mardi ???''': Format: 10min (5min de présentation 3 slides au plus, 5min de discussion). Cette évaluation sera prise en compte dans la note finale.

'''Consignes générales:'''

* '''Vous devez être pro-actifs !!!''': Si des points sont pas ou mals spécifiés, vous le faîtes et vous justifiez vos choix. Pour les problèmes techniques éventuels vous pouvez: creuser la question, contacter l'auteur du code si il y a lieu, écrire un rapport de bug ('''Attention:''' ca se prépare !), soumettre un patch/pull request, contacter l'enseignant ou la personne référente du projet.

* '''Vous devez maintenir une fiche de suivi de projet''': elle doit être mise à jour chaque semaine, elle rassemble les élements essentiels du projet, elle indique les évolutions du projet et présente sa feuille de route. '''Note:''' le nom de la fiche doit être composé du nom du projet et suffixé par info4_2021_2022. '''Cette fiche compte pour la note finale'''

* '''Votre code''' pour doit être hébergé sur le gitlab et à l'URL suivante https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22 , vous utiliserez votre compte UGA.

* Chaque projet doit avoir '''aux moins 2 dépôts git''':
** '''Un pour les documents''' demandés rapport, présentation de pré-soutenante, de soutenance, flyer. '''Il sera appelé documents.'''
** Un ou plusieurs pour le code, les tests, les évaluations, les preuves de concept, la ou les documentations afférentes.

* Les '''documents public doivent être rédigés en anglais (README, documentation, commentaires de code, nom de variables et de fonctions)'''. Le *rapport* sera aussi demandé en *anglais* (il fera la taille d'un rapport de TP). Les transparents des présentation peuvent être en anglais ou en francais, la soutenance sera taire en francais.

* '''La note obtenue''' tiendra compte du '''nombre et de la qualité des commits''' observé dans '''vos dépots git et la branche master''' (or depot documents). La qualité comprend l'intitulé du commit et son contenu. Les notes pourront être différentiées dans un groupe, il n'est pas acceptable de pas avoir de commit dans le(s) dépôt(s) du projet (or dépôt documents).

* Il est fortement conseillé de suivre un '''développement incrémental''' qui permette d'avoir à tout moment un démonstrateur à présenter, un projet peut être constituer d'une succession de '''démonstrateurs présentables séparément'''.

* Vous devez faire aussi des '''schémas d'architectures générales et/ou spéficiques, des diagrammes de séquence''', et autre documents de spécification si nécessaire. Ces documents vous serviront de base de discussion/brainstorming interne ainsi que dans vos différents documents (rapport, présentations, documentation). Ces schémas sont avant tout conceptuels et techniques.

===Propositions de projets S8===

* 1. [https://codimd.math.cnrs.fr/?next=%2Fs%2FB029qfT5Q Courriels à Suppression Programmée] : Michaël Périn
* 2. [[Firmwares open source pour une station de réception de satellites pour l’Internet des Objets isolés]], Didier DONSEZ.
* 3. [[Evaluation du toolkit AI de STM32 pour l'analyse de l'environnement sonore]] (Suite 2022), Didier DONSEZ.
* 4. [[Algorithmes de géolocalisation d’objets par TDOA (Time Difference of Arrival)]] (suite), Didier DONSEZ.
* 5. [[Dashboard pour Overwatch]] Olivier Richard
* 6. [[Application mobile d'enregistrements de noeuds IoT LoRaWAN dans plusieurs réseaux]] (Suite) : Didier DONSEZ
* 7. [[Bluetooth 5.1 Angle of Arrival based Indoor Localization]] (Suite) : Didier DONSEZ
* 8. Intégration de composants de mesures environnementales (eau, air, ...) pour le [[Contribution au projet STM32Python|projet STM32Python]] à destination des lycéens: Didier DONSEZ
* 9. [[Air Quality Station]] (Suite) : Didier DONSEZ
* 10. [[Floating Water Quality Station]] : Didier DONSEZ, Nicolas PALIX
* 12. [[Testeur de terrain pour réseaux LoRaWAN privés et publics (TTN, CampusIoT et Helium)]] (suite 2021), Didier DONSEZ.
* 13. [[Géolocalition Indoor en LoRa 2.4GHz]], Didier DONSEZ.
* 14. [[RealWorld avec Dioxus]] (Rust + web), Olivier Richard
* 15. Poursuite projet 20-21 [[Rust Engine | Executeur de tâche en Rust]], Olivier Richard
* 16. Poursuite projet 20-21 [[Retrocompute simulateur | RetroComputing]]: (vintage style) Coupler le simulateur Digital avec un simulateur de processeur 8bits, Olivier Richard
* 17. Poursuite projet 19-20 [[Portail pour gestionnaire de taches]](react, Typescript), Olivier Richard
* 18. [[Paquets NIX pour Polytech]], Olivier Richard
* 19. [[Mini compilateur C pour mini CPU]], Olivier Richard
* 20. Mode jeu en réseau (Wifi/Bluetooth) pour [[TanksOfFreedom]], Nicolas Palix

Non affecté
* xx. [[Bibliothèque de décodeurs standards et d'afficheurs Grafana pour objets connectés LoRaWAN]] : Didier DONSEZ
* xx. [[ASAC|Agriculture connectée]] en partenariat avec les projets collectifs IESE/MAT : Nicolas Palix
* xx. [[Faults In Linux]], Nicolas Palix

===Affectations===
{|class="wikitable alternance"
|+ Affectation des projets INFO4 21-22
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Enseignant(s)
!scope="col"| Fiche de suivi
!scope="col"| Documents
|-
!scope="row"| 1
| [https://air.imag.fr/index.php/Planned_Deletion_Emails Courriels à Suppression Programmée]
| CANIN CORENTIN,MONTEILLER JOSHUA,WAGNER SAMY
| Michaël PÉRIN
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/01/docs/-/blob/main/%20Courriels%20%C3%A0%20Suppression%20Programm%C3%A9e%20info4_2021_2022.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 2
| [https://air.imag.fr/index.php/Firmwares_open_source_pour_une_station_de_r%C3%A9ception_de_satellites_pour_l%E2%80%99Internet_des_Objets_isol%C3%A9s# Firmwares open source pour une station de réception de satellites pour l’Internet des Objets isolés]
| CARMONA DAMIAN,DA COSTA TOM,WOZNY PIERRE-RAPHAEL
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/02/docs/-/blob/main/Firmwares_open_source_pour_une_station_de_r%C3%A9ception_de_satellites_pour_l_Internet_des_Objets_isol%C3%A9s_info4_2021_2022.md# Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 3
| [https://air.imag.fr/index.php/Evaluation_du_toolkit_AI_de_STM32_pour_l%27analyse_de_l%27environnement_sonore Evaluation du toolkit AI de STM32 pour l'analyse de l'environnement sonore]
| BACH THOMAS,BARBE FLORENT,SIMO YOKAM GEORGES HARRISSO
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/03/docs/ Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:Midterm_presentation_3_2022.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 5
| [https://air.imag.fr/index.php/Dashboard_pour_Overwatch# Dashboard pour Overwatch]
| CAILLES MAXIME,REYGNER ETIENNE,VERRIER MARTIN
| Olivier RICHARD
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/05/docs/-/blob/main/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 6
| [[Application mobile d'enregistrements de noeuds IoT LoRaWAN dans plusieurs réseaux]]
| CHIOTTI MAEL,LAVIROTTE GAETAN,MOTTINO LORIS
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/06/docs/-/tree/main Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 8
| [https://air.imag.fr/index.php/Contribution_au_projet_STM32Python Intégration de composants de mesures environnementales (eau, air...) pour le projet STM32Python à destination des lycéens]
| GUIRGUIS MIRETTE,HADIBY CHEMSSEDDINE,MOHSEN HACHEM
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/08/docs/-/blob/main/README.md#lorawan Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 10
| [[Floating Water Quality Station]]
| BRETON EMERIC,FAGHLOUMI AYMAN,VIALLET CAMILLE
| Didier DONSEZ, Nicolas PALIX
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/10/docs/-/blob/main/info4_2021_2022_Fiche_suivi_projet.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/10/docs/-/blob/main/Soutenance%20mi-parcours%20Projet_S8.pdf Presentation de mi-parcours]
|-
!scope="row"| 13
| [https://air.imag.fr/index.php/G%C3%A9olocalition_Indoor_en_LoRa_2.4GHz Géolocalition Indoor en LoRa 2.4GHz]
| BERNERD CLARA,JARDIN BAPTISTE,NGUYEN JUSTIN
| Didier DONSEZ
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/13/docs/-/blob/main/Fiche_de_suivi.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 14
| [[RealWorld avec Dioxus]]
| IFAKIREN SAMI,MONTHE DJEUMOU BRICE,NGUYEN CLEMEN
| Olivier RICHARD
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/14/docs Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 15
| [https://air.imag.fr/index.php/Rust_Engine Exécuteur de tâche en Rust]
| CHAPPAZ FLORIAN,DE OLIVEIRA VALENTIN,KURKLU FIKRET
| Olivier RICHARD
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/15/docs/-/blob/main/Rust_Engine_info4_2021_2022.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/15/docs/-/blob/main/rust_engine_mid_presentation.pdf Presentation de mi-parcours]
|-
!scope="row"| 17
| [https://air.imag.fr/index.php/Portail_pour_gestionnaire_de_taches Portail Pour Gestionnaire De Taches]
| KACHA TOM,MAHAMAN NOURY ABDOURAHAMANE,MEIGNEN HUGO,ZHANG KEMING
| Olivier RICHARD
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/17/docs/-/blob/main/Fiche_De_Suivi_17.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/17/docs/-/blob/main/Pr%C3%A9sentation-mi-parcours.pdf Presentation de mi-parcours]
|-
!scope="row"| 18
| [[Paquets NIX pour Polytech]]
| CONJARD SAMUEL,FODOR GERGELY,PELISSE-VERDOUX CYPRIEN
| Olivier RICHARD
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/18/docs/-/blob/master/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 19
| [[Mini compilateur C pour mini CPU]]
| CAPET THEO,POITEVIN EVE,ROYET JULIAN
| Olivier Richard
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/19/docs/-/blob/main/C_compiler_for_MCPU_info4_2021_2022.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 20
| Mode jeu en réseau pour [[TanksOfFreedom]],
| ABECASSIS THOMAS,FOURNIER THOMAS,ZAFFUTO LUCA
| Nicolas Palix
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/20/docs/-/blob/main/fiche_de_suivi.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
|}

==INFO5==
===Projet IoT S9===
Enseignants responsables : Bernard Tourancheau

Calendrier: Octobre à Décembre 2021. Soutenance 24 Janvier 2022.

{|class="wikitable alternance"
|+ Choix des projet des projets INFO5 Réseaux 21-22
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Documents
!scope="col"| Github/Trello
|-
!scope="row"| 1
| [[Réseau de capteur de dichlorométhane]]
| Dorian BARET - Malone JULIENNE - Quentin CAMBUS
| [https://lesjoiesducode.fr/quand-notre-revue-de-sprint-se-passe-nickel Fiche]
| [https://github.com/Cambus-Quentin/DichloWan2021/blob/main/README.md git]
|-
!scope="row"| 2
| [[Création d'un système pour localiser les élèves lors de courses d'orientation]]
| Antoine Gitton, Gilles Mertens, Bertrand Baudeur
| [[Media:2021_2022_INFO5_IOT_Orientation_spec.pdf|Spécification paquets LoRa]]
| [[Media:2021_2022_INFO5_IOT_Orientation_backend.zip|Souces back-end]] - [[Media:2021_2022_INFO5_IOT_Orientation_carte.zip|Souces carte]]
|-
!scope="row"| 3
| [[Harnais animalier permettant de suivre notre animal domestique]]
| Sami ELHADJI TCHIAMBOU, Corentin HUMBERT, Paul LAMBERT, Hugo PRAT CAPILLA
| [[Media:PSP_Presentation.pdf|Présentation finale]]
| [https://github.com/Bicorpro Organisation GitHub]
|-
!scope="row"| 4
| [[Géolocalisation et suivi des transports en commun]]
| Liam ANDRIEUX, Lucas DREZET, Roman REGOUIN
|
| [https://github.com/2021-2022-IoT-INFO5-G4 Organisation GitHub]
|-
!scope="row"| 5
| [[Tracking des déplacements de joueurs sur un terrain]]
| Elias EL YANDOUZI, Lucas CHALOYARD
| [[Media:IOT_Presentation.pdf|Présentation finale]]
| [https://github.com/Indoor-Shadow/ble-experiment Github Repo]
|-
!scope="row"| 6
| [[Beer Pong connecté]]
| Yael PARA, Théo TEYSSIER, Victor MALOD, Alexis LANQUETIN
| [[Media:BeerPong_Presentation.pdf|Présentation finale]]
| [https://github.com/McReaper/BeerPongLora Gitub Repo]
|}

Exposés points techniques 10' - questions 5'
* Nom Sujet
* ??? Python
* ??? MQTT
* ??? COAP
* 26/11/2021 - Elias El Yandouzi - Les différentes techniques de virtualisation

===Projet Semestre S10===

Enseignant responsable : [[user:Donsez|Didier Donsez]]

Convention des projets tutorés externes : Elise Didier.

Calendrier: 27/01 (8H30-12H00) au 18/03.

Séances de Management de projets innovants: A voir dessus.

Réunion de présentation et choix des sujets: 27/01 (8H30-12H00) en salle Polygone P206 (voir ADE)

Démarrage : 27/01

Soutenance à mi-parcours (à définir) : ??/02/2021 13H30-17H30 en distantiel (15 minutes par équipe).

Soutenance finale : 18/03/2021 (8H30-12H00 et 13H30-17H00). 30 minutes par équipe, questions/réponses et démonstration incluse. Prière de rapporter au fablab le matériel emprunté juste après votre soutenance.

====Séances MPI====

Voir ADE qui fait foi).

<pre>

</pre>

==== Soutenance intermédiaire S10 ====
Date: 18/02 Matin. Distantiel (sur Zoom). Créneaux de 10 minutes.

L'objectif de la soutenance intermédiaire est de vérifier si l'équipe projet est en bon ordre de marche

L'équipe présentera en 5-6 transparents en 7 minutes.
* les équipiers et leurs rôles
* le contexte, le sujet et l'objectif du projet
* l'architecture du systèmes à réaliser
* les technologies utilisées
* le plan de travail (backlog, planning, ce qui est fait, ce qu'il reste à faire ...)
* les difficultés (s'il y a)

Prévoyez du temps pour les questions-réponses (3 minutes max).

Respectez bien les créneaux indiqués (par respect pour les autres équipes) et soyez présents un peu en avance dans la salle d'attente.

La présence des porteurs n'est pas obligatoire.

==== Soutenance finale S10 ====
Date provisoire: 18/03/2022 (8H30-12H00 et 13H30-17H00).

'''La présence du(des) porteur(s) est obligatoire. Pensez à les prévenir bien à l'avance'''

Durée: 30 minutes par équipe: présentation, questions/réponses et démonstration incluse.

Les documents devront être en ligne sur le wiki (colonne Documents) la veille (ie avant le 17/03/2021 23:59:59 CET).

La présentation est constituée des chapitres suivants:
* Rappel du sujet/besoin et cahier des charges
* Technologies employées
* Architecture techniques
* Réalisations techniques
* Gestion de projet (méthode, planning prévisionnel et effectif, gestion des risques, rôles des membres ...)
* Outils (collaboration, CD/CI ...)
* Métriques logiciels : lignes de code, langages, performance, temps ingénieur (d'après vos journaux), la répartition des lignes de code et des commits en pourcentage entre les membres du projet ...)
* Conclusion (Retour d'expérience)
* Transparent expliquant la démonstration

L'ensemble des documents doit être accessible depuis le tableau ci-dessus et dans chaque fiche de suivi.

Le screencast (réalisé lors de la dernière répétition) sera rendu disponible via un partage caché (wetransfer, google drive …) dont le lien sera ajouté dans le devoir idoine sur Moodle et également envoyé par mail à votre tuteur.

Le rapport final contient les mêmes chapitres que la présentation ainsi qu'un glossaire et une bibliographie. Le rapport ne doit pas dépasser 15 pages (schémas et figures compris). Vous pourrez référencer les autres documents que vous avez produits au cours du projet (spécifications détaillées, algorithmes, conception d'écrans ...).

Le rapport final est au format Markdown et doit être placé dans un des dépôts Git de votre groupe/organisation.

NB: le rapport technique listé dans la colonne Documents contient tout ce qui ne tient pas dans les 15 pages du rapport final : cahier des charges, diagrammes UML, enquêtes utilisateurs design UI, API, technologies employées (détail), plan de tests, term of services, conformance RPGD, audits/diagnostiques sécurité, MTBR, rapport de vulnérabilité, plan de charge, rapports de charge, manuel d'installation … : ça dépend un peu de la nature de votre projet.

Conseil : 30 minutes c'est très court alors répétez la soutenance auparavant ! Prévoyez des transparents supplémentaires en annexe pour répondre aux questions.

'''Prière de rapporter au fablab le matériel emprunté juste après votre soutenance'''.

==== Affectations S10====
{|class="wikitable alternance"
|+ Affectation des projets INFO5 2021-2022
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Porteur(s)
!scope="col"| Fiche de suivi
!scope="col"| Documents
!scope="col"| Dépôt Git
!scope="col"| Soutenance intermédiaire
|-

!scope="row"| 1
| [[Test d'infrastructures avec NixOS]]
| HUMBERT CORENTIN, MINIER MANCINI TITOUAN (Chef de projet), SUEUR CORENTIN (Scrum master)
| Olivier RICHARD et Quentin GUILLETEAU
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:Presentation_mi_parcours_NixOs.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:English_Poster_NixOS.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://git/xxx Dépot Git]
| [[Media:Presentation_mi_parcours_NixOs.pdf|Presentation intermédiaire]]
|-

!scope="row"| 2
| [[Plan dynamique d’un appartement connecté]]
| GRANGER OSCAR (Chef de projet), NOERIE SOPHIE, SARRE MARGAUX, SALMON AMAD, TEYSSIER THEO (Scrum master)
| Sybille CAFFIAU
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:Presentation_intermediaire_DOMUS.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:Poster-xxx-en.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://git/xxx Dépot Git]
| [[Media:Presentation_intermediaire_DOMUS.pdf|Presentation intermédiaire]]
|-

!scope="row"| 3
| [[Suivi de troupeaux (ovins, bovins) en zone montagneuse avec un réseau LoRaWAN : expérimentation dans la Matheysine]]
| GITTON ANTOINE, MALOD VICTOR, MUTEL MATHIS
| Fabrice FOREST
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:INFO5_AgriConnect_presentation_miparcours.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:Poster-xxx-en.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://git/xxx Dépot Git]
| [[Media:xxx.pdf|Presentation intermédiaire]]
|-

!scope="row"| 4
| [[FitSize]]
| GEITNER TEVA , GONZALEZ JULES, PARA YAEL
| Fidèle Eya'a
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:PrésentationFitSize.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:Poster-xxx-en.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://git/xxx Dépot Git]
| [[Media:PrésentationFitSize.pdf|Presentation de mi-parcours]]
|-

!scope="row"| 5
| [[GenderedNews]]
| AGUIAR MATHILDE (Chef de projet), HAJJI OUMAIMA (SCRUM Master), SIDIBE ROKIATOU DITE ROSE
| François PORTET, Gilles BASTIN, Ange RICHARD
| [[PROJET-INFO5 2022 GenderedNews|Fiche de suivi]]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:flyer_genderednews.pdf|Flyer]] - [[Media: Soutenance_interm_genderednews.pdf|Presentation de mi-parcours]] - [[Media:Poster-genderednews-fr.pdf|Poster FR]] - [[Media:Poster-genderednews-en.pdf|Poster EN]] - [[Media: Pitch_genderednews.pdf | Pitch 180 secondes]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/getalp/genderednews Dépot Git]
| [[Media: Soutenance_interm_genderednews.pdf|Presentation intermédiaire]]
|-

!scope="row"| 6
| [[Système d'analyse de traces sportives]]
| HERQUE ERIC (Scrum Master), VACHERIAS GUILLAUME (Chef de projet)
| Vivien QUEMA
| [[PROJET-INFO5 2022 Systeme d'analyse de traces sportive fiche suivis | Fiche de suivi]]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:Presentation_mi_parcours_systeme_analyse_trace_sportive.pdf|Presentation de mi-parcours]]- [[Media:Poster_systeme_analyse_trace_sportive.pdf|Poster FR]] - [[Media:Poster_systeme_analyse_trace_sportive.pdf|Poster EN]] - [[PROJET-INFO5 2022 Systeme d'analyse de traces sportive pitch | Pitch 180 secondes]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/vacherig/systeme-analyse-de-traces-sportives Dépot Git]
| [[Media:Presentation_mi_parcours_systeme_analyse_trace_sportive.pdf|Presentation intermédiaire]]
|-

!scope="row"| 7
| [[Qualité de l'Air et Santé des Populations]]
| BAUDEUR BERTRAND (Scrum Master), MERTENS GILLES (Chef)
| Marie-Laure AIX
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:Presentation_mi_parcours_qualite_air_baudeur_mertens.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:Poster-xxx-en.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://github.com/Air-Quality-LoRa Dépot Git]
| [[Media:Presentation_mi_parcours_qualite_air_baudeur_mertens.pdf|Presentation intermédiaire]]
|-

!scope="row"| 8
| [[Artiphonie(saison 3)]] extension de la [[Artiphonie (saison 2)]]
| BUISINE JULIEN (Chef de Projet), ELHADJI TCHIAMBOU SAMI, LAMBERT DAPHNE (Scrum Master), LAMBERT PAUL
| Olivier Richard
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media: Artiphonie-Presentation_mi-parcours.pdf|Presentation intermédiaire]] - [[Media:Poster_Artiphonie_FR.pdf|Poster FR]] - [[Media:Poster_Artiphonie_-_LAMBERT,_BUISINE,_ELHADJI_TCHIAMBOU.pdf|Poster EN]] - [[Media: Pitch_Artiphonie_2022.pdf|Pitch Artiphonie 2022]]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/artiphonie/projet-info5-21-22 Dépot Git]
| [[Media: Artiphonie-Presentation_mi-parcours.pdf|Presentation intermédiaire]]
|-

!scope="row"| 9
| [[Quark Project]]
| CHALOYARD LUCAS, EL YANDOUZI ELIAS
| Olivier Gruber
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:Soutenance QuarkV3.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:Poster-xxx-en.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://git/xxx Dépot Git]
| [[Media:Soutenance QuarkV3.pdf|Presentation intermédiaire]]
|-

!scope="row"| 10
| [[Jorigine]]
| BLANQUET ANTOINE ('''Scrum Master'''), LANQUETIN ALEXIS ('''Chef de projet'''), MALECOT ETHAN, PRAT-CAPILLA HUGO
| Sylvain Delangue
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:Presentation_Projet_miparcours_S10.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:PosterJorigine2022_vfinal.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://git/xxx Dépot Git]
| [[Media:Presentation_Projet_miparcours_S10.pdf|Presentation intermédiaire]]
|-

!scope="row"| 11
| [[Contributions open source au projet EdCampus|EdCampus]]
| ANDRIEUX LIAM, COSOTTI KEVIN, DREZET LUCAS ('''Chef de projet'''), REGOUIN ROMAN ('''Scrum Master''')
| Anthony GEOURJON
| [XXXX Fiche]
| [[Rapport EDCampus 2021-2022|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [https://air.imag.fr/images/c/ca/Soutenance_interm%C3%A9diaire_-_EDCampus_2021-2022.pdf Presentation de mi-parcours] - [https://air.imag.fr/images/0/00/PosterFREDCampus20212022.pdf Poster FR] - [https://air.imag.fr/images/d/df/EDCampus_-_2021_2022.pdf Poster EN] - [https://air.imag.fr/images/d/d5/PitchEDCampus20212022.pdf Pitch]
| [https://gricad-gitlab.univ-grenoble-alpes.fr/edcampus Dépot Git]
| [https://air.imag.fr/images/c/ca/Soutenance_interm%C3%A9diaire_-_EDCampus_2021-2022.pdf Presentation intermédiaire]
|-

!scope="row"| 12
| [[Contributions open source au projet LabnBook|LabnBook]]
| CIRSTEA PAUL, SOULARD ALEXANDRE (Chef de projet), TONDEUX EMILIE (Scrum master), YUNG KEVIN
| Anthony GEOURJON, Cédric DHAM
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:LabnBook_Presentation_finale.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Flyer]] - [[Media:LabnBook.pdf|Presentation de mi-parcours]] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:Poster_GroupLabnBook_Cirstea_Soulard_Tondeux_Yung.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://git/xxx Dépot Git]
| [[Media:LabnBook.pdf|Presentation intermédiaire]]
|-

!scope="row"| 13
| [[Green collect]]
| BARET DORIAN, CAMBUS QUENTIN (Chef de projet), JULIENNE MALONE, MALLEN GUILLAUME (Scrum master)
| Bernard TOURANCHEAU
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [https://github.com/GreenCollects/docs/blob/main/soutenance/Soutenance%20de%20mi-parcours.pdf Presentation de mi-parcours] - [[Media:Poster-xxx-fr.pdf|Poster FR]] - [[Media:Poster-xxx-en.pdf|Poster EN]] - [https://tontube.fr Pitch 180 secondes]
| [https://github.com/GreenCollects Dépot Git]
| [https://github.com/GreenCollects/docs/blob/main/soutenance/Soutenance%20de%20mi-parcours.pdf Presentation intermédiaire]
|-

|}

Sujets non choisis

# [[LoRaWAN Roaming]] avec [[Chirpstack]], [[TheThingStack]] et [[Actility]] pour le projet [https://gricad-gitlab.univ-grenoble-alpes.fr/thingsat/public/-/blob/master/cubesat_mission/README.md Thingsat]: Didier DONSEZ, Olivier ALPHAND.
# [[Contributions logicielles au projet RIOT OS pour le New Space]] : Francois-Xavier MOLINA, Olivier ALPHAND, Didier DONSEZ
# [[Réseaux social d'organisation de sortie (saison 2)]] refonte [[Réseaux social d'organisation de sortie]], Olivier Richard
# [[Experiment Process Management]], Olivier Richard
# [[Language Server for Visual Studio]]: Olivier Gruber
# ABANDONNé [[Réseau d'Alumni de formations]] (à confirmer), Gérard POLLIER ([https://disrupt-campus.univ-grenoble-alpes.fr/design-factory-grenoble/ Design Factory Grenoble])
# [[Evaluation du kit IA embarqué Wio Terminal]]: Louis CLOSSON, Didier DONSEZ (sous réserve de réception du matériel commandé)

File:English Poster NixOS.pdf

2022-03-17T19:21:16Z

Titouan.Minier-Mancini:

File:Presentation mi parcours NixOs.pdf

2022-02-18T08:12:59Z

Titouan.Minier-Mancini: Titouan.Minier-Mancini uploaded a new version of File:Presentation mi parcours NixOs.pdf

Projets 2021-2022

2022-02-02T08:05:16Z

Titouan.Minier-Mancini: /* Affectations S10 */

<<[[Projets 2020-2021]] | [[Projets]] | [[Projets 2022-2023]]>>
=INFO=
==INFO3==

==INFO4==
===Projet Semestre S8===

Enseignants responsables : Olivier Richard

* Dates : Lundi après-midi, Mardi après-midi
* Lancement: 10 Janvier 2021 après midi
* Soutenance à mi-parcours: A définir
* Soutenance: A définir

* '''Evaluation à mi-parcours le lundi/mardi ???''': Format: 10min (5min de présentation 3 slides au plus, 5min de discussion). Cette évaluation sera prise en compte dans la note finale.

'''Consignes générales:'''

* '''Vous devez être pro-actifs !!!''': Si des points sont pas ou mals spécifiés, vous le faîtes et vous justifiez vos choix. Pour les problèmes techniques éventuels vous pouvez: creuser la question, contacter l'auteur du code si il y a lieu, écrire un rapport de bug ('''Attention:''' ca se prépare !), soumettre un patch/pull request, contacter l'enseignant ou la personne référente du projet.

* '''Vous devez maintenir une fiche de suivi de projet''': elle doit être mise à jour chaque semaine, elle rassemble les élements essentiels du projet, elle indique les évolutions du projet et présente sa feuille de route. '''Note:''' le nom de la fiche doit être composé du nom du projet et suffixé par info4_2021_2022. '''Cette fiche compte pour la note finale'''

* '''Votre code''' pour doit être hébergé sur le gitlab et à l'URL suivante https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22 , vous utiliserez votre compte UGA.

* Chaque projet doit avoir '''aux moins 2 dépôts git''':
** '''Un pour les documents''' demandés rapport, présentation de pré-soutenante, de soutenance, flyer. '''Il sera appelé documents.'''
** Un ou plusieurs pour le code, les tests, les évaluations, les preuves de concept, la ou les documentations afférentes.

* Les '''documents public doivent être rédigés en anglais (README, documentation, commentaires de code, nom de variables et de fonctions)'''. Le *rapport* sera aussi demandé en *anglais* (il fera la taille d'un rapport de TP). Les transparents des présentation peuvent être en anglais ou en francais, la soutenance sera taire en francais.

* '''La note obtenue''' tiendra compte du '''nombre et de la qualité des commits''' observé dans '''vos dépots git et la branche master''' (or depot documents). La qualité comprend l'intitulé du commit et son contenu. Les notes pourront être différentiées dans un groupe, il n'est pas acceptable de pas avoir de commit dans le(s) dépôt(s) du projet (or dépôt documents).

* Il est fortement conseillé de suivre un '''développement incrémental''' qui permette d'avoir à tout moment un démonstrateur à présenter, un projet peut être constituer d'une succession de '''démonstrateurs présentables séparément'''.

* Vous devez faire aussi des '''schémas d'architectures générales et/ou spéficiques, des diagrammes de séquence''', et autre documents de spécification si nécessaire. Ces documents vous serviront de base de discussion/brainstorming interne ainsi que dans vos différents documents (rapport, présentations, documentation). Ces schémas sont avant tout conceptuels et techniques.

===Propositions de projets S8===

* 1. [https://codimd.math.cnrs.fr/s/B029qfT5Q Courriels à Suppression Programmée] : Michaël Périn
* 2. [[Firmwares open source pour une station de réception de satellites pour l’Internet des Objets isolés]], Didier DONSEZ.
* 3. [[Evaluation du toolkit AI de STM32 pour l'analyse de l'environnement sonore]] (Suite 2022), Didier DONSEZ.
* 4. [[Algorithmes de géolocalisation d’objets par TDOA (Time Difference of Arrival)]] (suite), Didier DONSEZ.
* 5. [[Dashboard pour Overwatch]] Olivier Richard
* 6. [[Application mobile d'enregistrements de noeuds IoT LoRaWAN dans plusieurs réseaux]] (Suite) : Didier DONSEZ
* 7. [[Bluetooth 5.1 Angle of Arrival based Indoor Localization]] (Suite) : Didier DONSEZ
* 8. Intégration de composants de mesures environnementales (eau, air, ...) pour le [[Contribution au projet STM32Python|projet STM32Python]] à destination des lycéens: Didier DONSEZ
* 9. [[Air Quality Station]] (Suite) : Didier DONSEZ
* 10. [[Floating Water Quality Station]] : Didier DONSEZ, Nicolas PALIX
* 11. [[ASAC|Agriculture connectée]] en partenariat avec les projets collectifs IESE/MAT : Nicolas Palix
* 12. [[Testeur de terrain pour réseaux LoRaWAN privés et publics (TTN, CampusIoT et Helium)]] (suite 2021), Didier DONSEZ.
* 13. [[Géolocalition Indoor en LoRa 2.4GHz]], Didier DONSEZ.
* 14. [[RealWorld avec Dioxus]] (Rust + web), Olivier Richard
* 15. Poursuite projet 20-21 [[Rust Engine | Executeur de tâche en Rust]], Olivier Richard
* 16. Poursuite projet 20-21 [[Retrocompute simulateur | RetroComputing]]: (vintage style) Coupler le simulateur Digital avec un simulateur de processeur 8bits, Olivier Richard
* 17. Poursuite projet 19-20 [[Portail pour gestionnaire de taches]](react, Typescript), Olivier Richard
* 18. [[Paquets NIX pour Polytech]], Olivier Richard
* 19. [[Mini compilateur C pour mini CPU]], Olivier Richard
* 20. Mode jeu en réseau (Wifi/Bluetooth) pour [[TanksOfFreedom]], Nicolas Palix
* 21. [[Faults In Linux]], Nicolas Palix
* 22.
Non affecté
* xx. [[Bibliothèque de décodeurs standards et d'afficheurs Grafana pour objets connectés LoRaWAN]] : Didier DONSEZ

===Affectations===
{|class="wikitable alternance"
|+ Affectation des projets INFO4 21-22
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Enseignant(s)
!scope="col"| Fiche de suivi
!scope="col"| Documents
|-
!scope="row"| 1
| [[TODO]]
| CANIN CORENTIN,MONTEILLER JOSHUA,WAGNER SAM
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/01/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 2
| [[TODO]]
| CARMONA DAMIAN,DA COSTA TOM,WOZNY PIERRE-RAPHAE
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/02/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 3
| [[TODO]]
| BACH THOMAS,BARBE FLORENT,SIMO YOKAM GEORGES HARRISSO
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/03/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 5
| [[TODO]]
| CAILLES MAXIME,REYGNER ETIENNE,VERRIER MARTI
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/05/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 6
| [[TODO]]
| CHIOTTI MAEL,LAVIROTTE GAETAN,MOTTINO LORI
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/06/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 8
| [[TODO]]
| GUIRGUIS MIRETTE,HADIBY CHEMSSEDDINE,MOHSEN HACHE
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/08/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 10
| [[Floating Water Quality Station]]
| BRETON EMERIC,FAGHLOUMI AYMAN,VIALLET CAMILLE
| Didier DONSEZ, Nicolas PALIX
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/10/docs/-/blob/main/info4_2021_2022_Fiche_suivi_projet.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 13
| [[TODO]]
| BERNERD CLARA,JARDIN BAPTISTE,NGUYEN JUSTI
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/13/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 14
| [[TODO]]
| IFAKIREN SAMI,MONTHE DJEUMOU BRICE,NGUYEN CLEMEN
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/14/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 15
| [[TODO]]
| CHAPPAZ FLORIAN,DE OLIVEIRA VALENTIN,KURKLU FIKRE
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/15/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 17
| [[TODO]]
| KACHA TOM,MAHAMAN NOURY ABDOURAHAMANE,MEIGNEN HUGO,ZHANG KEMIN
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/17/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 18
| [[Paquets NIX pour Polytech]]
| CONJARD SAMUEL,FODOR GERGELY,PELISSE-VERDOUX CYPRIEN
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/18/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 19
| [[TODO]]
| CAPET THEO,POITEVIN EVE,ROYET JULIA
| TODO
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/19/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
!scope="row"| 20
| Mode jeu en réseau pour [[TanksOfFreedom]],
| ABECASSIS THOMAS,FOURNIER THOMAS,ZAFFUTO LUCA
| Nicolas Palix
| [https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/21-22/20/docs/README.md Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
|-
|}

==INFO5==
===Projet IoT S9===
Enseignants responsables : Bernard Tourancheau

Calendrier: Octobre à Décembre 2021. Soutenance 24 Janvier 2022.

{|class="wikitable alternance"
|+ Choix des projet des projets INFO5 Réseaux 21-22
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Documents
!scope="col"| Github/Trello
|-
!scope="row"| 1
| [[Réseau de capteur de dichlorométhane]]
| Dorian BARET - Malone JULIENNE - Quentin CAMBUS
| [https://lesjoiesducode.fr/quand-notre-revue-de-sprint-se-passe-nickel Fiche]
| [https://github.com/Cambus-Quentin/DichloWan2021/blob/main/README.md git]
|-
!scope="row"| 2
| [[Création d'un système pour localiser les élèves lors de courses d'orientation]]
| Antoine Gitton, Gilles Mertens, Bertrand Baudeur
| [[Media:2021_2022_INFO5_IOT_Orientation_spec.pdf|Spécification paquets LoRa]]
| [[Media:2021_2022_INFO5_IOT_Orientation_backend.zip|Souces back-end]] - [[Media:2021_2022_INFO5_IOT_Orientation_carte.zip|Souces carte]]
|-
!scope="row"| 3
| [[Harnais animalier permettant de suivre notre animal domestique]]
| Sami ELHADJI TCHIAMBOU, Corentin HUMBERT, Paul LAMBERT, Hugo PRAT CAPILLA
|
| [https://github.com/Bicorpro Organisation GitHub]
|-
!scope="row"| 4
| [[Géolocalisation et suivi des transports en commun]]
| Liam ANDRIEUX, Lucas DREZET, Roman REGOUIN
|
| [https://github.com/2021-2022-IoT-INFO5-G4 Organisation GitHub]
|-
!scope="row"| 5
| [[Tracking des déplacements de joueurs sur un terrain]]
| Elias EL YANDOUZI, Lucas CHALOYARD
||
|-
!scope="row"| 6
| [[Beer Pong connecté]]
| Yael PARA, Théo TEYSSIER, Victor MALOD, Alexis LANQUETIN
|
|
|}

Exposés points techniques 10' - questions 5'
* Nom Sujet
* ??? Python
* ??? MQTT
* ??? COAP
* 26/11/2021 - Elias El Yandouzi - Les différentes techniques de virtualisation

===Projet Semestre S10===

Enseignant responsable : [[user:Donsez|Didier Donsez]]

Convention des projets tutorés externes : Elise Didier.

Calendrier: 27/01 (8H30-12H00) au 18/03.

Séances de Management de projets innovants: A voir dessus.

Réunion de présentation et choix des sujets: 27/01 (8H30-12H00) en salle Polygone P206 (voir ADE)

Démarrage : 27/01

Soutenance à mi-parcours (à définir) : ??/02/2021 13H30-17H30 en distantiel (15 minutes par équipe).

Soutenance finale : 18/03/2021 (8H30-12H00 et 13H30-17H00). 30 minutes par équipe, questions/réponses et démonstration incluse. Prière de rapporter au fablab le matériel emprunté juste après votre soutenance.

====Séances MPI====

Voir ADE qui fait foi).

<pre>

</pre>

==== Soutenance intermédiaire S10 ====
Date (à définir): ??/02 Après midi. Distantiel (sur Zoom).

L'objectif de la soutenance intermédiaire est de vérifier si l'équipe projet est en bon ordre de marche. La présence du porteur n'est pas obligatoire. Prévoyez du temps pour les questions-réponses (5 minutes max).

L'équipe présentera en 5-6 transparents en 8 minutes.
* les équipiers et leurs rôles
* le contexte, le sujet et l'objectif du projet
* l'architecture du systèmes à réaliser
* les technologies utilisées
* le plan de travail (backlog, planning, ce qui est fait, ce qu'il reste à faire ...)
* les difficultés (s'il y a)

Respectez bien les créneaux indiqués (par respect pour les autres équipes).

==== Soutenance finale S10 ====
Date provisoire: 18/03/2022 (8H30-12H00 et 13H30-17H00).

'''La présence du(des) porteur(s) est obligatoire. Pensez à les prévenir bien à l'avance'''

Durée: 30 minutes par équipe: présentation, questions/réponses et démonstration incluse.

Les documents devront être en ligne sur le wiki (colonne Documents) la veille (ie avant le ??/03/2021 23:59:59 CET).

La présentation est constituée des chapitres suivants:
* Rappel du sujet/besoin et cahier des charges
* Technologies employées
* Architecture techniques
* Réalisations techniques
* Gestion de projet (méthode, planning prévisionnel et effectif, gestion des risques, rôles des membres ...)
* Outils (collaboration, CD/CI ...)
* Métriques logiciels : lignes de code, langages, performance, temps ingénieur (d'après vos journaux), la répartition des lignes de code et des commits en pourcentage entre les membres du projet ...)
* Conclusion (Retour d'expérience)
* Transparent expliquant la démonstration

L'ensemble des documents doit être accessible depuis le tableau ci-dessus et dans chaque fiche de suivi.

Le screencast (réalisé lors de la dernière répétition) sera rendu disponible via un partage caché (wetransfer, google drive …) dont le lien sera ajouté dans le devoir idoine sur Moodle et également envoyé par mail à votre tuteur.

Le rapport final contient les mêmes chapitres que la présentation ainsi qu'un glossaire et une bibliographie. Le rapport ne doit pas dépasser 15 pages (schémas et figures compris). Vous pourrez référencer les autres documents que vous avez produits au cours du projet (spécifications détaillées, algorithmes, conception d'écrans ...).

Le rapport final est au format Markdown et doit être placé dans un des dépôts Git de votre groupe/organisation.

NB: le rapport technique listé dans la colonne Documents contient tout ce qui ne tient pas dans les 15 pages du rapport final : cahier des charges, diagrammes UML, enquêtes utilisateurs design UI, API, technologies employées (détail), plan de tests, term of services, conformance RPGD, audits/diagnostiques sécurité, MTBR, rapport de vulnérabilité, plan de charge, rapports de charge, manuel d'installation … : ça dépend un peu de la nature de votre projet.

Conseil : 30 minutes c'est très court alors répétez la soutenance auparavant ! Prévoyez des transparents supplémentaires en annexe pour répondre aux questions.

'''Prière de rapporter au fablab le matériel emprunté juste après votre soutenance'''.

==== Affectations S10====
{|class="wikitable alternance"
|+ Affectation des projets INFO5 2021-2022
|-
|
!scope="col"| Sujet
!scope="col"| Etudiants
!scope="col"| Porteur(s)
!scope="col"| Fiche de suivi
!scope="col"| Documents
!scope="col"| Dépôt Git
!scope="col"| Soutenance intermédiaire
|-

!scope="row"| 1
| [[Test d'infrastructures avec NixOS]]
| HUMBERT CORENTIN, MINIER MANCINI TITOUAN (Chef de projet), SUEUR CORENTIN (Scrum master)
| Olivier RICHARD et Quentin GUILLETEAU
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
| [https://git/xxx Dépot Git]
| [[Media:xxx.pdf|Presentation intermédiaire]]
|-

!scope="row"| 2
| [[Plan dynamique d’un appartement connecté]]
| GRANGER OSCAR, NOERIE SOPHIE, SARRE MARGAUX, SALMON AMAD, TEYSSIER THEO
| Sybille CAFFIAU
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
| [https://git/xxx Dépot Git]
| [[Media:xxx.pdf|Presentation intermédiaire]]
|-

!scope="row"| 3
| [[Suivi de troupeaux (ovins, bovins) en zone montagneuse avec un réseau LoRaWAN : expérimentation dans la Matheysine]]
| GITTON ANTOINE, MALOD VICTOR, MUTEL MATHIS
| Fabrice FOREST
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
| [https://git/xxx Dépot Git]
| [[Media:xxx.pdf|Presentation intermédiaire]]
|-

!scope="row"| 4
| [[FitSize]]
| GEITNER TEVA , GONZALEZ JULES, PARA YAEL
| Fidèle Eya'a
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
| [https://git/xxx Dépot Git]
| [[Media:xxx.pdf|Presentation intermédiaire]]
|-

!scope="row"| 5
| [[GenderedNews]]
| AGUIAR MATHILDE (Chef de projet), HAJJI OUMAIMA (SCRUM Master), SIDIBE ROKIATOU DITE ROSE
| François PORTET, Gilles BASTIN, Ange RICHARD
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
| [https://git/xxx Dépot Git]
| [[Media:xxx.pdf|Presentation intermédiaire]]
|-

!scope="row"| 6
| [[Système d'analyse de traces sportives]]
| HERQUE ERIC (Scrum Master), VACHERIAS GUILLAUME (Chef de projet)
| Vivien QUEMA
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
| [https://git/xxx Dépot Git]
| [[Media:xxx.pdf|Presentation intermédiaire]]
|-

!scope="row"| 7
| [[Qualité de l'Air et Santé des Populations]]
| BAUDEUR BERTRAND (Scrum Master), MERTENS GILLES (Chef)
| Marie-Laure AIX
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
| [https://git/xxx Dépot Git]
| [[Media:xxx.pdf|Presentation intermédiaire]]
|-

!scope="row"| 8
| [[Artiphonie(saison 3)]] extension de la [[Artiphonie (saison 2)]]
| BUISINE JULIEN, ELHADJI TCHIAMBOU SAMI, LAMBERT DAPHNE (Scrum Master), LAMBERT PAUL
| Olivier Richard
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
| [https://git/xxx Dépot Git]
| [[Media:xxx.pdf|Presentation intermédiaire]]
|-

!scope="row"| 9
| [[Quark Project]]
| CHALOYARD LUCAS, EL YANDOUZI ELIAS
| Olivier Gruber
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
| [https://git/xxx Dépot Git]
| [[Media:xxx.pdf|Presentation intermédiaire]]
|-

!scope="row"| 10
| [[Jorigine]]
| BLANQUET ANTOINE, LANQUETIN ALEXIS, MALECOT ETHAN, PRAT-CAPILLA HUGO
| Sylvain Delangue
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
| [https://git/xxx Dépot Git]
| [[Media:xxx.pdf|Presentation intermédiaire]]
|-

!scope="row"| 11
| [[Contributions open source au projet EdCampus|EdCampus]]
| ANDRIEUX LIAM, COSOTTI KEVIN, DREZET LUCAS ('''Chef de projet'''), REGOUIN ROMAN ('''Scrum Master''')
| Anthony GEOURJON
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
| [https://git/xxx Dépot Git]
| [[Media:xxx.pdf|Presentation intermédiaire]]
|-

!scope="row"| 12
| [[Contributions open source au projet LabnBook|LabnBook]]
| CIRSTEA PAUL, SOULARD ALEXANDRE (Chef de projet), TONDEUX EMILIE (Scrum master), YUNG KEVIN
| Anthony GEOURJON, Cédric DHAM
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
| [https://git/xxx Dépot Git]
| [[Media:xxx.pdf|Presentation intermédiaire]]
|-

!scope="row"| 13
| [[Green collect]]
| BARET DORIAN, CAMBUS QUENTIN (Chef de projet), JULIENNE MALONE, MALLEN GUILLAUME (Scrum master)
| Bernard TOURANCHEAU
| [XXXX Fiche]
| [[Media:xxx.pdf|Rapport final]] - [[Media:xxx.pdf|Presentation finale FR]] - [[Media:xxx.pdf|Final Presentation EN]] - [[Media:xxx.pdf|Flyer]] - [[Media:xxx.pdf|Presentation de mi-parcours]]
| [https://github.com/malleng/Projet_S10 Dépot Git]
| [[Media:xxx.pdf|Presentation intermédiaire]]
|-

|}

Sujets non choisis

# [[LoRaWAN Roaming]] avec [[Chirpstack]], [[TheThingStack]] et [[Actility]] pour le projet [https://gricad-gitlab.univ-grenoble-alpes.fr/thingsat/public/-/blob/master/cubesat_mission/README.md Thingsat]: Didier DONSEZ, Olivier ALPHAND.
# [[Contributions logicielles au projet RIOT OS pour le New Space]] : Francois-Xavier MOLINA, Olivier ALPHAND, Didier DONSEZ
# [[Réseaux social d'organisation de sortie (saison 2)]] refonte [[Réseaux social d'organisation de sortie]], Olivier Richard
# [[Experiment Process Management]], Olivier Richard
# [[Language Server for Visual Studio]]: Olivier Gruber
# ABANDONNé [[Réseau d'Alumni de formations]] (à confirmer), Gérard POLLIER ([https://disrupt-campus.univ-grenoble-alpes.fr/design-factory-grenoble/ Design Factory Grenoble])
# [[Evaluation du kit IA embarqué Wio Terminal]]: Louis CLOSSON, Didier DONSEZ (sous réserve de réception du matériel commandé)

VT2021 Kind fiche

2021-11-29T09:55:30Z

Titouan.Minier-Mancini:

[https://kind.sigs.k8s.io/ KiND] est une solution pour déployer des clusters [https://kubernetes.io/ Kubernetes(K8S)] localement pour simplifier les processus de développement et de test.

[[File:Kind_logo.png|300px|thumb|right|Kind logo]]

= Présentation de KiND =

GITTON Antoine - antoine.gitton@etu.univ-grenoble-alpes.fr

MINIER MANCINI Titouan - titouan.minier-mancini@etu.univ-grenoble-alpes.fr

== Résumé ==

Kind est un outil permettant le déploiement de clusters Kubernetes dans un environnement local, en utilisant directement des conteneurs [https://docs.docker.com/ Docker] en tant que machine du cluster. Cet outil a été créé avec comme but principal de tester Kubernetes lui-même, mais il est maintenant très utilisé pour obtenir un cycle de développement et de tests end-to-end plus rapide, ainsi qu’une facilité de mise en place de CI (Continuous Integration). Dans un premier temps nous allons présenter l’architecture haut niveau de cette solution, pour ensuite discuter ses avantages et inconvénients, que l’on peut comparer à des concurrents comme [https://minikube.sigs.k8s.io Minikube].

Mot clés: Docker, Kubernetes, Conteneurs, Systèmes distribués, tests E2E

== Abstract ==

Kind is a tool that enables running Kubernetes clusters in a local environment, using [https://docs.docker.com/ Docker] containers as the nodes of the cluster. This tool was initially created with the main purpose of testing Kubernetes itself, but it is nowadays widely used to perform end-to-end testing and develop more efficiently, as well as ease the implementation of CI (Continuous Integration). In the first part, we will present the high level concepts of Kind architecture, then we will discuss pros and cons of such a solution in comparison with close concurrents like [https://minikube.sigs.k8s.io Minikube].

Keywords: Docker, Kubernetes, Containers, Distributed systems, E2E testing

== Synthèse ==

=== Mettre son infrastructure en bouteille ===

Kubernetes est un outil qui a pour objectif de partager des machines (noeud ou node) connectées en réseau entre plusieurs applications. Il permet d’automatiser le déploiement et la maintenance d’infrastructures décrites au travers de fichiers spécifiques (manifestes, yaml) par les ingénieurs. Ces infrastructures, nécessitant habituellement beaucoup de ressources (puissance de calcul, mémoire vive et stockage), sont la plupart du temps complexes. De ce fait, il est difficile de les tester dans un environnement réaliste (qui se rapproche de l'environnement de production) localement, donc sur une seule machine qui est limitée en termes de ressources.

C’est sur ce point que Kind propose une solution intéressante, car il permet de créer virtuellement des clusters qui peuvent imiter potentiellement tout cluster réel. On entend par là notamment la capacité de déployer des clusters multi-noeuds en n’utilisant fondamentalement qu’une seule machine physique. C’est de là que vient l’image de mettre son cluster Kubernetes en bouteille, environnement à échelle réduite qu’il est facile à manœuvrer.

Il simplifie alors le processus de test, puisqu’il donne accès à un environnement réaliste, mais qui reste local et donc plus léger et simple à manoeuvrer pour le testeur. Au delà du test, Kind donne accès à un environnement favorable au développement. Il est tout à fait compatible avec des solutions de développement pour Kubernetes, telles que [https://skaffold.dev/ Skaffold].

[[File:Kind_architecture.png|600px|thumb|right|Kind architecture]]

=== Architecture haut niveau ===

Kind, en tant que solution, incorpore différents composants. Il y a notamment la Command Line Interface (CLI) qui permet d'interagir avec le cluster, et l’image Docker du node. Cette image est le cœur du fonctionnement de Kind puisqu’elle fournit cet environnement dans lequel peut s'exécuter le cluster Kubernetes.

Cette image contient trois couches. La couche centrale est l’image de Ubuntu 21.10. Par dessus celle-ci il y a la couche de base implémentée par Kind pour fournir un environnement qui respecte l’API CRI. CRI (Container Runtime Interface) est une API définie par Kubernetes pour que le Kubelet du nœud puisse communiquer correctement avec le container runtime (containerd, CRI-O, etc). De plus cette couche doit permettre l’utilisation de conteneurs imbriqués, puisque Kubernetes utilisera des conteneurs en étant lui-même dans un conteneur. Concrètement cette couche intègre systemd, avec uniquement les services utiles, containerd, et d’autres paquets nécessaires au bon fonctionnement des composants du Kube.

Ensuite la troisième couche de l’image node est dédiée entièrement au fonctionnement de Kubernetes. Elle contient donc les composants du Kube avec [https://kubernetes.io/docs/reference/setup-tools/kubeadm/ Kubeadm] et [https://www.weave.works/oss/net/ Weave]. Kubeadm est un outil qui permet la mise en place facile et rapide d’un cluster Kubernetes minimum. Il déploie les composants du kube et gère les certificats pour assurer une bonne communication entre eux. Weave quant à lui est une implémentation de la CNI qui est une API définie par Kubernetes comme son modèle de networking. Weave fournit à Kubernetes un overlay sur le réseau sur lequel il peut faire communiquer ses pods au travers d’adresses IP.

=== Killer features et Minikube ===

Kind et Minikube sont tous deux des produits issus des [https://github.com/kubernetes-sigs K8S SIG (Special Interest Groups)], c'est-à-dire de la communauté autour de Kubernetes. De ce fait, on pourrait trouver étrange qu’une même communauté ait créé deux produits très similaires. Là où Kind se démarque très clairement de Minikube est en fait la capacité de déployer un cluster avec plusieurs nœuds, ce qui est absolument impossible avec Minikube.

“Pourquoi avoir besoin d’un cluster multi-nœuds ?” - C’est une question qu’il est légitime de se poser lorsque l’on souhaite choisir entre Kind et Minikube (ou autre). La différence fondamentale se situe dans la qualité réaliste de l'environnement utilisé.
En production, donc dans un “vrai” cluster, il est évident que plusieurs (voire énormément de) machines sont utilisées pour faire tourner l'infrastructure. De cette différence d'environnement naît un problème de réalisme, en effet le comportement des éléments dans le cluster peut être très différent selon que celui-ci ne contient qu’un nœud ou plusieurs. Il s’agit même de tout l’enjeu des systèmes distribués. Comment vérifier que ma base de données distribuée fonctionne alors que je n’ai qu’une seule machine ? Ce n’est pas possible, ou du moins c'est un problème difficile qui requerrait des outils suplémentaires, rajoutant à la charge du système.

Kind apporte cet environnement un maximum proche de celui de production en donnant la possibilité de choisir son nombre de nœuds. Dans le cadre de test end-to-end c’est une fonctionnalité absolument incroyable en comparaison de Minikube.

En revanche, il est intéressant de se poser la question dans le cadre du développement. Dans ce cas là cet aspect de réalisme n’est pas aussi important (à distinguer selon le contexte). Cela dit, Kind est également natif sur les systèmes Linux puisqu'il tourne dans des conteneurs Docker (natifs pour Linux et Windows servers). De ce fait, il est fondamentalement moins lourd que Minikube qui utilise une machine virtuelle. Bien sûr cela ne sera pas vrai si l’on déploie un cluster de dix nœuds avec Kind, qui deviendra alors plus consommateur en ressources.

== Mécanismes de simplification ==

=== 1. Image sideload ===

Tout cluster Kind possède son propre gestionnaire d’images Docker, il n’interfère pas avec celui de l’hôte. Il existe cependant un moyen de les interfacer, et ainsi charger une image de l’hôte vers les nœuds. Il permet aussi d’abstraire le niveau de gestionnaire d’image privés, afin de ne faire l’authentification qu’à un seul endroit (sur l’hôte). De manière générale, cela permet de ne pas avoir recours à un Docker registry pour partager ses images entre l’hôte et les nœuds.

=== 2. Attribution dynamique de volumes ===

Depuis 2019, Kind intègre une configuration de la solution “local-host-path” de Rancher. Celle-ci fournit une StorageClass qui assigne automatiquement des PV (Persistance Volume) au cluster à chaque PVC (Persistent Volume Claim) faite par des applications. De ce fait, le développeur n’a plus à se préoccuper de l’assignation des volumes sur son espace de stockage et peut se concentrer sur son activité principale.

=== 3. Contrôleur Ingress ===

Kind supporte des contrôleurs ingress, notamment Nginx, Contour et Ambassador. Pour les mettre en place il suffit d’appliquer leur manifeste avec Kubectl. Ces contrôleurs ingress permettent alors la création d’objets Ingress par les développeurs. Le contrôleur ingress gère notamment le routage des services en fonction de noms de DNS et chemin d’URL, et autorisent également l’utilisation du protocole TLS pour une communication en HTTPS.

=== 4. Load-balancing et MetalLB ===

Parmi les services Kubernetes, il existe les LoadBalancer. Ce type de service permet à chaque service de disposer d’une adresse IP qui sera accessible par l’extérieur du cluster au travers de ce load balancer. Cette solution est fournie par les cloud providers à la demande, toutefois lorsque l’on utilise un cluster bare-metal (comprendre sur ses propres machines) cette fonctionnalité n’est pas disponible sans implémentation supplémentaire. [https://metallb.universe.tf/ MetalLB] apporte une solution à ce problème, en créant un load balancer virtuel. Kind supporte parfaitement cette solution.

== Les limitations à considérer ==

=== 1. Mises à jours et rythme de développement ===

Kind est un outil développé par la communauté, et non pas l’équipe derrière Kubernetes lui-même. De ce fait l’effort mis dans son développement n’est pas le même. Le projet a démarré en 2018 et a suivi un rythme de mise à jour assez correct depuis. Il n'y a cependant pas eu de nouvelle release depuis mai 2021. A noter qu’il est en version 0.11.1, et n’a donc pas encore atteint sa version 1.0.

=== 2. Consommation en espace de stockage ===

Du fait de la manière dont il a été conçu, Kind consomme un espace disque important. En effet, pour chaque image utilisée dans le cluster, il est nécessaire d’en avoir une copie sur la machine hôte, ainsi que sur chaque nœud afin qu’ils puissent les démarrer. Il faut donc bien faire attention à la place restante sur la machine hôte.

L’espace utilisé est d’autant plus important que l’on utilise des solutions comme Skaffold qui produisent une grande quantité de volumes pour fournir du hot-reloading. On peut considérer que pour une dizaine de microservices sur quatre nœuds, l’espace disque nécessaire approche les 100 Go.

=== 3. Consommation en RAM et CPU ===

De plus, il faut se rappeler que l’utilisation de containers affecte (même si légèrement) les performances. Kubernetes est toujours un processus daemon qui se doit de fonctionner en arrière-plan sur chaque nœud, afin de répondre au mieux à l’état dans lequel se trouve le cluster.

Couplé avec Skaffold pour le développement par exemple, si l’on souhaite déployer de nombreux microservices, alors la quantité de RAM consommée grimpe en flèche, et est proportionnelle au nombre de nœuds utilisés. On peut considérer que pour une dizaine de microservices et quatre nœuds, la consommation en mémoire vive dépasse les 10 Go et il est préférable d’avoir un processeur puissant (8+ coeurs).

== Références ==

https://kind.sigs.k8s.io/ - Site web de Kind

https://github.com/kubernetes-sigs/kind/pull/1157 - Pull request PV

https://minikube.sigs.k8s.io/docs/ - Site web de Minikube

File:VT2021 Kind presentation.pdf

2021-11-28T22:04:59Z

Titouan.Minier-Mancini: Titouan.Minier-Mancini uploaded a new version of File:VT2021 Kind presentation.pdf

VT2021 Kind fiche

2021-11-28T18:25:40Z

Titouan.Minier-Mancini:

[https://kind.sigs.k8s.io/ KiND] est une solution pour déployer des clusters [https://kubernetes.io/ Kubernetes(K8S)] localement pour simplifier les processus de développement et de test.

[[File:Kind_logo.png|300px|thumb|right|Kind logo]]

= Présentation de KiND =

GITTON Antoine - antoine.gitton@etu.univ-grenoble-alpes.fr

MINIER MANCINI Titouan - titouan.minier-mancini@etu.univ-grenoble-alpes.fr

== Résumé ==

Kind est un outil permettant le déploiement de clusters Kubernetes dans un environnement local, en utilisant directement des conteneurs [https://docs.docker.com/ Docker] en tant que machine du cluster. Cet outil a été créé avec comme but principal de tester Kubernetes lui-même, mais il est maintenant très utilisé pour obtenir un cycle de développement et de tests end-to-end plus rapide, ainsi qu’une facilité de mise en place de CI (Continuous Integration). Dans un premier temps nous allons présenter l’architecture haut niveau de cette solution, pour ensuite discuter ses avantages et inconvénients, que l’on peut comparer à des concurrents comme [https://minikube.sigs.k8s.io Minikube].

Mot clés: Docker, Kubernetes, Conteneurs, Systèmes distribués, tests E2E

== Abstract ==

Kind is a tool that enables running Kubernetes clusters in a local environment, using [https://docs.docker.com/ Docker] containers as the nodes of the cluster. This tool was initially created with the main purpose of testing Kubernetes itself, but it is nowadays widely used to perform end-to-end testing and develop more efficiently, as well as ease the implementation of CI (Continuous Integration). In the first part, we will present the high level concepts of Kind architecture, then we will discuss pros and cons of such a solution in comparison with close concurrents like [https://minikube.sigs.k8s.io Minikube].

Keywords: Docker, Kubernetes, Containers, Distributed systems, E2E testing

== Synthèse ==

=== Mettre son infrastructure en bouteille ===

Kubernetes est un outil qui a pour objectif de partager des machines (noeud ou node) connectées en réseau entre plusieurs applications. Il permet d’automatiser le déploiement et la maintenance d’infrastructures décrites au travers de fichiers spécifiques (manifestes, yaml) par les ingénieurs. Ces infrastructures, nécessitant habituellement beaucoup de ressources (puissance de calcul, mémoire vive et stockage), sont la plupart du temps complexes. De ce fait, il est difficile de les tester dans un environnement réaliste (qui se rapproche de l'environnement de production) localement, donc sur une seule machine qui est limitée en termes de ressources.

C’est sur ce point que Kind propose une solution intéressante, car il permet de créer virtuellement des clusters qui peuvent imiter potentiellement tout cluster réel. On entend par là notamment la capacité de déployer des clusters multi-noeuds en n’utilisant fondamentalement qu’une seule machine physique. C’est de là que vient l’image de mettre son cluster Kubernetes en bouteille, environnement à échelle réduite qu’il est facile à manœuvrer.

Il simplifie alors le processus de test, puisqu’il donne accès à un environnement réaliste, mais qui reste local et donc plus léger et simple à manoeuvrer pour le testeur. Au delà du test, Kind donne accès à un environnement favorable au développement. Il est tout à fait compatible avec des solutions de développement pour Kubernetes, telles que [https://skaffold.dev/ Skaffold].

[[File:Kind_architecture.png|600px|thumb|right|Kind architecture]]

=== Architecture haut niveau ===

Kind, en tant que solution, incorpore différents composants. Il y a notamment la Command Line Interface (CLI) qui permet d'interagir avec le cluster, et l’image Docker du node. Cette image est le cœur du fonctionnement de Kind puisqu’elle fournit cet environnement dans lequel peut s'exécuter le cluster Kubernetes.

Cette image contient trois couches. La couche centrale est l’image de Ubuntu 21.10. Par dessus celle-ci il y a la couche de base implémentée par Kind pour fournir un environnement qui respecte l’API CRI. CRI (Container Runtime Interface) est une API définie par Kubernetes pour que le Kubelet du nœud puisse communiquer correctement avec le container runtime (containerd, CRI-O, etc). De plus cette couche doit permettre l’utilisation de conteneurs imbriqués, puisque Kubernetes utilisera des conteneurs en étant lui-même dans un conteneur. Concrètement cette couche intègre systemd, avec uniquement les services utiles, containerd, et d’autres paquets nécessaires au bon fonctionnement des composants du Kube.

Ensuite la troisième couche de l’image node est dédiée entièrement au fonctionnement de Kubernetes. Elle contient donc les composants du Kube avec [https://kubernetes.io/docs/reference/setup-tools/kubeadm/ Kubeadm] et [https://www.weave.works/oss/net/ Weave]. Kubeadm est un outil qui permet la mise en place facile et rapide d’un cluster Kubernetes minimum. Il déploie les composants du kube et gère les certificats pour assurer une bonne communication entre eux. Weave quant à lui est une implémentation de la CNI qui est une API définie par Kubernetes comme son modèle de networking. Weave fournit à Kubernetes un overlay sur le réseau sur lequel il peut faire communiquer ses pods au travers d’adresses IP.

=== Killer features et Minikube ===

Kind et Minikube sont tous deux des produits issus des [https://github.com/kubernetes-sigs K8S SIG (Special Interest Groups)], c'est -à -dire de la communauté autour de Kubernetes. De ce fait, on pourrait trouver étrange qu’une même communauté ait créé deux produits très similaires. Là où Kind se démarque très clairement de Minikube est en fait la capacité de déployer un cluster avec plusieurs nœuds, ce qui est absolument impossible avec Minikube.

“Pourquoi avoir besoin d’un cluster multi-nœuds ?” - C’est une question qu’il est légitime de se poser lorsque l’on souhaite choisir entre Kind et Minikube (ou autre). La différence fondamentale se situe dans la qualité réaliste de l'environnement utilisé.
En production, donc dans un “vrai” cluster, il est évident que plusieurs (voire énormément de) machines sont utilisées pour faire tourner l'infrastructure. De cette différence d'environnement naît un problème de réalisme, en effet le comportement des éléments dans le cluster peut être très différent selon que celui-ci ne contient qu’un nœud ou plusieurs. Il s’agit même de tout l’enjeu des systèmes distribués. Comment vérifier que ma base de données distribuée fonctionne alors que je n’ai qu’une seule machine ? Ce n’est pas possible.

Kind apporte cet environnement un maximum proche de celui de production en donnant la possibilité de choisir son nombre de nœuds. Dans le cadre de test end-to-end c’est une fonctionnalité absolument incroyable en comparaison de Minikube.

En revanche, il est intéressant de se poser la question dans le cadre du développement. Dans ce cas là cet aspect de réalisme n’est pas aussi important (à distinguer selon le contexte). Cela dit, Kind est également natif sur les systèmes Linux puisqu'il tourne dans des conteneurs Docker (natifs pour Linux et Windows servers). De ce fait, il est fondamentalement moins lourd que Minikube qui utilise une machine virtuelle. Bien sûr cela ne sera pas vrai si l’on déploie un cluster de dix nœuds avec Kind, qui deviendra alors plus consommateur en ressources.

== Mécanismes de simplification ==

=== 1. Image sideload ===

Tout cluster Kind possède son propre gestionnaire d’images Docker, il n’interfère pas avec celui de l’hôte. Il existe cependant un moyen de les interfacer, et ainsi charger une image de l’hôte vers les nœuds. Il permet aussi d’abstraire le niveau de gestionnaire d’image privés, afin de ne faire l’authentification qu’à un seul endroit (sur l’hôte). De manière générale, cela permet de ne pas avoir recours à un Docker registry pour partager ses images entre l’hôte et les nœuds.

=== 2. Attribution dynamique de volumes ===

Depuis 2019, Kind intègre une configuration de la solution “local-host-path” de Rancher. Celle-ci fournit une StorageClass qui assigne automatiquement des PV (Persistance Volume) au cluster à chaque PVC (Persistent Volume Claim) faite par des applications. De ce fait, le développeur n’a plus à se préoccuper de l’assignation des volumes sur son espace de stockage et peut se concentrer sur son activité principale.

=== 3. Contrôleur Ingress ===

Kind supporte des contrôleurs ingress, notamment Nginx, Contour et Ambassador. Pour les mettre en place il suffit d’appliquer leur manifeste avec Kubectl. Ces contrôleurs ingress permettent alors la création d’objets Ingress par les développeurs. Le contrôleur ingress gère notamment le routage des services en fonction de noms de DNS et chemin d’URL, et autorisent également l’utilisation du protocole TLS pour une communication en HTTPS.

=== 4. Load-balancing et MetalLB ===

Parmi les services Kubernetes, il existe les LoadBalancer. Ce type de service permet à chaque service de disposer d’une adresse IP qui sera accessible par l’extérieur du cluster au travers de ce load balancer. Cette solution est fournie par les cloud providers à la demande, toutefois lorsque l’on utilise un cluster bare-metal (comprendre sur ses propres machines) cette fonctionnalité n’est pas disponible sans implémentation supplémentaire. [https://metallb.universe.tf/ MetalLB] apporte une solution à ce problème, en créant un load balancer virtuel. Kind supporte parfaitement cette solution.

== Les limitations à considérer ==

=== 1. Mises à jours et rythme de développement ===

Kind est un outil développé par la communauté, et non pas l’équipe derrière Kubernetes lui-même. De ce fait l’effort mis dans son développement n’est pas le même. Le projet a démarré en 2018 et a suivi un rythme de mise à jour assez correct depuis. Il n'y a cependant pas eu de nouvelle release depuis mai 2021. A noter qu’il est en version 0.11.1, et n’a donc pas encore atteint sa version 1.0.

=== 2. Consommation en espace de stockage ===

Du fait de la manière dont il a été conçu, Kind consomme un espace disque important. En effet, pour chaque image utilisée dans le cluster, il est nécessaire d’en avoir une copie sur la machine hôte, ainsi que sur chaque nœud afin qu’ils puissent les démarrer. Il faut donc bien faire attention à la place restante sur la machine hôte.

L’espace utilisé est d’autant plus important que l’on utilise des solutions comme Skaffold qui produisent une grande quantité de volumes pour fournir du hot-reloading. On peut considérer que pour une dizaine de microservices sur quatre nœuds, l’espace disque nécessaire approche les 100 Go.

=== 3. Consommation en RAM et CPU ===

De plus, il faut se rappeler que l’utilisation de containers affecte (même si légèrement) les performances. Kubernetes est toujours un processus daemon qui se doit de fonctionner en arrière-plan sur chaque nœud, afin de répondre au mieux à l’état dans lequel se trouve le cluster.

Couplé avec Skaffold pour le développement par exemple, si l’on souhaite déployer de nombreux microservices, alors la quantité de RAM consommée grimpe en flèche, et est proportionnelle au nombre de nœuds utilisés. On peut considérer que pour une dizaine de microservices et quatre nœuds, la consommation en mémoire vive dépasse les 10 Go et il est préférable d’avoir un processeur puissant (8+ coeurs).

== Références ==

https://kind.sigs.k8s.io/ - Site web de Kind

https://github.com/kubernetes-sigs/kind/pull/1157 - Pull request PV

https://minikube.sigs.k8s.io/docs/ - Site web de Minikube

VT2021 Kind fiche

2021-11-28T17:35:50Z

Titouan.Minier-Mancini:

[https://kind.sigs.k8s.io/ KiND] est une solution pour déployer des clusters [https://kubernetes.io/ Kubernetes(K8S)] localement pour simplifier les processus de développement et de test.

[[File:Kind_logo.png|300px|thumb|right|Kind architecture]]

= Présentation de KiND =

GITTON Antoine - antoine.gitton@etu.univ-grenoble-alpes.fr

MINIER MANCINI Titouan - titouan.minier-mancini@etu.univ-grenoble-alpes.fr

== Résumé ==

Kind est un outil permettant le déploiement de clusters Kubernetes dans un environnement local, en utilisant directement des conteneurs [https://docs.docker.com/ Docker] en tant que machine du cluster. Cet outil a été créé avec comme but principal de tester Kubernetes lui-même, mais il est maintenant très utilisé pour obtenir un cycle de développement et de tests end-to-end plus rapide, ainsi qu’une facilité de mise en place de CI (Continuous Integration). Dans un premier temps nous allons présenter l’architecture haut niveau de cette solution, pour ensuite discuter ses avantages et inconvénients, que l’on peut comparer à des concurrents comme [https://minikube.sigs.k8s.io Minikube].

Mot clés: Docker, Kubernetes, Conteneurs, Systèmes distribués, tests E2E

== Abstract ==

Kind is a tool that enables running Kubernetes clusters in a local environment, using [https://docs.docker.com/ Docker] containers as the nodes of the cluster. This tool was initially created with the main purpose of testing Kubernetes itself, but it is nowadays widely used to perform end-to-end testing and develop more efficiently, as well as ease the implementation of CI (Continuous Integration). In the first part, we will present the high level concepts of Kind architecture, then we will discuss pros and cons of such a solution in comparison with close concurrents like [https://minikube.sigs.k8s.io Minikube].

Keywords: Docker, Kubernetes, Containers, Distributed systems, E2E testing

== Synthèse ==

=== Mettre son infrastructure en bouteille ===

Kubernetes est un outil qui a pour objectif de partager des machines (noeud ou node) connectées en réseau entre plusieurs applications. Il permet d’automatiser le déploiement et la maintenance d’infrastructures décrites au travers de fichiers spécifiques (manifestes, yaml) par les ingénieurs. Ces infrastructures, nécessitant habituellement beaucoup de ressources (puissance de calcul, mémoire vive et stockage), sont la plupart du temps complexes. De ce fait, il est difficile de les tester dans un environnement réaliste (qui se rapproche de l'environnement de production) localement, donc sur une seule machine qui est limitée en termes de ressources.

C’est sur ce point que Kind propose une solution intéressante, car il permet de créer virtuellement des clusters qui peuvent imiter potentiellement tout cluster réel. On entend par là notamment la capacité de déployer des clusters multi-noeuds en n’utilisant fondamentalement qu’une seule machine physique. C’est de là que vient l’image de mettre son cluster Kubernetes en bouteille, environnement à échelle réduite qu’il est facile à manœuvrer.

Il simplifie alors le processus de test, puisqu’il donne accès à un environnement réaliste, mais qui reste local et donc plus léger et simple à manoeuvrer pour le testeur. Au delà du test, Kind donne accès à un environnement favorable au développement. Il est tout à fait compatible avec des solutions de développement pour Kubernetes, telles que [https://skaffold.dev/ Skaffold].

[[File:Kind_architecture.png|600px|thumb|right|Kind architecture]]

=== Architecture haut niveau ===

Kind, en tant que solution, incorpore différents composants. Il y a notamment la Command Line Interface (CLI) qui permet d'interagir avec le cluster, et l’image Docker du node. Cette image est le cœur du fonctionnement de Kind puisqu’elle fournit cet environnement dans lequel peut s'exécuter le cluster Kubernetes.

Cette image contient trois couches. La couche centrale est l’image de Ubuntu 21.10. Par dessus celle-ci il y a la couche de base implémentée par Kind pour fournir un environnement qui respecte l’API CRI. CRI (Container Runtime Interface) est une API définie par Kubernetes pour que le Kubelet du nœud puisse communiquer correctement avec le container runtime (containerd, CRI-O, etc). De plus cette couche doit permettre l’utilisation de conteneurs imbriqués, puisque Kubernetes utilisera des conteneurs en étant lui-même dans un conteneur. Concrètement cette couche intègre systemd, avec uniquement les services utiles, containerd, et d’autres paquets nécessaires au bon fonctionnement des composants du Kube.

Ensuite la troisième couche de l’image node est dédiée entièrement au fonctionnement de Kubernetes. Elle contient donc les composants du Kube avec [https://kubernetes.io/docs/reference/setup-tools/kubeadm/ Kubeadm] et [https://www.weave.works/oss/net/ Weave]. Kubeadm est un outil qui permet la mise en place facile et rapide d’un cluster Kubernetes minimum. Il déploie les composants du kube et gère les certificats pour assurer une bonne communication entre eux. Weave quant à lui est une implémentation de la CNI qui est une API définie par Kubernetes comme son modèle de networking. Weave fournit à Kubernetes un overlay sur le réseau sur lequel il peut faire communiquer ses pods au travers d’adresses IP.

=== Killer features et Minikube ===

Kind et Minikube sont tous deux des produits issus des [https://github.com/kubernetes-sigs K8S SIG (Special Interest Groups)], c'est -à -dire de la communauté autour de Kubernetes. De ce fait, on pourrait trouver étrange qu’une même communauté ait créé deux produits très similaires. Là où Kind se démarque très clairement de Minikube est en fait la capacité de déployer un cluster avec plusieurs nœuds, ce qui est absolument impossible avec Minikube.

“Pourquoi avoir besoin d’un cluster multi-nœuds ?” - C’est une question qu’il est légitime de se poser lorsque l’on souhaite choisir entre Kind et Minikube (ou autre). La différence fondamentale se situe dans la qualité réaliste de l'environnement utilisé.
En production, donc dans un “vrai” cluster, il est évident que plusieurs (voire énormément de) machines sont utilisées pour faire tourner l'infrastructure. De cette différence d'environnement naît un problème de réalisme, en effet le comportement des éléments dans le cluster peut être très différent selon que celui-ci ne contient qu’un nœud ou plusieurs. Il s’agit même de tout l’enjeu des systèmes distribués. Comment vérifier que ma base de données distribuée fonctionne alors que je n’ai qu’une seule machine ? Ce n’est pas possible.

Kind apporte cet environnement un maximum proche de celui de production en donnant la possibilité de choisir son nombre de nœuds. Dans le cadre de test end-to-end c’est une fonctionnalité absolument incroyable en comparaison de Minikube.

En revanche, il est intéressant de se poser la question dans le cadre du développement. Dans ce cas là cet aspect de réalisme n’est pas aussi important (à distinguer selon le contexte). Cela dit, Kind est également natif sur les systèmes Linux puisqu'il tourne dans des conteneurs Docker (natifs pour Linux et Windows servers). De ce fait, il est fondamentalement moins lourd que Minikube qui utilise une machine virtuelle. Bien sûr cela ne sera pas vrai si l’on déploie un cluster de dix nœuds avec Kind, qui deviendra alors plus consommateur en ressources.

== Mécanismes de simplification ==

=== 1. Image sideload ===

Tout cluster Kind possède son propre gestionnaire d’images Docker, il n’interfère pas avec celui de l’hôte. Il existe cependant un moyen de les interfacer, et ainsi charger une image de l’hôte vers les nœuds. Il permet aussi d’abstraire le niveau de gestionnaire d’image privés, afin de ne faire l’authentification qu’à un seul endroit (sur l’hôte). De manière générale, cela permet de ne pas avoir recours à un Docker registry pour partager ses images entre l’hôte et les nœuds.

=== 2. Attribution dynamique de volumes ===

Depuis 2019, Kind intègre une configuration de la solution “local-host-path” de Rancher. Celle-ci fournit une StorageClass qui assigne automatiquement des PV (Persistance Volume) au cluster à chaque PVC (Persistent Volume Claim) faite par des applications. De ce fait, le développeur n’a plus à se préoccuper de l’assignation des volumes sur son espace de stockage et peut se concentrer sur son activité principale.

=== 3. Contrôleur Ingress ===

Kind supporte des contrôleurs ingress, notamment Nginx, Contour et Ambassador. Pour les mettre en place il suffit d’appliquer leur manifeste avec Kubectl. Ces contrôleurs ingress permettent alors la création d’objets Ingress par les développeurs. Le contrôleur ingress gère notamment le routage des services en fonction de noms de DNS et chemin d’URL, et autorisent également l’utilisation du protocole TLS pour une communication en HTTPS.

=== 4. Load-balancing et MetalLB ===

Parmi les services Kubernetes, il existe les LoadBalancer. Ce type de service permet à chaque service de disposer d’une adresse IP qui sera accessible par l’extérieur du cluster au travers de ce load balancer. Cette solution est fournie par les cloud providers à la demande, toutefois lorsque l’on utilise un cluster bare-metal (comprendre sur ses propres machines) cette fonctionnalité n’est pas disponible sans implémentation supplémentaire. [https://metallb.universe.tf/ MetalLB] apporte une solution à ce problème, en créant un load balancer virtuel. Kind supporte parfaitement cette solution.

== Les limitations à considérer ==

=== 1. Mises à jours et rythme de développement ===

Kind est un outil développé par la communauté, et non pas l’équipe derrière Kubernetes lui-même. De ce fait l’effort mis dans son développement n’est pas le même. Le projet a démarré en 2018 et a suivi un rythme de mise à jour assez correct depuis. Il n'y a cependant pas eu de nouvelle release depuis mai 2021. A noter qu’il est en version 0.11.1, et n’a donc pas encore atteint sa version 1.0.

=== 2. Consommation en espace de stockage ===

Du fait de la manière dont il a été conçu, Kind consomme un espace disque important. En effet, pour chaque image utilisée dans le cluster, il est nécessaire d’en avoir une copie sur la machine hôte, ainsi que sur chaque nœud afin qu’ils puissent les démarrer. Il faut donc bien faire attention à la place restante sur la machine hôte.

L’espace utilisé est d’autant plus important que l’on utilise des solutions comme Skaffold qui produisent une grande quantité de volumes pour fournir du hot-reloading. On peut considérer que pour une dizaine de microservices sur quatre nœuds, l’espace disque nécessaire approche les 100 Go.

=== 3. Consommation en RAM et CPU ===

De plus, il faut se rappeler que l’utilisation de containers affecte (même si légèrement) les performances. Kubernetes est toujours un processus daemon qui se doit de fonctionner en arrière-plan sur chaque nœud, afin de répondre au mieux à l’état dans lequel se trouve le cluster.

Couplé avec Skaffold pour le développement par exemple, si l’on souhaite déployer de nombreux microservices, alors la quantité de RAM consommée grimpe en flèche, et est proportionnelle au nombre de nœuds utilisés. On peut considérer que pour une dizaine de microservices et quatre nœuds, la consommation en mémoire vive dépasse les 10 Go et il est préférable d’avoir un processeur puissant (8+ coeurs).

== Références ==

https://kind.sigs.k8s.io/ - Site web de Kind

https://github.com/kubernetes-sigs/kind/pull/1157 - Pull request PV

https://minikube.sigs.k8s.io/docs/ - Site web de Minikube

VT2021 Kind fiche

2021-11-28T17:33:34Z

Titouan.Minier-Mancini:

[https://kind.sigs.k8s.io/ KiND] est une solution pour déployer des clusters [https://kubernetes.io/ Kubernetes(K8S)] localement pour simplifier les processus de développement et de test.

[[File:Kind_logo.png|300px|thumb|right|Kind architecture]]

= Présentation de KiND =

GITTON Antoine - antoine.gitton@etu.univ-grenoble-alpes.fr

MINIER MANCINI Titouan - titouan.minier-mancini@etu.univ-grenoble-alpes.fr

== Résumé ==

Kind est un outil permettant le déploiement de clusters Kubernetes dans un environnement local, en utilisant directement des conteneurs [https://docs.docker.com/ Docker] en tant que machine du cluster. Cet outil a été créé avec comme but principal de tester Kubernetes lui-même, mais il est maintenant très utilisé pour obtenir un cycle de développement et de tests end-to-end plus rapide, ainsi qu’une facilité de mise en place de CI (Continuous Integration). Dans un premier temps nous allons présenter l’architecture haut niveau de cette solution, pour ensuite discuter ses avantages et inconvénients, que l’on peut comparer à des concurrents comme [https://minikube.sigs.k8s.io Minikube].

Mot clés: Docker, Kubernetes, Conteneurs, Systèmes distribués, tests E2E

== Abstract ==

Kind is a tool that enables running Kubernetes clusters in a local environment, using [https://docs.docker.com/ Docker] containers as the nodes of the cluster. This tool was initially created with the main purpose of testing Kubernetes itself, but it is nowadays widely used to perform end-to-end testing and develop more efficiently, as well as ease the implementation of CI (Continuous Integration). In the first part, we will present the high level concepts of Kind architecture, then we will discuss pros and cons of such a solution in comparison with close concurrents like [https://minikube.sigs.k8s.io Minikube].

Keywords: Docker, Kubernetes, Containers, Distributed systems, E2E testing

== Synthèse ==

=== Mettre son infrastructure en bouteille ===

Kubernetes est un outil qui a pour objectif de partager des machines (noeud ou node) connectées en réseau entre plusieurs applications. Il permet d’automatiser le déploiement et la maintenance d’infrastructures décrites au travers de fichiers spécifiques (manifestes, yaml) par les ingénieurs. Ces infrastructures, nécessitant habituellement beaucoup de ressources (puissance de calcul, mémoire vive et stockage), sont la plupart du temps complexes. De ce fait, il est difficile de les tester dans un environnement réaliste (qui se rapproche de l'environnement de production) localement, donc sur une seule machine qui est limitée en termes de ressources.

C’est sur ce point que Kind propose une solution intéressante, car il permet de créer virtuellement des clusters qui peuvent imiter potentiellement tout cluster réel. On entend par là notamment la capacité de déployer des clusters multi-noeuds en n’utilisant fondamentalement qu’une seule machine physique. C’est de là que vient l’image de mettre son cluster Kubernetes en bouteille, environnement à échelle réduite qu’il est facile à manœuvrer.

Il simplifie alors le processus de test, puisqu’il donne accès à un environnement réaliste, mais qui reste local et donc plus léger et simple à manoeuvrer pour le testeur. Au delà du test, Kind donne accès à un environnement favorable au développement. Il est tout à fait compatible avec des solutions de développement pour Kubernetes, telles que [https://skaffold.dev/ Skaffold].

[[File:Kind_architecture.png|600px|thumb|right|Kind architecture]]

=== Architecture haut niveau ===

Kind, en tant que solution, incorpore différents composants. Il y a notamment la Command Line Interface (CLI) qui permet d'interagir avec le cluster, et l’image Docker du node. Cette image est le cœur du fonctionnement de Kind puisqu’elle fournit cet environnement dans lequel peut s'exécuter le cluster Kubernetes.

Cette image contient trois couches. La couche centrale est l’image de Ubuntu 21.10. Par dessus celle-ci il y a la couche de base implémentée par Kind pour fournir un environnement qui respecte l’API CRI. CRI (Container Runtime Interface) est une API définie par Kubernetes pour que le Kubelet du nœud puisse communiquer correctement avec le container runtime (containerd, CRI-O, etc). De plus cette couche doit permettre l’utilisation de conteneurs imbriqués, puisque Kubernetes utilisera des conteneurs en étant lui-même dans un conteneur. Concrètement cette couche intègre systemd, avec uniquement les services utiles, containerd, et d’autres paquets nécessaires au bon fonctionnement des composants du Kube.

Ensuite la troisième couche de l’image node est dédiée entièrement au fonctionnement de Kubernetes. Elle contient donc les composants du Kube avec Kubeadm et Weave. Kubeadm est un outil qui permet la mise en place facile et rapide d’un cluster Kubernetes minimum. Il déploie les composants du kube et gère les certificats pour assurer une bonne communication entre eux. Weave quant à lui est une implémentation de la CNI qui est une API définie par Kubernetes comme son modèle de networking. Weave fournit à Kubernetes un overlay sur le réseau sur lequel il peut faire communiquer ses pods au travers d’adresses IP.

=== Killer features et Minikube ===

Kind et Minikube sont tous deux des produits issus des K8S SIG (Special Interest Groups), c'est -à -dire de la communauté autour de Kubernetes. De ce fait, on pourrait trouver étrange qu’une même communauté ait créé deux produits très similaires. Là où Kind se démarque très clairement de Minikube est en fait la capacité de déployer un cluster avec plusieurs nœuds, ce qui est absolument impossible avec Minikube.

“Pourquoi avoir besoin d’un cluster multi-nœuds ?” - C’est une question qu’il est légitime de se poser lorsque l’on souhaite choisir entre Kind et Minikube (ou autre). La différence fondamentale se situe dans la qualité réaliste de l'environnement utilisé.
En production, donc dans un “vrai” cluster, il est évident que plusieurs (voire énormément de) machines sont utilisées pour faire tourner l'infrastructure. De cette différence d'environnement naît un problème de réalisme, en effet le comportement des éléments dans le cluster peut être très différent selon que celui-ci ne contient qu’un nœud ou plusieurs. Il s’agit même de tout l’enjeu des systèmes distribués. Comment vérifier que ma base de données distribuée fonctionne alors que je n’ai qu’une seule machine ? Ce n’est pas possible.

Kind apporte cet environnement un maximum proche de celui de production en donnant la possibilité de choisir son nombre de nœuds. Dans le cadre de test end-to-end c’est une fonctionnalité absolument incroyable en comparaison de Minikube.

En revanche, il est intéressant de se poser la question dans le cadre du développement. Dans ce cas là cet aspect de réalisme n’est pas aussi important (à distinguer selon le contexte). Cela dit, Kind est également natif sur les systèmes Linux puisqu'il tourne dans des conteneurs Docker (natifs pour Linux et Windows servers). De ce fait, il est fondamentalement moins lourd que Minikube qui utilise une machine virtuelle. Bien sûr cela ne sera pas vrai si l’on déploie un cluster de dix nœuds avec Kind, qui deviendra alors plus consommateur en ressources.

== Mécanismes de simplification ==

=== 1. Image sideload ===

Tout cluster Kind possède son propre gestionnaire d’images Docker, il n’interfère pas avec celui de l’hôte. Il existe cependant un moyen de les interfacer, et ainsi charger une image de l’hôte vers les nœuds. Il permet aussi d’abstraire le niveau de gestionnaire d’image privés, afin de ne faire l’authentification qu’à un seul endroit (sur l’hôte). De manière générale, cela permet de ne pas avoir recours à un Docker registry pour partager ses images entre l’hôte et les nœuds.

=== 2. Attribution dynamique de volumes ===

Depuis 2019, Kind intègre une configuration de la solution “local-host-path” de Rancher. Celle-ci fournit une StorageClass qui assigne automatiquement des PV (Persistance Volume) au cluster à chaque PVC (Persistent Volume Claim) faite par des applications. De ce fait, le développeur n’a plus à se préoccuper de l’assignation des volumes sur son espace de stockage et peut se concentrer sur son activité principale.

=== 3. Contrôleur Ingress ===

Kind supporte des contrôleurs ingress, notamment Nginx, Contour et Ambassador. Pour les mettre en place il suffit d’appliquer leur manifeste avec Kubectl. Ces contrôleurs ingress permettent alors la création d’objets Ingress par les développeurs. Le contrôleur ingress gère notamment le routage des services en fonction de noms de DNS et chemin d’URL, et autorisent également l’utilisation du protocole TLS pour une communication en HTTPS.

=== 4. Load-balancing et MetalLB ===

Parmi les services Kubernetes, il existe les LoadBalancer. Ce type de service permet à chaque service de disposer d’une adresse IP qui sera accessible par l’extérieur du cluster au travers de ce load balancer. Cette solution est fournie par les cloud providers à la demande, toutefois lorsque l’on utilise un cluster bare-metal (comprendre sur ses propres machines) cette fonctionnalité n’est pas disponible sans implémentation supplémentaire. [https://metallb.universe.tf/ MetalLB] apporte une solution à ce problème, en créant un load balancer virtuel. Kind supporte parfaitement cette solution.

== Les limitations à considérer ==

=== 1. Mises à jours et rythme de développement ===

Kind est un outil développé par la communauté, et non pas l’équipe derrière Kubernetes lui-même. De ce fait l’effort mis dans son développement n’est pas le même. Le projet a démarré en 2018 et a suivi un rythme de mise à jour assez correct depuis. Il n'y a cependant pas eu de nouvelle release depuis mai 2021. A noter qu’il est en version 0.11.1, et n’a donc pas encore atteint sa version 1.0.

=== 2. Consommation en espace de stockage ===

Du fait de la manière dont il a été conçu, Kind consomme un espace disque important. En effet, pour chaque image utilisée dans le cluster, il est nécessaire d’en avoir une copie sur la machine hôte, ainsi que sur chaque nœud afin qu’ils puissent les démarrer. Il faut donc bien faire attention à la place restante sur la machine hôte.

L’espace utilisé est d’autant plus important que l’on utilise des solutions comme Skaffold qui produisent une grande quantité de volumes pour fournir du hot-reloading. On peut considérer que pour une dizaine de microservices sur quatre nœuds, l’espace disque nécessaire approche les 100 Go.

=== 3. Consommation en RAM et CPU ===

De plus, il faut se rappeler que l’utilisation de containers affecte (même si légèrement) les performances. Kubernetes est toujours un processus daemon qui se doit de fonctionner en arrière-plan sur chaque nœud, afin de répondre au mieux à l’état dans lequel se trouve le cluster.

Couplé avec Skaffold pour le développement par exemple, si l’on souhaite déployer de nombreux microservices, alors la quantité de RAM consommée grimpe en flèche, et est proportionnelle au nombre de nœuds utilisés. On peut considérer que pour une dizaine de microservices et quatre nœuds, la consommation en mémoire vive dépasse les 10 Go et il est préférable d’avoir un processeur puissant (8+ coeurs).

== Références ==

https://kind.sigs.k8s.io/ - Site web de Kind

https://github.com/kubernetes-sigs/kind/pull/1157 - Pull request PV

https://minikube.sigs.k8s.io/docs/ - Site web de Minikube

VT2021 Kind fiche

2021-11-28T17:29:13Z

Titouan.Minier-Mancini:

[https://kind.sigs.k8s.io/ KiND] est une solution pour déployer des clusters [https://kubernetes.io/ Kubernetes(K8S)] localement pour simplifier les processus de développement et de test.

[[File:Kind_logo.png|300px|thumb|right|Kind architecture]]

= Présentation de KiND =

GITTON Antoine - antoine.gitton@etu.univ-grenoble-alpes.fr

MINIER MANCINI Titouan - titouan.minier-mancini@etu.univ-grenoble-alpes.fr

== Résumé ==

Kind est un outil permettant le déploiement de clusters Kubernetes dans un environnement local, en utilisant directement des conteneurs Docker en tant que machine du cluster. Cet outil a été créé avec comme but principal de tester Kubernetes lui-même, mais il est maintenant très utilisé pour obtenir un cycle de développement et de tests end-to-end plus rapide, ainsi qu’une facilité de mise en place de CI (Continuous Integration). Dans un premier temps nous allons présenter l’architecture haut niveau de cette solution, pour ensuite discuter ses avantages et inconvénients, que l’on peut comparer à des concurrents comme Minikube.

Mot clés: Docker, Kubernetes, Conteneurs, Systèmes distribués, tests E2E

== Abstract ==

Kind is a tool that enables running Kubernetes clusters in a local environment, using Docker containers as the nodes of the cluster. This tool was initially created with the main purpose of testing Kubernetes itself, but it is nowadays widely used to perform end-to-end testing and develop more efficiently, as well as ease the implementation of CI (Continuous Integration). In the first part, we will present the high level concepts of Kind architecture, then we will discuss pros and cons of such a solution in comparison with close concurrents like Minikube.

Keywords: Docker, Kubernetes, Containers, Distributed systems, E2E testing

== Synthèse ==

=== Mettre son infrastructure en bouteille ===

Kubernetes est un outil qui a pour objectif de partager des machines (noeud ou node) connectées en réseau entre plusieurs applications. Il permet d’automatiser le déploiement et la maintenance d’infrastructures décrites au travers de fichiers spécifiques (manifestes, yaml) par les ingénieurs. Ces infrastructures, nécessitant habituellement beaucoup de ressources (puissance de calcul, mémoire vive et stockage), sont la plupart du temps complexes. De ce fait, il est difficile de les tester dans un environnement réaliste (qui se rapproche de l'environnement de production) localement, donc sur une seule machine qui est limitée en termes de ressources.

C’est sur ce point que Kind propose une solution intéressante, car il permet de créer virtuellement des clusters qui peuvent imiter potentiellement tout cluster réel. On entend par là notamment la capacité de déployer des clusters multi-noeuds en n’utilisant fondamentalement qu’une seule machine physique. C’est de là que vient l’image de mettre son cluster Kubernetes en bouteille, environnement à échelle réduite qu’il est facile à manœuvrer.

Il simplifie alors le processus de test, puisqu’il donne accès à un environnement réaliste, mais qui reste local et donc plus léger et simple à manoeuvrer pour le testeur. Au delà du test, Kind donne accès à un environnement favorable au développement. Il est tout à fait compatible avec des solutions de développement pour Kubernetes, telles que Skaffold.

[[File:Kind_architecture.png|600px|thumb|right|Kind architecture]]

=== Architecture haut niveau ===

Kind, en tant que solution, incorpore différents composants. Il y a notamment la Command Line Interface (CLI) qui permet d'interagir avec le cluster, et l’image Docker du node. Cette image est le cœur du fonctionnement de Kind puisqu’elle fournit cet environnement dans lequel peut s'exécuter le cluster Kubernetes.

Cette image contient trois couches. La couche centrale est l’image de Ubuntu 21.10. Par dessus celle-ci il y a la couche de base implémentée par Kind pour fournir un environnement qui respecte l’API CRI. CRI (Container Runtime Interface) est une API définie par Kubernetes pour que le Kubelet du nœud puisse communiquer correctement avec le container runtime (containerd, CRI-O, etc). De plus cette couche doit permettre l’utilisation de conteneurs imbriqués, puisque Kubernetes utilisera des conteneurs en étant lui-même dans un conteneur. Concrètement cette couche intègre systemd, avec uniquement les services utiles, containerd, et d’autres paquets nécessaires au bon fonctionnement des composants du Kube.

Ensuite la troisième couche de l’image node est dédiée entièrement au fonctionnement de Kubernetes. Elle contient donc les composants du Kube avec Kubeadm et Weave. Kubeadm est un outil qui permet la mise en place facile et rapide d’un cluster Kubernetes minimum. Il déploie les composants du kube et gère les certificats pour assurer une bonne communication entre eux. Weave quant à lui est une implémentation de la CNI qui est une API définie par Kubernetes comme son modèle de networking. Weave fournit à Kubernetes un overlay sur le réseau sur lequel il peut faire communiquer ses pods au travers d’adresses IP.

=== Killer features et Minikube ===

Kind et Minikube sont tous deux des produits issus des K8S SIG (Special Interest Groups), c'est -à -dire de la communauté autour de Kubernetes. De ce fait, on pourrait trouver étrange qu’une même communauté ait créé deux produits très similaires. Là où Kind se démarque très clairement de Minikube est en fait la capacité de déployer un cluster avec plusieurs nœuds, ce qui est absolument impossible avec Minikube.

“Pourquoi avoir besoin d’un cluster multi-nœuds ?” - C’est une question qu’il est légitime de se poser lorsque l’on souhaite choisir entre Kind et Minikube (ou autre). La différence fondamentale se situe dans la qualité réaliste de l'environnement utilisé.
En production, donc dans un “vrai” cluster, il est évident que plusieurs (voire énormément de) machines sont utilisées pour faire tourner l'infrastructure. De cette différence d'environnement naît un problème de réalisme, en effet le comportement des éléments dans le cluster peut être très différent selon que celui-ci ne contient qu’un nœud ou plusieurs. Il s’agit même de tout l’enjeu des systèmes distribués. Comment vérifier que ma base de données distribuée fonctionne alors que je n’ai qu’une seule machine ? Ce n’est pas possible.

Kind apporte cet environnement un maximum proche de celui de production en donnant la possibilité de choisir son nombre de nœuds. Dans le cadre de test end-to-end c’est une fonctionnalité absolument incroyable en comparaison de Minikube.

En revanche, il est intéressant de se poser la question dans le cadre du développement. Dans ce cas là cet aspect de réalisme n’est pas aussi important (à distinguer selon le contexte). Cela dit, Kind est également natif sur les systèmes Linux puisqu'il tourne dans des conteneurs Docker (natifs pour Linux et Windows servers). De ce fait, il est fondamentalement moins lourd que Minikube qui utilise une machine virtuelle. Bien sûr cela ne sera pas vrai si l’on déploie un cluster de dix nœuds avec Kind, qui deviendra alors plus consommateur en ressources.

== Mécanismes de simplification ==

=== 1. Image sideload ===

Tout cluster Kind possède son propre gestionnaire d’images Docker, il n’interfère pas avec celui de l’hôte. Il existe cependant un moyen de les interfacer, et ainsi charger une image de l’hôte vers les nœuds. Il permet aussi d’abstraire le niveau de gestionnaire d’image privés, afin de ne faire l’authentification qu’à un seul endroit (sur l’hôte). De manière générale, cela permet de ne pas avoir recours à un Docker registry pour partager ses images entre l’hôte et les nœuds.

=== 2. Attribution dynamique de volumes ===

Depuis 2019, Kind intègre une configuration de la solution “local-host-path” de Rancher. Celle-ci fournit une StorageClass qui assigne automatiquement des PV (Persistance Volume) au cluster à chaque PVC (Persistent Volume Claim) faite par des applications. De ce fait, le développeur n’a plus à se préoccuper de l’assignation des volumes sur son espace de stockage et peut se concentrer sur son activité principale.

=== 3. Contrôleur Ingress ===

Kind supporte des contrôleurs ingress, notamment Nginx, Contour et Ambassador. Pour les mettre en place il suffit d’appliquer leur manifeste avec Kubectl. Ces contrôleurs ingress permettent alors la création d’objets Ingress par les développeurs. Le contrôleur ingress gère notamment le routage des services en fonction de noms de DNS et chemin d’URL, et autorisent également l’utilisation du protocole TLS pour une communication en HTTPS.

=== 4. Load-balancing et MetalLB ===

Parmi les services Kubernetes, il existe les LoadBalancer. Ce type de service permet à chaque service de disposer d’une adresse IP qui sera accessible par l’extérieur du cluster au travers de ce load balancer. Cette solution est fournie par les cloud providers à la demande, toutefois lorsque l’on utilise un cluster bare-metal (comprendre sur ses propres machines) cette fonctionnalité n’est pas disponible sans implémentation supplémentaire. MetalLB apporte une solution à ce problème, en créant un load balancer virtuel. Kind supporte parfaitement cette solution.

== Les limitations à considérer ==

=== 1. Mises à jours et rythme de développement ===

Kind est un outil développé par la communauté, et non pas l’équipe derrière Kubernetes lui-même. De ce fait l’effort mis dans son développement n’est pas le même. Le projet a démarré en 2018 et a suivi un rythme de mise à jour assez correct depuis. Il n'y a cependant pas eu de nouvelle release depuis mai 2021. A noter qu’il est en version 0.11.1, et n’a donc pas encore atteint sa version 1.0.

=== 2. Consommation en espace de stockage ===

Du fait de la manière dont il a été conçu, Kind consomme un espace disque important. En effet, pour chaque image utilisée dans le cluster, il est nécessaire d’en avoir une copie sur la machine hôte, ainsi que sur chaque nœud afin qu’ils puissent les démarrer. Il faut donc bien faire attention à la place restante sur la machine hôte.

L’espace utilisé est d’autant plus important que l’on utilise des solutions comme Skaffold qui produisent une grande quantité de volumes pour fournir du hot-reloading. On peut considérer que pour une dizaine de microservices sur quatre nœuds, l’espace disque nécessaire approche les 100 Go.

=== 3. Consommation en RAM et CPU ===

De plus, il faut se rappeler que l’utilisation de containers affecte (même si légèrement) les performances. Kubernetes est toujours un processus daemon qui se doit de fonctionner en arrière-plan sur chaque nœud, afin de répondre au mieux à l’état dans lequel se trouve le cluster.

Couplé avec Skaffold pour le développement par exemple, si l’on souhaite déployer de nombreux microservices, alors la quantité de RAM consommée grimpe en flèche, et est proportionnelle au nombre de nœuds utilisés. On peut considérer que pour une dizaine de microservices et quatre nœuds, la consommation en mémoire vive dépasse les 10 Go et il est préférable d’avoir un processeur puissant (8+ coeurs).

== Références ==

https://kind.sigs.k8s.io/ - Site web de Kind

https://github.com/kubernetes-sigs/kind/pull/1157 - Pull request PV

https://minikube.sigs.k8s.io/docs/ - Site web de Minikube

File:Kind logo.png

2021-11-28T17:23:35Z

Titouan.Minier-Mancini:

VT2021 Kind fiche

2021-11-28T17:22:08Z

Titouan.Minier-Mancini:

= Présentation de KiND =

GITTON Antoine - antoine.gitton@etu.univ-grenoble-alpes.fr

MINIER MANCINI Titouan - titouan.minier-mancini@etu.univ-grenoble-alpes.fr

== Résumé ==

Kind est un outil permettant le déploiement de clusters Kubernetes dans un environnement local, en utilisant directement des conteneurs Docker en tant que machine du cluster. Cet outil a été créé avec comme but principal de tester Kubernetes lui-même, mais il est maintenant très utilisé pour obtenir un cycle de développement et de tests end-to-end plus rapide, ainsi qu’une facilité de mise en place de CI (Continuous Integration). Dans un premier temps nous allons présenter l’architecture haut niveau de cette solution, pour ensuite discuter ses avantages et inconvénients, que l’on peut comparer à des concurrents comme Minikube.

Mot clés: Docker, Kubernetes, Conteneurs, Systèmes distribués, tests E2E

== Abstract ==

Kind is a tool that enables running Kubernetes clusters in a local environment, using Docker containers as the nodes of the cluster. This tool was initially created with the main purpose of testing Kubernetes itself, but it is nowadays widely used to perform end-to-end testing and develop more efficiently, as well as ease the implementation of CI (Continuous Integration). In the first part, we will present the high level concepts of Kind architecture, then we will discuss pros and cons of such a solution in comparison with close concurrents like Minikube.

Keywords: Docker, Kubernetes, Containers, Distributed systems, E2E testing

== Synthèse ==

=== Mettre son infrastructure en bouteille ===

Kubernetes est un outil qui a pour objectif de partager des machines (noeud ou node) connectées en réseau entre plusieurs applications. Il permet d’automatiser le déploiement et la maintenance d’infrastructures décrites au travers de fichiers spécifiques (manifestes, yaml) par les ingénieurs. Ces infrastructures, nécessitant habituellement beaucoup de ressources (puissance de calcul, mémoire vive et stockage), sont la plupart du temps complexes. De ce fait, il est difficile de les tester dans un environnement réaliste (qui se rapproche de l'environnement de production) localement, donc sur une seule machine qui est limitée en termes de ressources.

C’est sur ce point que Kind propose une solution intéressante, car il permet de créer virtuellement des clusters qui peuvent imiter potentiellement tout cluster réel. On entend par là notamment la capacité de déployer des clusters multi-noeuds en n’utilisant fondamentalement qu’une seule machine physique. C’est de là que vient l’image de mettre son cluster Kubernetes en bouteille, environnement à échelle réduite qu’il est facile à manœuvrer.

Il simplifie alors le processus de test, puisqu’il donne accès à un environnement réaliste, mais qui reste local et donc plus léger et simple à manoeuvrer pour le testeur. Au delà du test, Kind donne accès à un environnement favorable au développement. Il est tout à fait compatible avec des solutions de développement pour Kubernetes, telles que Skaffold.

[[File:Kind_architecture.png|600px|thumb|right|Kind architecture]]

=== Architecture haut niveau ===

Kind, en tant que solution, incorpore différents composants. Il y a notamment la Command Line Interface (CLI) qui permet d'interagir avec le cluster, et l’image Docker du node. Cette image est le cœur du fonctionnement de Kind puisqu’elle fournit cet environnement dans lequel peut s'exécuter le cluster Kubernetes.

Cette image contient trois couches. La couche centrale est l’image de Ubuntu 21.10. Par dessus celle-ci il y a la couche de base implémentée par Kind pour fournir un environnement qui respecte l’API CRI. CRI (Container Runtime Interface) est une API définie par Kubernetes pour que le Kubelet du nœud puisse communiquer correctement avec le container runtime (containerd, CRI-O, etc). De plus cette couche doit permettre l’utilisation de conteneurs imbriqués, puisque Kubernetes utilisera des conteneurs en étant lui-même dans un conteneur. Concrètement cette couche intègre systemd, avec uniquement les services utiles, containerd, et d’autres paquets nécessaires au bon fonctionnement des composants du Kube.

Ensuite la troisième couche de l’image node est dédiée entièrement au fonctionnement de Kubernetes. Elle contient donc les composants du Kube avec Kubeadm et Weave. Kubeadm est un outil qui permet la mise en place facile et rapide d’un cluster Kubernetes minimum. Il déploie les composants du kube et gère les certificats pour assurer une bonne communication entre eux. Weave quant à lui est une implémentation de la CNI qui est une API définie par Kubernetes comme son modèle de networking. Weave fournit à Kubernetes un overlay sur le réseau sur lequel il peut faire communiquer ses pods au travers d’adresses IP.

=== Killer features et Minikube ===

Kind et Minikube sont tous deux des produits issus des K8S SIG (Special Interest Groups), c'est -à -dire de la communauté autour de Kubernetes. De ce fait, on pourrait trouver étrange qu’une même communauté ait créé deux produits très similaires. Là où Kind se démarque très clairement de Minikube est en fait la capacité de déployer un cluster avec plusieurs nœuds, ce qui est absolument impossible avec Minikube.

“Pourquoi avoir besoin d’un cluster multi-nœuds ?” - C’est une question qu’il est légitime de se poser lorsque l’on souhaite choisir entre Kind et Minikube (ou autre). La différence fondamentale se situe dans la qualité réaliste de l'environnement utilisé.
En production, donc dans un “vrai” cluster, il est évident que plusieurs (voire énormément de) machines sont utilisées pour faire tourner l'infrastructure. De cette différence d'environnement naît un problème de réalisme, en effet le comportement des éléments dans le cluster peut être très différent selon que celui-ci ne contient qu’un nœud ou plusieurs. Il s’agit même de tout l’enjeu des systèmes distribués. Comment vérifier que ma base de données distribuée fonctionne alors que je n’ai qu’une seule machine ? Ce n’est pas possible.

Kind apporte cet environnement un maximum proche de celui de production en donnant la possibilité de choisir son nombre de nœuds. Dans le cadre de test end-to-end c’est une fonctionnalité absolument incroyable en comparaison de Minikube.

En revanche, il est intéressant de se poser la question dans le cadre du développement. Dans ce cas là cet aspect de réalisme n’est pas aussi important (à distinguer selon le contexte). Cela dit, Kind est également natif sur les systèmes Linux puisqu'il tourne dans des conteneurs Docker (natifs pour Linux et Windows servers). De ce fait, il est fondamentalement moins lourd que Minikube qui utilise une machine virtuelle. Bien sûr cela ne sera pas vrai si l’on déploie un cluster de dix nœuds avec Kind, qui deviendra alors plus consommateur en ressources.

== Mécanismes de simplification ==

=== 1. Image sideload ===

Tout cluster Kind possède son propre gestionnaire d’images Docker, il n’interfère pas avec celui de l’hôte. Il existe cependant un moyen de les interfacer, et ainsi charger une image de l’hôte vers les nœuds. Il permet aussi d’abstraire le niveau de gestionnaire d’image privés, afin de ne faire l’authentification qu’à un seul endroit (sur l’hôte). De manière générale, cela permet de ne pas avoir recours à un Docker registry pour partager ses images entre l’hôte et les nœuds.

=== 2. Attribution dynamique de volumes ===

Depuis 2019, Kind intègre une configuration de la solution “local-host-path” de Rancher. Celle-ci fournit une StorageClass qui assigne automatiquement des PV (Persistance Volume) au cluster à chaque PVC (Persistent Volume Claim) faite par des applications. De ce fait, le développeur n’a plus à se préoccuper de l’assignation des volumes sur son espace de stockage et peut se concentrer sur son activité principale.

=== 3. Contrôleur Ingress ===

Kind supporte des contrôleurs ingress, notamment Nginx, Contour et Ambassador. Pour les mettre en place il suffit d’appliquer leur manifeste avec Kubectl. Ces contrôleurs ingress permettent alors la création d’objets Ingress par les développeurs. Le contrôleur ingress gère notamment le routage des services en fonction de noms de DNS et chemin d’URL, et autorisent également l’utilisation du protocole TLS pour une communication en HTTPS.

=== 4. Load-balancing et MetalLB ===

Parmi les services Kubernetes, il existe les LoadBalancer. Ce type de service permet à chaque service de disposer d’une adresse IP qui sera accessible par l’extérieur du cluster au travers de ce load balancer. Cette solution est fournie par les cloud providers à la demande, toutefois lorsque l’on utilise un cluster bare-metal (comprendre sur ses propres machines) cette fonctionnalité n’est pas disponible sans implémentation supplémentaire. MetalLB apporte une solution à ce problème, en créant un load balancer virtuel. Kind supporte parfaitement cette solution.

== Les limitations à considérer ==

=== 1. Mises à jours et rythme de développement ===

Kind est un outil développé par la communauté, et non pas l’équipe derrière Kubernetes lui-même. De ce fait l’effort mis dans son développement n’est pas le même. Le projet a démarré en 2018 et a suivi un rythme de mise à jour assez correct depuis. Il n'y a cependant pas eu de nouvelle release depuis mai 2021. A noter qu’il est en version 0.11.1, et n’a donc pas encore atteint sa version 1.0.

=== 2. Consommation en espace de stockage ===

Du fait de la manière dont il a été conçu, Kind consomme un espace disque important. En effet, pour chaque image utilisée dans le cluster, il est nécessaire d’en avoir une copie sur la machine hôte, ainsi que sur chaque nœud afin qu’ils puissent les démarrer. Il faut donc bien faire attention à la place restante sur la machine hôte.

L’espace utilisé est d’autant plus important que l’on utilise des solutions comme Skaffold qui produisent une grande quantité de volumes pour fournir du hot-reloading. On peut considérer que pour une dizaine de microservices sur quatre nœuds, l’espace disque nécessaire approche les 100 Go.

=== 3. Consommation en RAM et CPU ===

De plus, il faut se rappeler que l’utilisation de containers affecte (même si légèrement) les performances. Kubernetes est toujours un processus daemon qui se doit de fonctionner en arrière-plan sur chaque nœud, afin de répondre au mieux à l’état dans lequel se trouve le cluster.

Couplé avec Skaffold pour le développement par exemple, si l’on souhaite déployer de nombreux microservices, alors la quantité de RAM consommée grimpe en flèche, et est proportionnelle au nombre de nœuds utilisés. On peut considérer que pour une dizaine de microservices et quatre nœuds, la consommation en mémoire vive dépasse les 10 Go et il est préférable d’avoir un processeur puissant (8+ coeurs).

== Références ==

https://kind.sigs.k8s.io/ - Site web de Kind

https://github.com/kubernetes-sigs/kind/pull/1157 - Pull request PV

https://minikube.sigs.k8s.io/docs/ - Site web de Minikube

VT2021 Kind fiche

2021-11-28T17:21:39Z

Titouan.Minier-Mancini:

= Présentation de KiND =

GITTON Antoine - antoine.gitton@etu.univ-grenoble-alpes.fr

MINIER MANCINI Titouan - titouan.minier-mancini@etu.univ-grenoble-alpes.fr

== Résumé ==

Kind est un outil permettant le déploiement de clusters Kubernetes dans un environnement local, en utilisant directement des conteneurs Docker en tant que machine du cluster. Cet outil a été créé avec comme but principal de tester Kubernetes lui-même, mais il est maintenant très utilisé pour obtenir un cycle de développement et de tests end-to-end plus rapide, ainsi qu’une facilité de mise en place de CI (Continuous Integration). Dans un premier temps nous allons présenter l’architecture haut niveau de cette solution, pour ensuite discuter ses avantages et inconvénients, que l’on peut comparer à des concurrents comme Minikube.

Mot clés: Docker, Kubernetes, Conteneurs, Systèmes distribués, tests E2E

== Abstract ==

Kind is a tool that enables running Kubernetes clusters in a local environment, using Docker containers as the nodes of the cluster. This tool was initially created with the main purpose of testing Kubernetes itself, but it is nowadays widely used to perform end-to-end testing and develop more efficiently, as well as ease the implementation of CI (Continuous Integration). In the first part, we will present the high level concepts of Kind architecture, then we will discuss pros and cons of such a solution in comparison with close concurrents like Minikube.

Keywords: Docker, Kubernetes, Containers, Distributed systems, E2E testing

== Synthèse ==

=== Mettre son infrastructure en bouteille ===

Kubernetes est un outil qui a pour objectif de partager des machines (noeud ou node) connectées en réseau entre plusieurs applications. Il permet d’automatiser le déploiement et la maintenance d’infrastructures décrites au travers de fichiers spécifiques (manifestes, yaml) par les ingénieurs. Ces infrastructures, nécessitant habituellement beaucoup de ressources (puissance de calcul, mémoire vive et stockage), sont la plupart du temps complexes. De ce fait, il est difficile de les tester dans un environnement réaliste (qui se rapproche de l'environnement de production) localement, donc sur une seule machine qui est limitée en termes de ressources.

C’est sur ce point que Kind propose une solution intéressante, car il permet de créer virtuellement des clusters qui peuvent imiter potentiellement tout cluster réel. On entend par là notamment la capacité de déployer des clusters multi-noeuds en n’utilisant fondamentalement qu’une seule machine physique. C’est de là que vient l’image de mettre son cluster Kubernetes en bouteille, environnement à échelle réduite qu’il est facile à manœuvrer.

Il simplifie alors le processus de test, puisqu’il donne accès à un environnement réaliste, mais qui reste local et donc plus léger et simple à manoeuvrer pour le testeur. Au delà du test, Kind donne accès à un environnement favorable au développement. Il est tout à fait compatible avec des solutions de développement pour Kubernetes, telles que Skaffold.

[[File:Kind_architecture.png|800px|thumb|left|Kind architecture]]

=== Architecture haut niveau ===

Kind, en tant que solution, incorpore différents composants. Il y a notamment la Command Line Interface (CLI) qui permet d'interagir avec le cluster, et l’image Docker du node. Cette image est le cœur du fonctionnement de Kind puisqu’elle fournit cet environnement dans lequel peut s'exécuter le cluster Kubernetes.

Cette image contient trois couches. La couche centrale est l’image de Ubuntu 21.10. Par dessus celle-ci il y a la couche de base implémentée par Kind pour fournir un environnement qui respecte l’API CRI. CRI (Container Runtime Interface) est une API définie par Kubernetes pour que le Kubelet du nœud puisse communiquer correctement avec le container runtime (containerd, CRI-O, etc). De plus cette couche doit permettre l’utilisation de conteneurs imbriqués, puisque Kubernetes utilisera des conteneurs en étant lui-même dans un conteneur. Concrètement cette couche intègre systemd, avec uniquement les services utiles, containerd, et d’autres paquets nécessaires au bon fonctionnement des composants du Kube.

Ensuite la troisième couche de l’image node est dédiée entièrement au fonctionnement de Kubernetes. Elle contient donc les composants du Kube avec Kubeadm et Weave. Kubeadm est un outil qui permet la mise en place facile et rapide d’un cluster Kubernetes minimum. Il déploie les composants du kube et gère les certificats pour assurer une bonne communication entre eux. Weave quant à lui est une implémentation de la CNI qui est une API définie par Kubernetes comme son modèle de networking. Weave fournit à Kubernetes un overlay sur le réseau sur lequel il peut faire communiquer ses pods au travers d’adresses IP.

=== Killer features et Minikube ===

Kind et Minikube sont tous deux des produits issus des K8S SIG (Special Interest Groups), c'est -à -dire de la communauté autour de Kubernetes. De ce fait, on pourrait trouver étrange qu’une même communauté ait créé deux produits très similaires. Là où Kind se démarque très clairement de Minikube est en fait la capacité de déployer un cluster avec plusieurs nœuds, ce qui est absolument impossible avec Minikube.

“Pourquoi avoir besoin d’un cluster multi-nœuds ?” - C’est une question qu’il est légitime de se poser lorsque l’on souhaite choisir entre Kind et Minikube (ou autre). La différence fondamentale se situe dans la qualité réaliste de l'environnement utilisé.
En production, donc dans un “vrai” cluster, il est évident que plusieurs (voire énormément de) machines sont utilisées pour faire tourner l'infrastructure. De cette différence d'environnement naît un problème de réalisme, en effet le comportement des éléments dans le cluster peut être très différent selon que celui-ci ne contient qu’un nœud ou plusieurs. Il s’agit même de tout l’enjeu des systèmes distribués. Comment vérifier que ma base de données distribuée fonctionne alors que je n’ai qu’une seule machine ? Ce n’est pas possible.

Kind apporte cet environnement un maximum proche de celui de production en donnant la possibilité de choisir son nombre de nœuds. Dans le cadre de test end-to-end c’est une fonctionnalité absolument incroyable en comparaison de Minikube.

En revanche, il est intéressant de se poser la question dans le cadre du développement. Dans ce cas là cet aspect de réalisme n’est pas aussi important (à distinguer selon le contexte). Cela dit, Kind est également natif sur les systèmes Linux puisqu'il tourne dans des conteneurs Docker (natifs pour Linux et Windows servers). De ce fait, il est fondamentalement moins lourd que Minikube qui utilise une machine virtuelle. Bien sûr cela ne sera pas vrai si l’on déploie un cluster de dix nœuds avec Kind, qui deviendra alors plus consommateur en ressources.

== Mécanismes de simplification ==

=== 1. Image sideload ===

Tout cluster Kind possède son propre gestionnaire d’images Docker, il n’interfère pas avec celui de l’hôte. Il existe cependant un moyen de les interfacer, et ainsi charger une image de l’hôte vers les nœuds. Il permet aussi d’abstraire le niveau de gestionnaire d’image privés, afin de ne faire l’authentification qu’à un seul endroit (sur l’hôte). De manière générale, cela permet de ne pas avoir recours à un Docker registry pour partager ses images entre l’hôte et les nœuds.

=== 2. Attribution dynamique de volumes ===

Depuis 2019, Kind intègre une configuration de la solution “local-host-path” de Rancher. Celle-ci fournit une StorageClass qui assigne automatiquement des PV (Persistance Volume) au cluster à chaque PVC (Persistent Volume Claim) faite par des applications. De ce fait, le développeur n’a plus à se préoccuper de l’assignation des volumes sur son espace de stockage et peut se concentrer sur son activité principale.

=== 3. Contrôleur Ingress ===

Kind supporte des contrôleurs ingress, notamment Nginx, Contour et Ambassador. Pour les mettre en place il suffit d’appliquer leur manifeste avec Kubectl. Ces contrôleurs ingress permettent alors la création d’objets Ingress par les développeurs. Le contrôleur ingress gère notamment le routage des services en fonction de noms de DNS et chemin d’URL, et autorisent également l’utilisation du protocole TLS pour une communication en HTTPS.

=== 4. Load-balancing et MetalLB ===

Parmi les services Kubernetes, il existe les LoadBalancer. Ce type de service permet à chaque service de disposer d’une adresse IP qui sera accessible par l’extérieur du cluster au travers de ce load balancer. Cette solution est fournie par les cloud providers à la demande, toutefois lorsque l’on utilise un cluster bare-metal (comprendre sur ses propres machines) cette fonctionnalité n’est pas disponible sans implémentation supplémentaire. MetalLB apporte une solution à ce problème, en créant un load balancer virtuel. Kind supporte parfaitement cette solution.

== Les limitations à considérer ==

=== 1. Mises à jours et rythme de développement ===

Kind est un outil développé par la communauté, et non pas l’équipe derrière Kubernetes lui-même. De ce fait l’effort mis dans son développement n’est pas le même. Le projet a démarré en 2018 et a suivi un rythme de mise à jour assez correct depuis. Il n'y a cependant pas eu de nouvelle release depuis mai 2021. A noter qu’il est en version 0.11.1, et n’a donc pas encore atteint sa version 1.0.

=== 2. Consommation en espace de stockage ===

Du fait de la manière dont il a été conçu, Kind consomme un espace disque important. En effet, pour chaque image utilisée dans le cluster, il est nécessaire d’en avoir une copie sur la machine hôte, ainsi que sur chaque nœud afin qu’ils puissent les démarrer. Il faut donc bien faire attention à la place restante sur la machine hôte.

L’espace utilisé est d’autant plus important que l’on utilise des solutions comme Skaffold qui produisent une grande quantité de volumes pour fournir du hot-reloading. On peut considérer que pour une dizaine de microservices sur quatre nœuds, l’espace disque nécessaire approche les 100 Go.

=== 3. Consommation en RAM et CPU ===

De plus, il faut se rappeler que l’utilisation de containers affecte (même si légèrement) les performances. Kubernetes est toujours un processus daemon qui se doit de fonctionner en arrière-plan sur chaque nœud, afin de répondre au mieux à l’état dans lequel se trouve le cluster.

Couplé avec Skaffold pour le développement par exemple, si l’on souhaite déployer de nombreux microservices, alors la quantité de RAM consommée grimpe en flèche, et est proportionnelle au nombre de nœuds utilisés. On peut considérer que pour une dizaine de microservices et quatre nœuds, la consommation en mémoire vive dépasse les 10 Go et il est préférable d’avoir un processeur puissant (8+ coeurs).

== Références ==

https://kind.sigs.k8s.io/ - Site web de Kind

https://github.com/kubernetes-sigs/kind/pull/1157 - Pull request PV

https://minikube.sigs.k8s.io/docs/ - Site web de Minikube

VT2021 Kind fiche

2021-11-28T17:19:26Z

Titouan.Minier-Mancini: /* Architecture haut niveau */

= Présentation de KiND =

GITTON Antoine - antoine.gitton@etu.univ-grenoble-alpes.fr

MINIER MANCINI Titouan - titouan.minier-mancini@etu.univ-grenoble-alpes.fr

== Résumé ==

Kind est un outil permettant le déploiement de clusters Kubernetes dans un environnement local, en utilisant directement des conteneurs Docker en tant que machine du cluster. Cet outil a été créé avec comme but principal de tester Kubernetes lui-même, mais il est maintenant très utilisé pour obtenir un cycle de développement et de tests end-to-end plus rapide, ainsi qu’une facilité de mise en place de CI (Continuous Integration). Dans un premier temps nous allons présenter l’architecture haut niveau de cette solution, pour ensuite discuter ses avantages et inconvénients, que l’on peut comparer à des concurrents comme Minikube.

Mot clés: Docker, Kubernetes, Conteneurs, Systèmes distribués, tests E2E

== Abstract ==

Kind is a tool that enables running Kubernetes clusters in a local environment, using Docker containers as the nodes of the cluster. This tool was initially created with the main purpose of testing Kubernetes itself, but it is nowadays widely used to perform end-to-end testing and develop more efficiently, as well as ease the implementation of CI (Continuous Integration). In the first part, we will present the high level concepts of Kind architecture, then we will discuss pros and cons of such a solution in comparison with close concurrents like Minikube.

Keywords: Docker, Kubernetes, Containers, Distributed systems, E2E testing

== Synthèse ==

=== Mettre son infrastructure en bouteille ===

Kubernetes est un outil qui a pour objectif de partager des machines (noeud ou node) connectées en réseau entre plusieurs applications. Il permet d’automatiser le déploiement et la maintenance d’infrastructures décrites au travers de fichiers spécifiques (manifestes, yaml) par les ingénieurs. Ces infrastructures, nécessitant habituellement beaucoup de ressources (puissance de calcul, mémoire vive et stockage), sont la plupart du temps complexes. De ce fait, il est difficile de les tester dans un environnement réaliste (qui se rapproche de l'environnement de production) localement, donc sur une seule machine qui est limitée en termes de ressources.

C’est sur ce point que Kind propose une solution intéressante, car il permet de créer virtuellement des clusters qui peuvent imiter potentiellement tout cluster réel. On entend par là notamment la capacité de déployer des clusters multi-noeuds en n’utilisant fondamentalement qu’une seule machine physique. C’est de là que vient l’image de mettre son cluster Kubernetes en bouteille, environnement à échelle réduite qu’il est facile à manœuvrer.

Il simplifie alors le processus de test, puisqu’il donne accès à un environnement réaliste, mais qui reste local et donc plus léger et simple à manoeuvrer pour le testeur. Au delà du test, Kind donne accès à un environnement favorable au développement. Il est tout à fait compatible avec des solutions de développement pour Kubernetes, telles que Skaffold.

=== Architecture haut niveau ===

Kind, en tant que solution, incorpore différents composants. Il y a notamment la Command Line Interface (CLI) qui permet d'interagir avec le cluster, et l’image Docker du node. Cette image est le cœur du fonctionnement de Kind puisqu’elle fournit cet environnement dans lequel peut s'exécuter le cluster Kubernetes.

Cette image contient trois couches. La couche centrale est l’image de Ubuntu 21.10. Par dessus celle-ci il y a la couche de base implémentée par Kind pour fournir un environnement qui respecte l’API CRI. CRI (Container Runtime Interface) est une API définie par Kubernetes pour que le Kubelet du nœud puisse communiquer correctement avec le container runtime (containerd, CRI-O, etc). De plus cette couche doit permettre l’utilisation de conteneurs imbriqués, puisque Kubernetes utilisera des conteneurs en étant lui-même dans un conteneur. Concrètement cette couche intègre systemd, avec uniquement les services utiles, containerd, et d’autres paquets nécessaires au bon fonctionnement des composants du Kube.

Ensuite la troisième couche de l’image node est dédiée entièrement au fonctionnement de Kubernetes. Elle contient donc les composants du Kube avec Kubeadm et Weave. Kubeadm est un outil qui permet la mise en place facile et rapide d’un cluster Kubernetes minimum. Il déploie les composants du kube et gère les certificats pour assurer une bonne communication entre eux. Weave quant à lui est une implémentation de la CNI qui est une API définie par Kubernetes comme son modèle de networking. Weave fournit à Kubernetes un overlay sur le réseau sur lequel il peut faire communiquer ses pods au travers d’adresses IP.

[[File:Kind_architecture.png|800px|thumb|left|Kind architecture]]

=== Killer features et Minikube ===

Kind et Minikube sont tous deux des produits issus des K8S SIG (Special Interest Groups), c'est -à -dire de la communauté autour de Kubernetes. De ce fait, on pourrait trouver étrange qu’une même communauté ait créé deux produits très similaires. Là où Kind se démarque très clairement de Minikube est en fait la capacité de déployer un cluster avec plusieurs nœuds, ce qui est absolument impossible avec Minikube.

“Pourquoi avoir besoin d’un cluster multi-nœuds ?” - C’est une question qu’il est légitime de se poser lorsque l’on souhaite choisir entre Kind et Minikube (ou autre). La différence fondamentale se situe dans la qualité réaliste de l'environnement utilisé.
En production, donc dans un “vrai” cluster, il est évident que plusieurs (voire énormément de) machines sont utilisées pour faire tourner l'infrastructure. De cette différence d'environnement naît un problème de réalisme, en effet le comportement des éléments dans le cluster peut être très différent selon que celui-ci ne contient qu’un nœud ou plusieurs. Il s’agit même de tout l’enjeu des systèmes distribués. Comment vérifier que ma base de données distribuée fonctionne alors que je n’ai qu’une seule machine ? Ce n’est pas possible.

Kind apporte cet environnement un maximum proche de celui de production en donnant la possibilité de choisir son nombre de nœuds. Dans le cadre de test end-to-end c’est une fonctionnalité absolument incroyable en comparaison de Minikube.

En revanche, il est intéressant de se poser la question dans le cadre du développement. Dans ce cas là cet aspect de réalisme n’est pas aussi important (à distinguer selon le contexte). Cela dit, Kind est également natif sur les systèmes Linux puisqu'il tourne dans des conteneurs Docker (natifs pour Linux et Windows servers). De ce fait, il est fondamentalement moins lourd que Minikube qui utilise une machine virtuelle. Bien sûr cela ne sera pas vrai si l’on déploie un cluster de dix nœuds avec Kind, qui deviendra alors plus consommateur en ressources.

== Mécanismes de simplification ==

=== 1. Image sideload ===

Tout cluster Kind possède son propre gestionnaire d’images Docker, il n’interfère pas avec celui de l’hôte. Il existe cependant un moyen de les interfacer, et ainsi charger une image de l’hôte vers les nœuds. Il permet aussi d’abstraire le niveau de gestionnaire d’image privés, afin de ne faire l’authentification qu’à un seul endroit (sur l’hôte). De manière générale, cela permet de ne pas avoir recours à un Docker registry pour partager ses images entre l’hôte et les nœuds.

=== 2. Attribution dynamique de volumes ===

Depuis 2019, Kind intègre une configuration de la solution “local-host-path” de Rancher. Celle-ci fournit une StorageClass qui assigne automatiquement des PV (Persistance Volume) au cluster à chaque PVC (Persistent Volume Claim) faite par des applications. De ce fait, le développeur n’a plus à se préoccuper de l’assignation des volumes sur son espace de stockage et peut se concentrer sur son activité principale.

=== 3. Contrôleur Ingress ===

Kind supporte des contrôleurs ingress, notamment Nginx, Contour et Ambassador. Pour les mettre en place il suffit d’appliquer leur manifeste avec Kubectl. Ces contrôleurs ingress permettent alors la création d’objets Ingress par les développeurs. Le contrôleur ingress gère notamment le routage des services en fonction de noms de DNS et chemin d’URL, et autorisent également l’utilisation du protocole TLS pour une communication en HTTPS.

=== 4. Load-balancing et MetalLB ===

Parmi les services Kubernetes, il existe les LoadBalancer. Ce type de service permet à chaque service de disposer d’une adresse IP qui sera accessible par l’extérieur du cluster au travers de ce load balancer. Cette solution est fournie par les cloud providers à la demande, toutefois lorsque l’on utilise un cluster bare-metal (comprendre sur ses propres machines) cette fonctionnalité n’est pas disponible sans implémentation supplémentaire. MetalLB apporte une solution à ce problème, en créant un load balancer virtuel. Kind supporte parfaitement cette solution.

== Les limitations à considérer ==

=== 1. Mises à jours et rythme de développement ===

Kind est un outil développé par la communauté, et non pas l’équipe derrière Kubernetes lui-même. De ce fait l’effort mis dans son développement n’est pas le même. Le projet a démarré en 2018 et a suivi un rythme de mise à jour assez correct depuis. Il n'y a cependant pas eu de nouvelle release depuis mai 2021. A noter qu’il est en version 0.11.1, et n’a donc pas encore atteint sa version 1.0.

=== 2. Consommation en espace de stockage ===

Du fait de la manière dont il a été conçu, Kind consomme un espace disque important. En effet, pour chaque image utilisée dans le cluster, il est nécessaire d’en avoir une copie sur la machine hôte, ainsi que sur chaque nœud afin qu’ils puissent les démarrer. Il faut donc bien faire attention à la place restante sur la machine hôte.

L’espace utilisé est d’autant plus important que l’on utilise des solutions comme Skaffold qui produisent une grande quantité de volumes pour fournir du hot-reloading. On peut considérer que pour une dizaine de microservices sur quatre nœuds, l’espace disque nécessaire approche les 100 Go.

=== 3. Consommation en RAM et CPU ===

De plus, il faut se rappeler que l’utilisation de containers affecte (même si légèrement) les performances. Kubernetes est toujours un processus daemon qui se doit de fonctionner en arrière-plan sur chaque nœud, afin de répondre au mieux à l’état dans lequel se trouve le cluster.

Couplé avec Skaffold pour le développement par exemple, si l’on souhaite déployer de nombreux microservices, alors la quantité de RAM consommée grimpe en flèche, et est proportionnelle au nombre de nœuds utilisés. On peut considérer que pour une dizaine de microservices et quatre nœuds, la consommation en mémoire vive dépasse les 10 Go et il est préférable d’avoir un processeur puissant (8+ coeurs).

== Références ==

https://kind.sigs.k8s.io/ - Site web de Kind

https://github.com/kubernetes-sigs/kind/pull/1157 - Pull request PV

https://minikube.sigs.k8s.io/docs/ - Site web de Minikube

File:Kind architecture.png

2021-11-28T17:17:56Z

Titouan.Minier-Mancini:

File:VT2021 Kind presentation.pdf

2021-11-28T17:12:33Z

Titouan.Minier-Mancini: