Intégration de BQS dans le gLite-CE

Réunion TCG Présentation des difficultés rencontrées: Installation gLite-CE et WMS –Sensibilité aux modifications de version des interpréteurs, variables d’environnement… Test coûteux et inefficaces –Fort couplage entre gLite-CE et WMS (temps de chaque test, nombreuses sources d’erreurs) –Dispersion des logs, échecs silencieux, messages d’erreurs inutiles… Pas insisté sur le manque de doc car c’est le moindre des problèmes Conclusion Développer/débuguer avec CREAM, puis déployer avec glite-CE Voir

Test de CREAM Massimo Sgaravatto nous a donné accès à une preview de CREAM ICECREAM BLAH+torque WN Environ 15Ko de scripts créés rien que pour automatiser bêtement l’installation, mais CREAM semble ne souffrir d’aucun des problèmes présentés au TCG En cours d’installation: ICE CREAM+BLAH+torque+WN

Plan d’action (LCG-CE) Gatekeeper BQS job-manager BDII Local batch system CE Submit job Provided CC-IN2P3 To be done UIRB BQS Information Provider BQS

Plan d’action (gLite-CE) BQS job-manager BQS GatekeeperBDII Condor-CBlahpd Launch Condor-C Local batch system CE Submit job fork job-manager BLAH to Globus Provided CC-IN2P3 To be done BQS Information Provider UIWMS

Plan d’action (CREAM – step 1) BQS job-manager CREAMCEMon Blahpd Local batch system CE BLAH connector Provided CC-IN2P3 To be done ICE BQS BLAH Log Parser Submit job BQS Information Provider BQS BQS BLAH commands

Plan d’action (CREAM – step 2) CREAMCEMon Local batch system CE BLAH connector Provided CC-IN2P3 To be done ICE Submit job XML to LDIF BQS grid-neutral front-end BQSLavoisier Blahpd Command-wrapper status cache qvar-query plugin Notification proxy conf XML to CIM

Plan d’action (CREAM – step 2) CREAMCEMon Local batch system CE BLAH connectorBQS connector Provided CC-IN2P3 To be done ICE Submit job XML to LDIF BQS grid-neutral front-end BQSLavoisier Blahpd status cache qvar-query plugin conf XML to CIM

Plan d’action (CREAM – step 1) Faut-il sauter cette étape ? BLAH scripts –L’analyse des arguments et du stdout font office d’interface Pas de détection d’erreur Pas de spécification –De plus en plus de fonctionnalités implémentées dans les plugins (au lieu de BLAH ou du middleware) BLAH Log Parser –Logs = outil de débuggage, pas une interface (surtout BQS) –Est-ce vraiment un plug-in ?... Taille "plug-in" PBS = 10 * client générique (1900 / 192 LOC en C) ! Aucun effort d’isolation du code spécifique au LRMS –Pas de documentation –Spécifique CREAM: socket listener + envoi de notifications

Plan d’action (CREAM – step 2) 1 ère implémentation en Java car… –Prototypage et re-factoring. Tout est mélangé dans BLAH. La principale difficulté est de définir les frontières entre : Grid-specific (gLite-CE, CREAM, GT4) / LRMS-specific (BQS, PBS) Données de config globale / config VO / job Code exécuté (CE, LRMS) / généré (WN) Isoler les détails d’implémentation destinées à évoluer (stage-in/out, proxy renew, notification du status…) –API BQS existe en Java depuis hier (sauf soumission de job qui n’est faite qu’une fois) –(Partager le même container de service que Lavoisier) …puis éventuellement portage d’une partie en C