Intégration de BQS dans CREAM vendredi 20 juillet 2018vendredi 20 juillet 2018 Intégration de BQS dans CREAM Sylvain Reynaud Lyon, le jeudi 14 mai

(dépendance sur Globus supprimée) Plan 3 composants indépendants job control bash (+ XSL) job monitoring C, C++, Java système d'information tous les autres langages! ;-) BLAH version 1.12.3-6 (20/04/2009) (dépendance sur Globus supprimée) GIP

Scripts shell Job control fonctions BLAH en bash (gLite) Responsable de: soumission, annulation, hold/resume Scripts shell fonctions BLAH en bash (gLite) parsing ligne de commande gestion des tables de mapping local/remote des fichiers génération du job wrapper de BLAH staging de fichiers renouvellement de proxy jugé non acceptable pour le déploiement par le TMB solution intermédiaire à court terme: idem LCG-CE scripts bqs_*.sh (CC-IN2P3)

Job control: problèmes Empilement de job wrappers => rend le débogage difficile stdout/stderr transférés via… Job wrapper de BQS bqsd Job wrapper de BLAH (ne pas confondre avec bqs_submit.sh =========================> interface avec BLAHPD) Job wrapper de CREAM rcp (à remplacer ?) Job wrapper de WMS gridftp Script de l'utilisateur hors du rôle du CE

Job control: problèmes BLAH requière le rapatriement sur le CE des stdout/stderr du job wrapper de CREAM solution envisagée encodés (39 octets en général) dans le stdout de BQS …mais le script bqs_status.sh ( méthode "poll" du jobmanager de Globus) n'est appelé qu'en cas d'échec des autres façons de monitorer le job solution actuelle copiés par rcp …mais modifier le job wrapper de BLAH nécessite de patcher un fichier du middleware (blah_common_submit_functions.sh)

Job control: état d'avancement ****** JobID=[https://ccgridvmli01.in2p3.fr:8443/CREAM894035942] Status = [DONE-OK] ExitCode = [0] fait 1er job DONE ce matin… …mais sans utiliser le monitoring de BQS reste à faire tester (et débuguer…) BQSBUpdater (voir slides "Job monitoring") reproduire le comportement du job-manager du LCG -CE dans le script bqs_submit.sh implémenter les autres scripts (hold, cancel…)

Job control: perspectives refactoring (comme déjà fait pour gLite-CE) JSDL (+ extensions pour renouvellement de proxy) comme langage intermédiaire format structuré, spécifié (OGF) et stable génération du job wrapper BQS en XSL simplifie le code (augmente lisibilité, réduit la taille) élimine le problème des caractères à échapper séparation code générateur/code généré grâce au syntax-highlight des éditeurs

communication avec le middleware par fichiers (job_registry) Job monitoring communication avec le middleware par fichiers (job_registry) utilisés par plusieurs composants (BNotifier, CREAM, scripts de BLAH) daemon doit être local au CE => léger formats non spécifiés daemon doit invoquer les fonctions fournies par gLite (en C), et ce plusieurs fois par jobs => éviter les solutions de type JNI & Cie

Job monitoring: état d'avancement Daemon BQSBUpdater fonctions BLAH en C (gLite) job_registry.c : interface avec le middleware config.c : lecture configuration BLAH Bfunctions.c : divers utilitaires (temps, logs…) bibliothèque BDBQuery en Java (CC-IN2P3) compilé en .o et encapsulé dans un wrapper en C++ (car API orientée objet) daemon en C++ (CC-IN2P3)

Job monitoring: problèmes difficile à tester car plusieurs monitoring redondants Logging & Bookkeeping (utilisé par les job wrappers de CREAM et de WMS) BUpdater et BNotifier BLAH (via script bqs_status.sh) Il faut comprendre quels monitorings sont utilisés en fonction de l'étape du job…

Job monitoring: état d'avancement source: Julien Devemy

