Skip to content
GitLab

WIP: Features/oar gpus

Merged PASTOR Jonathan requested to merge features/oar_gpus into master

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.
Edited by Pierre Neyron