devrel-workshop / 101-ai-and-py Goto Github PK

Lorsqu'une commande affiche une liste, par exemple ovhai app list, faire un pipe pour que cela n'affiche que les informations de l'attendee.

De même pour AI Notebook et AI Training.

L'upload / fabrication ds images peut être long, pour palier à cela préparer deux images prêtes à l'emploi:

• ubf2r2if.c1.gra9.container-registry.ovh.net/lab/speaker/yolov8-rock-paper-scissors-training-job:1.0.0
• ubf2r2if.c1.gra9.container-registry.ovh.net/lab/speaker/yolov8-rock-paper-scissors-app

L'idée est de pouvoir les utiliser lors de la création du job AI Training ou de l'application AI Deploy

Pour éviter les erreurs de manipulation lors de la création des notebooks par les participant·es : les générer en amont.

--> Voir le code d'Eléa permettant la génération de Notebooks.

Au lancement de l'application une stacktrace apparaît:

File "/usr/local/lib/python3.8/site-packages/streamlit/runtime/scriptrunner/script_runner.py", line 552, in _run_script
    exec(code, module.__dict__)
File "/workspace/app.py", line 25, in <module>
    photoPath = save_photo(img_file_buffer)
File "/workspace/app.py", line 7, in save_photo
    photoAbsolutePath = '/workspace/data/rock-paper-scissors/app/' + photo.name

Comme discuté entre nous déplacer le repo dans le repo officiel des exemples OVHcloud

Utiliser le domain labdevrel.ovh pour fabriquer une URL user friendly pointant sur l'app QUarkus délivrant les configurations : http://labdevrel.ovh/lab-101-ia

Sur l'app avoir deux cadre pour prendre une photo puis une fois les photos prises déterminer qui a gagner à pierre / feuille / ciseaux.

• retirer la création via CLI (la laisser pour information)
• ajouter plus de détail sur ce qui a été pré-cré
• utiliser a CLI pour avoir les infos du Notebook à utiliser

L'app ne fonctionne pas lorsqu'elle est lancée en mode local avec Gitpod, elle fait "rien".

En regardant les logs j'ai l'impression que c'est un problème de CORS

Il est possible d'utiliser la shared registry des produit IA plutôt qu'un Harbor pour stocker les images.
L'avantage : pas de harbor à configurer ni de comptes.
A voir si on veut utiliser ça.

Le path de sortie de l'entraînement n'est pas positionné ce qui fait que l'on ne maitrise pas l'endroit où sont générés les fichiers de run / prédictions.

Le positionner pour rendre la cellule d'affichage des graphs opérationnelle à coup sûr.

Si la CLI essaie de se mettre à jour on a un message d'erreur:

✔ Downloading new version 3.20.0
  14.06 MiB @ 40.31 MiB/s                                                                                                                                                                                                                                      
✘ IO error: Permission denied (os error 13)

Je pense qu'il faudrait pouvoir la mettre à jour ou au moins avoir la dernière version dans l'image

Pour savoir dans quel ordre suivre les documents il faut les réordonner soit en les numérotant soit en les fusionnants dans un seul document.

Pour AI Training et AI Deploy pusher les images dans la registry Harbor OVHcloud plutôt que Dockerhub.

Et mettre à jour les param de lancement avec ovhai.

Expliquer ce que c'est + Gitpod et comment l'utiliser pour le lab

L’entraînement du modèle met 1h, préparer un modèle dans un object storage pour l'application finale ou essayer de diminuer le nombre d'epochs.

Le workspace par défaut de GitPod offre 30 Go d'espace.
Ce n'est pas assez pour construire l'image d’entraînement et l'image applicative.

A voir si on peut avoir plus de disque, en solution de contournement documenter le "nettoyage"

• S3 de secours
• Notebook
• Training
• App

Suite au changement de déroulé et d'utilisation du script de Hackathon il faut modifier le script d'init:

• supprimer ce qui est en lien avec le user openstack
• ajouter la récupération de WORKSHOP_NAME
• ajoute la récupération de AI_TOKEN

Ajouter la possibilité de créer les buckets S3 en python dans le script Hackathon

Rassembler l'ensemble des liens utiles dans une seule doc avec une seule URL pour que les personnes puissent s'y référer.

Dans le Dockerfile la CLI ovhai est bien installé, le PATH mis à jour mais pas reloadé je pense.

Running this script will download the ovhai binary and add it to your PATH.
The ovhai CLI upgrades itself automatically when you use it.
To uninstall, simply delete the ovhai binary.

Downloading archive from https://cli.gra.training.ai.cloud.ovh.net/ovhai-linux.zip...
Installing ovhai to /home/gitpod/bin...
Updating PATH variable, please open a new terminal or run "source $HOME/.bashrc"
Installation done!

Cela nous oblige à utiliser le chemin absolu, ce serait plus pratique, je pense, de pouvoir utiliser directement ovhai sans mettre de chemin devant.

Quelques slides pour présenter Python + liens avec le lab

Le schéma d'archi sur les slides n'est plus à jour: indiqué un seul object storage

L'idée ici est d'éviter d'avoir à taper des URL / comptes / passwords / ... lors du workshop.
De mémoire GitPod permet de définir des variables qui sont ensuite accessibles comme variables d'environnement.

Il faudrait donc rajouter dans la doc de démarrage / init la création de ces variables.
Un début de liste (non exhaustive) si tu es ok sur le principe @titimoby :

