WIP: Features/oar gpus

Merge request pour ajouter les GPUs dans OAR. On peut lancer le générateur avec la commande suivante:

Lien vers le pad: https://pad.inria.fr/p/np_YHHmlatqQDDFo48X

Afficher les commandes OAR:

$ rake gen:oar-properties SITE=lille CLUSTER=chifflet,chifflot DO=output

Afficher la table OAR (comme dans dans la doc):

$ rake gen:oar-properties SITE=lille CLUSTER=chifflet,chifflot DO=table

Faire le diff:

$ rake gen:oar-properties SITE=lille CLUSTER=chifflet,chifflot DO=diff

Avancement:

• faire un script qui analyse le mapping cpu/gpu
• proposer un format pour les propriétés GPUs dans la ref-api
• écrire un générateur de commandes OAR pour propriétés GPUs
• intégrer avec le générateur existant
• reprendre le code de création des propriétés de l'ancien générateur
• créer d'abord les propriétés de base host/cpu/core/gpudevice avant les propriétés auxiliaires (cosmétique/plus logique)
• rebase sur les derniers commits de la branche master
• supprimer l'ancienne commande gen:oar-properties de la branch de dev (le code de poc-oar-properties remplace l'ancien de oar-properties): les tests/comparaisons sont à faire avec la même commande dans la branche master
• implémenter/renommer l'action "exec"/"update", "output"/"print" (déjà fait dans la branche master, devrait arriver avec le rebase)
• dans le DO=update affichager les commandes shell exécutées avant leurs outputs (e.g. echo "# $cmd" ; $cmd)
• générer les propriétés OAR manquantes (L123 https://pad.inria.fr/p/g.h6aibp4MP2anzhaz$np_UV271zBwm7OQxXs6_g5kdev)
• vérifier que les commandes basiques fonctionnent bien, par ex: rake gen:oar-properties DO=print sans SITE, sans CLUSTER
• vérifier que le usage (rake -T) est cohérent (commande DO=...)
• uniformiser le code (les noms de méthodes, les variables)
• reordonner les fonctions et supprimer les espaces afin de minimiser le diff avec master
• tester dans oar-vagrant qu'on produit bien la même chose qu'avec la branche master pour les clusters sans GPU
• tester dans oar-vagrant qu'on produit bien ce qui est attendu pour les clusters avec GPU
• tests pour une base existante → DO=diff, DO=update sur base existante.
• retravailler les commits pour les rendre un peu plus lisibles (git rebase -i origin master)
• vérifier avec hw-loc les règles d'attributions des CPUs pour chaque cluster
• dernière validation (CI ok?) et merge dans master
• attention a ne pas avoir gpu et gpudevice dans le tableau retourné par ignore_default_keys() (ajoutés temporairement dans l'ancien generateur avec le commit 9a32d739)

Tests avec oar-vagrant:

Cf. https://oar.imag.fr/wiki:oar-vagrant

Mise en place:

• tests avec la même version de OAR que Grid5000, sur deb_debian9_pgsql: il faut juste faire export OAR_FTP_DISTRIB=stretch-backports_beta avant de faire le vagrant up
• puis ouvrir l'accès sans password vers la box server pour que ssh vagrant@192.168.37.10 fonctionne (ssh-copy-id) et ssh root@@192.168.37.10 aussi (copy vagrant's authorized_keys to /root/.ssh/).
• enfin il faut réinitialiser la database OAR:

$ ssh root@192.168.37.10 "oar-database --drop --db-is-local -y && oar-database --create --db-is-local"

Test du générateur de la branche master:

$ rake gen:oar-properties SITE=lille CLUSTER=chifflet DO=print | ssh vagrant@192.168.37.10 sudo bash

Tester du nouveau générateur:

(DO=exec devient DO=update)

$ rake gen:oar-properties SITE=lille CLUSTER=chifflet DO=update OAR_SERVER=192.168.37.10 OAR_SERVER_USER=vagrant

Extraction de la table resources de la database OAR:

; Avec oarnodes

$ oarnodes -Y

; Avec pg_dump

$ pg_dump oar -a -t resources # VM vagrant

$ pg_dump oar2 -a -t resources # Site en production

; Avec une requete SQL

$ cat <<EOF > select.sql
SELECT
switch, cluster, host, network_address, ip, type, cpu, gpu, core, disk, cpuset, gpudevice, diskpath, resource_id, disk_reservation_count, disktype, scheduler_priority, besteffort, deploy, cpuarch, cpucore, cputype, cpufreq, gpu_count, gpu_model, nodemodel, virtual, eth_count, eth_rate, ib_count, ib_rate, ib, opa_count, opa_rate, opa, myri_count, myri_rate, myri, memcore, memcpu, memnode, mic, wattmeter, cluster_priority, max_walltime, production
FROM resources
WHERE (comment IS NULL OR NOT comment like 'Retired%') AND (type = 'default' OR type = 'disk')
ORDER BY
switch, cluster, CAST(SPLIT_PART(ip,'.',4) as integer), type, cpu, gpu, core, disk, cpuset, gpudevice, diskpath, resource_id, disk_reservation_count, disktype, scheduler_priority, besteffort, deploy, cpuarch, cpucore, cputype, cpufreq, gpu_count, gpu_model, nodemodel, virtual, eth_count, eth_rate, ib_count, ib_rate, ib, opa_count, opa_rate, opa, myri_count, myri_rate, myri, memcore, memcpu, memnode, mic, wattmeter, cluster_priority, max_walltime, production
;
EOF

Then to retrieve from the VM:

$ cat select.sql | ssh -t root@192.168.37.10 'su - postgres -c "psql -A -t oar"' > select.new

And to retrieve from production (Lille):

$ cat select.sql | ssh -t oar.lille.g5ka 'sudo -u postgres psql -A -t oar2' > select.lille

Évaluation des résultats:

• Comparer les résultats de plusieurs (2 au moins) itérations du nouveau générateur à partir d'une base vierge : vérifier l'idempotence.
• Comparer les résultats après une passe du nouveau générateur sur une base existante pour un cluster existant ou tous les clusters. Vérifier que les modifications sont pertinentes: ajout des GPUs, mais pas de changement sur les autres ressources.
• Comparer les résultat après ajout d'un nouveau cluster sur un site existant : vérifier la pertinence de l'ajout et l'idempotence apres une nouvelle passe.

data/grid5000/sites/lyon/clusters/orion/nodes/orion-1.json

@@ -24,6 +24,7 @@
       "memory": 5636096000,
       "model": "Tesla M2075",
       "power_default_limit": "225.00 W",
+      "reservation": false,
       "vbios_version": "70.10.46.00.05",
       "vendor": "Nvidia"
     }