raffinement du setup
Je propose de la réorganiser de la manière suivante: L'idée serait de permettre aux participants de tester le plus en autonomie possible leur configuration en étant un peu progressif. Je vois 3 parties (détaillées plus bas)
- Configure and validate your Grid'5000 and FiT accesses
- Get the lab environment (docker / singularity)
- Validate the lab environment
- Grid'5000 setup
- lien vers les ressources nécessaires
- config locales (.ssh/config)
- tests de fonctionnement: on donne un enchainement de commandes qui doivent fonctionner depuis la machine de l'utilisateur
- tests ssh et des proxy commands:
#
# test an initial connection with grid5000
#
$laptop) ssh <login>@access.grid5000.fr hostname
access-north
#
# test the automatic ssh jump
# laptop -> access -> frontend
# normalement la règle dans .ssh/config positionne les logins
#
$laptop) ssh rennes.grid5000.fr hostname
frennes
#
# test the automatic ssh jump
# laptop -> access -> a node
#
$laptop) ssh rennes.grid5000.fr
$frennes) oarsub -I -t allow_classic_ssh
# in another terminal (from the laptop)
$laptop) ssh <nodename>.<site>.grid5000.fr
- tests accès API avec curl par exemple (un peu pareil qu'au dessus)
curl un truc qui fait un GET (ça vérifie la connectivité, les requêtes GET sont plus ou moint publiques)
curl un truc qui fait un POST (ça test les accès)
-
IOTlab setup
- pareil
-
Notebook / docker
- Normalement on doit pouvoir lancer le docker en montant les répertoires de config (.iotlabrc, .ssh/config, SSH AGENT ...)
- On teste les mêmes truc mais jupyter lab dans un terminal
-
Dernier setup pour EnOSlib:
.python-grid5000.yaml
- https://msimonin.gitlabpages.inria.fr/python-grid5000/#installation-and-examples
- un test possible serait d'utiliser la ligne de commande
grid5000
depuis un terminal dans le conteneur (et de tester la création d'un job puis sa suppression par exemple)