• STUDENT_ID : identifiant unique de la participante ou du participant (réutiliser qd il faut identfiier de manière unique des éléments, par ex le nom des images dans Harbor)
• OVH_AI_TOKEN : token permettant d'accéder à la CLI et aux Notebooks
• REGISTRY_NAME : URL de la registry Harbor à utiliser, par ex: .gra7.container-registry.ovh.net/workshop_ia
• REGISTRY_LOGIN : login pour faire un push / pull sur la registry
• REGISTRY_PASSWORD : mot de passe du compte pour faire un push / pull sur la registry

Afin d'éviter le curl à chaque chargement du workspace par Gitpod tester la présence du fichier attendee.json et le re-loader à la place du CURL si il est présent.

Remplacer les object container storage Swift par des S3.

Avant de modifier les scripts Terraform vérifier si les scripts de création d’environnement d'Eléa crée ou pas les objets.

J'ai fait le choix de mettre 101-ai-lab partout sur les noms des ressources (objects storage, notebook ,training, app, ...) mais je me rends compte qu'en reprenant le tuto rock-paper-scissors j'ai pas mal de renommage à faire et que ce n'est pas forcément plus clair que cela s'appelle 101-ai-lab partout.

@titimoby si ça e vas je vais voir si ce n'est pas trop galère à détricoter mais je mettrais bien rock-paper-scissors pour faciliter la future maintenance / évolution du lab.
Notamment en ayant un seul référentiel de sources et pas 3 comme aujourd'hui (lab, démo dans GL, ai-training-examples).

Plutôt que de prendre des photos, nous pourrions afficher les détections de YOLO directement sur le flux vidéo (si Streamlit ne l'empêche pas). Cela rendrait l'application plus "fluide".

Sur des machines personnelles, cela dépendrait des capacités des ordinateurs. Mais puisque l'application tourne dans le Cloud, cela devrait fonctionner sans latence.

Ajouter dans la documentation comment utiliser le Swagger.
En profiter pour changer l'URL pour qu'elle soit plus "conviviale"

Idéalement automatiser la récupération des informations du end-point dans le projets GitPod.
Pour le fichier .environment : à la création du workspace, appel du end-point Quarkus et renseignement automatique des champs puis source du fichier.

Pour les users openstack : création automatique de deux variables d'environnement et ensuite générification de la ligne de connection ovhai: ovhai login -u $USER -p $PASSWORD

Faire de même pour l'ensemble des éléments de configuration si il y en a d'autres.

Il y a plusieurs ressources dynamiques ou statiques à servir aux participant·es:

• les users / password openstack
• les objects storage
• le dataset

L'idée serait d'avoir un end-point qui permettre de répartir de manière unique ces ressources.
Lorsque, par exemple pour les users et les objects storage il ne faut pas que deux participant·es aient la même ressource il faudra un mécanisme permettant de ne rendre plus éligible la ressource attribuée.

Par exemple:
http://devrel/ai-lab/resource cela renvoie un truc du genre:

{
  "username": "user-xxxxx",
  "password": "zzzzzzzzzz", 
  "object-storage": "attendee-0-data", 
  "student-id": 0,
  "registry-login": "xxx",
  "registry-password": "zzz"
}

Comme ça on évite les doublons et les fautes de frappes ;).
Je vois bien un truc déployé sur le kube du projet lab ou sur une bête instance avec un nginx.

Pour le lab il faudra scripter :

• création de comptes opensstack
• création des object storages (au moins ceux avec les datas)

En backup si les participantes / participants n'y arrivent pas :

• notebooks
• app

see #15

Parce que c'est plus joli :=)

• depends on #76
• utiliser lien de tracking
• utiliser bit.ly pour les URL
• utiliser https://pypi.org/project/qrcode/ pour générer les QRcode

Il faudrait faciliter le test / debug local pour le training et l'app:

• avec Docker (docker run)
• avec Python: python train.py

Il y a un début de doc dans docs/training.md mais il faut l'enrichir et surtout rajouter un peu de variabilisation dans le code (CPU vs GPU), récupérer le modèle et faire les pip install, ...

Impossible avec la CLI de récupérer les poids du modèle entraîné.
Voir avec l'option du --save-credentials lors de la création du datastore.

Sinon mettre les poids sur le Swift publique avec les données

Mettre à jour avec la dernière version de la CLI ovhai et d'autres éléments si nécessaire

Update the TF scripts to create S3 storage using the hackathon names nomenclature

Généralités IA + Prez outils OVHcloud

• Feuille avec lien + QrCode vers le document (framapad) partagé avec l'ensemble des liens

A voir si on choisit d'utiliser les scripts toolkits pour les hakaton (https://stash.ovh.net/projects/MLS/repos/ai-training-challenge-toolkit/browse) d'Eléa pour créer les environnements du lab.

L'idée serait aussi de créer un projet Public Cloud dédié au lab pour isoler cela du projet COMMON ou pas 😉

Pour pouvoir faire des tests en local il faut ajouter les packages ffmpeg libsm6 libxext6:

apt-get update
apt-get install ffmpeg libsm6 libxext6  -y

Si le $STUDENT_ID n'est pas renseigné cela génère des buckets / notebook avec des ID / noms manquants.

Il ne doit pas être possible de créer de Notebook avec un $STUDENT_ID vide.

Le script doit être pouvoir lancé alors que l'accès est RO, tenter le chmod +x avant le push ?

A l'heure actuelle le fichier setup_env.sh n'est pas exécuté à l'init du workspace.
Ce serait mieux si il était lancé par défaut pour forcer le renseignement du fichier .environment par la suite.

Pensez aussi dans la doc à indiquer de "sourcer" le .environment avant de commencer le lab.

A l'heure actuelle le end-point Quarkus génère une conf vide si il n'y a plus de configuration disponible.

Il serait plus lisible de générer une erreur.