Job monitoring: état d'avancement status { QUEUED => status2 { HOLD=>HELD , *=>PENDING } RUNNING => status2 { SUBMITTED=>PENDING , *=>RUNNING } ENDED => status2 { SUBMITTED => FAILED: Batch failure RUNNING | STARTED | EOJ => step { SPAWNED => FAILED: Batch failure OVER => COMPLETED RUNNING | ENDING => etime { null | < now - 5*60 => RUNNING: Transitional status * => FAILED: Blocked in a transitional status } * => FAILED: Unexpected status } DELF* => ABORTED: Canceled by BQS operator DEL* => step { QUEUED => CANCELED: Canceled by user * => CANCELED: May have been canceled by user or BQS operator } RERUN* | REBOOTING => FAILED: Internal error (job should not be rerunnable) SIG* | KILL* => ABORTED: A limit has been exceeded LOST => FAILED: Job disappeared NREBOOT => FAILED: Worker node has rebooted * => FAILED: Unexpected status }

Job monitoring: perspectives rendre mapping du status configurable parser généré (lex/yacc ou ANTLR v3 ?) commande "bselect" pour tester le mapping sur les jobs existants récupération des status de job commune avec le système d'information ? complique l'architecture avec un composant intermédiaire

Job monitoring: perspectives Rule := BQSVar '{' (Condition '=>' Rule (','|'\n'))* BLAHRet '}' | BLAHRet BLAHRet := BLAHState (':' BLAHCause)? Condition := BQSStateExpr | BoolExpr BQSStateExpr := BQSStateItem ('|' BQSStateItem)* BQSStateItem := BQSState | BQSStatePrefix BoolExpr := BoolItem (('|'|'&') BoolItem)* BoolItem := ('<'|'>'|'<='|'>='|'='|'!=')? AddExpr AddExpr := AddItem (('+'|'-') AddItem)* AddItem := '(' AddExpr ')' | MultExpr MultExpr := MultItem (('*'|'/') MultItem)* MultItem := '(' MultExpr ')' | Number | 'now' | 'null' BQSVar := 'status' | 'status2' | 'step' | 'etime' | ... BQSState := 'QUEUED' | 'RUNNING' | 'ENDED' | 'SUBMITTED' |... BQSStatePrefix := [A-Z]*'*' BLAHCause := [^,\n]* Number := [0-9]*

réutilisation du GIP du LCG-CE => tel quel SI: état d'avancement réutilisation du GIP du LCG-CE => tel quel

SI: perspectives Configuration centralisée ? Site

SI: perspectives Configuration centralisée ? VO

mais est-ce que ça vaut le coup ?... SI: perspectives refactoring service centralisé, redondant, gestion de cache fourni les informations de base pour GIP mais est-ce que ça vaut le coup ?... << we plan to obsolete the dynamic plugins, their functionality will go into the lrmsinfo- scripts. >> (Dennis van Dok) https://savannah.cern.ch/bugs/?23580

suite de tests automatisée de JSAGA Validation tests prévus suite de tests automatisée de JSAGA nombreux tests réutilisables (basés sur SAGA) via le plug-in CREAM (non terminé mais d'ors et déjà utilisable) tests manuels via WMS via ICE

Utiliser les fonctions fournies par gLite ? Choix à faire… Utiliser les fonctions fournies par gLite ? PROS évite de maintenir du code pour ce qui est déjà géré par gLite (e.g. correction proxy renewal à venir…) CONS contraintes: écrire en bash, patch pour copie stdout Factoriser job states entre monitoring et SI? étant donné les contraintes de BLAH, l'intérêt de cette factorisation n'est pas évident…

Qu'est-ce qui doit être rendu configurable ? Choix à faire… Qu'est-ce qui doit être rendu configurable ? ce qui dépend du savoir faire de la production ? exemple: mapping des status de job seulement ce qui diffère entre 2 CE ? exemple: VOView Faciliter l'exploitation => comment ? centraliser la configuration ?