= Soumission des Jobs =
[[TracNav]]

[[TOC(inline)]]


Tous les fichiers nécessaires se trouvent dans le répertoire  `tutorial/material` que vous avez récupéré.

== Premiers pas... ==

=== Principales Commandes ===

Les commandes permettant de soumettre et gérer un job commencent toutes par `glite-wms-job-` et utilise les services d'un gLite WMS.

''Note : pour soumettre et gérer un job avec l'ancien LCG RB, il faut utiliser les commandes `edg-job-`. Ces commandes sont obsolètes et il faut préférer l'utilisation d'un WMS, sauf raisons très particulières. De même il ne faut pas utiliser les commandes `glite-job-xxx`, elles-mêmes obsolètes.''

Les principales commandes sont :
 * `glite-wms-job-submit` : soumission d'un job. Cette commande nécessite un ''delegation proxy'' qui peut être créé automatiquement si on utilise l'option `-a` ou être créé avec la commande `glite-wms-job-delegation-proxy` et être spécifié avec l'option `-d identifieur`. L'utilisation de `-d` doit être préférée si on soumet plusieurs jobs car elle est beaucoup plus efficace.
 * `glite-wms-job-status` : affichage de l'état d'un job (en attente, en cours d'exécution, terminé...).
 * `glite-wms-job-output` : récupération de l'output du job.
 * `glite-wms-job-logging-info` : affichage d'informations détaillées sur l'exécution du job et les éventuelles erreurs rencontrées.
 * `glite-wms-job-delegation-proxy -d identifieur` : obtention d'un `delegation proxy` pour soumettre plusieurs jobs. `identifieur` est un nom arbitraire qui sera utilisé pour désigner le ''delegation proxy'' et l'utiliser dans avec les commandes comme `glite-wms-job-submit`.

La commande `glite-wms-job-submit` retourne un ''jobid'' qui est un URL. Ce ''jobid'' devra être utilisé pour désigner le job dans les autres commandes. Il doit être conservé sans quoi il n'est plus possible d'interagir avec le job (connaitre son état ou récupérer son output). Quand on soumet plusieurs jobs, il peut être plus pratique d'utiliser l'option `-o fichier` lors du submit : dans ce cas, le ''jobid'' sera écrit dans le fichier. Le même fichier pourra être utilisé à la place du paramètre ''jobid'' dans les autres commandes en utilisant l'option `-i`.

''Note: l'utilisation des commandes `glite-wms-job-xxx` nécessite d'avoir un proxy valide.''

=== Soumission d'un Job "Hello World" ===

Cette exercice consiste à soumettre un job très simple qui écrira "Hello World" dans le fichier d'output. Le job en lui-même n'a pas d'intérêt particulier mais permet d'illuster la soumission et le suivi de l'exécution d'un job. Un job grille est décrit dans un langage particulier appelé ''JDL'', décrit dans la partie suivante.

 1.  Si ce n'est pas déjà fait, créez un proxy à l'aide de la  fonction  `voms-proxy-init`.
 1.  La description du job la plus simple possible se trouve dans le fichier `HelloWorld.jdl`. Le format de ce fichier est le couple  clés/valeurs définis. 
 1.  Soumettez le job  `HelloWorld.jdl` en utilisant la commande `glite-wms-job-submit`.  Les commandes "workload management" comprennent les proxies VOMS et utilisent la VO indiquée  dedans. 
  * `glite-wms-job-submit HelloWorld.jdl`  : la commande envoie une réponse contenant une URL qui débute par "https", quand elle se passe bien. Cet URL est l'identifiant du job ou ''jobid'' qui permet de manipuler le job.
  * On peut utiliser l'option `-o fichier` de la commande `glite-wms-job-submit` pour que le ''jobid'' soit stocké dans un fichier. Le même fichier pourra être utilisé avec les autres commandes `glite-wms-job` en utilisant l'option `-i`.
 1. Vérifiez le statut du job en utilisant la commande `glite-wms-job-status` (Sur linux on peut utiliser la commande `watch` pour  exécuter une commande dans une boucle. Pour effectuer la commande `glite-wms-job-submit` toutes les 15 secondes, utilisez  `watch -n 15 glite-wms-job-status <jobid>` et taper ctrl-c pour sortir).
  * Suivez les modifications de l'état du job jusqu'à l'état "Done(Success)".
  * Combien d'états différents pouvez-vous distinguer ?
  * Si le job se termine dans l'état "Aborted", c'est qu'il y a eu une erreur. On peut trouver plus d'informations avec la commande `glite-wms-job-get-logging-info`. Cette commande requiert le jobid.
 1.  Lorsque le job est terminé (Status: Done (Success)), récupérez les données générées  à l'aide de la commande  `glite-wms-job-output`.  Le répertoire  utilisé pour stocker les résultats dépend de la configuration du  site.  Au LAL, le répertoire est  `~/JobOutput/`.  Ce  répertoire doit exister; créez-le si nécessaire. 
  * `glite-wms-job-output <jobid>` : la réponse indique le répertoire qui contient les résultats du job.
 1.  Vérifiez que tout s'est déroulé correctement en consultant les  fichiers `std.out` et `std.err`. Le fichier `std.err` doit être vide et `std.out` doit contenir "Hello  World". Cette procédure simple est utilisée pour le suivi de tous les jobs.
 
Comme indiqué dans la description de la commande `glite-wms-job-submit`, il est possible d'utiliser les options `-o`, `-i`, et `-noint` qui permettent de gérer un plus grand nombre de jobs avec les commandes  `glite-wms-job-*`. Regardez les informations avec l'option `-help` ou la commande `man`. Il existe également des APIs (java, c, c++) qui permettent la gestion des jobs vers un programme compilé.  Ce tutorial ne couvre pas ces APIs.

== Description des Jobs (JDL) ==

=== Fichier JDL : modification et édition ===

 1. Modifiez le fichier `HelloWorld.jdl` de manière à ce  qu'il n'appelle plus `/bin/echo` mais le script `HelloWorldScript.sh`.  Pour cela : 
  *  la ligne `Executable` doit être `HelloWorldScript.sh`,
  *  la ligne `Argument` peut rester avec `Hello World`, 
  *  vous devez de plus définir le paramètre `InputSandbox`. Tous les fichiers listés dans `InputSandbox` sont transfèrés avec le job. La syntaxe de cette ligne est :  
  * `{{{InputSandbox = `HelloWorldScript.sh`; }}}`    Si vous soumettez plusieurs jobs avec les mêmes fichiersd'entrée, une nouvelle copie de chaque fichier est créée.   Exécutez le job et vérifiez que tout fonctionne.On peut utiliser n'importe quel script, cependant le shell utilisé par le script (indiqué dans la ligne `#!`) doit exister dans le `Worker Node`.
 1.  Modifier de nouveau `HelloWorld.jdl` de manière à ce  qu'il appelle cette fois l'exécutable  `myhostname`.  Vous  pouvez visualiser la source de cet exécutable, qui est un  programme C :  `myhostname.c`. Vous n'avez cette fois pas besoin de définir d'argument.  Il faut modifier la ligne `InputSandbox`.  Exécutez le job et vérifiez que tout fonctionne.  Sur quel ordinateur a tourné votre job?
 1.  L'exécution d'un programme en C compilé n'est pas  forcément pratique : l'exécutable peut être d'une grande  taille, dépendre de plusieurs fichiers, ou dépendre d'un  environnement d'exécution particulier.Une solution consiste à compiler le programme directement sur le CE. Modifier une nouvelle fois `HelloWorld.jdl` de manière à ce  qu'il appelle le script `buildandrun.sh`, avec pour argument  `myhostname`. Testez ce script seul pour comprendre l'argument nécessaire.Exécutez le job et vérifiez qu'il fonctionne toujours. Votre job a-t-il tourné sur le même ordinateur que précédemment? 

`Note : si la VO que vous utilisez est acceptée par plusieurs CE, il peut être utile d'ajouter la ligne suivante dans votre JDL pour forcer le job à aller sur un CE particulier (au LAL dans l'exemple) :`
{{{
Requirements = regexp(`.*\.lal\.in2p3\.fr:.*`, other.GlueCEUniqueID)
}}}

=== Pour comprendre les `Requirements` and `Rank` ===

Il y a deux mots-clés très importants dans les fichiers JDL : `Requirements` et `Rank .  Leurs valeurs sont des expressions.  Ces 2 mot-clés servent à sélectionner le CE auxquels sera envoyé le job.
 * `Requirements` : ce mot-clé permet de sélectionner les CE qui ont les ressources requises pour exécuter le job. L'expression des ressources peut porter sur n'importe quelle information publié dans le système d'information (BDII). En particulier, le nombre de CPUs libres, le temps d'exécution minimum, la quantité de mémoire... La valeur est une condition logique utilisant une syntaxe assez habituelle (proche de celle du langage C). On peut utiliser des `regular expressions` avec les chaines de caractères, en utilisant la fonction `RegExp(`pattern`,attribut)`. Par exemple, pour sélectionner un CE appartenant au domaine `lal.in2p3.fr`, on pourra utiliser l'expression :
{{{
Requirements = regexp(`.*\.lal\.in2p3\.fr:.*`, other.GlueCEUniqueID);
}}}
 * `Rank` : cet mot-clé définit l'ordre de classement des CEs sélectionnés par la clause `Requirements `. Le CE sélectionné pour exécuter le job est celui ayant le meilleur classement suivant le critère défini par `Rank`. En cas d'ex-aequo, le CE est choisi aléatoirement parmi eux. Par exemple pour trier sur le nombre de CPUs libres dans le CE :
{{{
Rank = other.GlueCEStateFreeCPUs;
}}}

Le résultat de l'évaluation de `Requirements` et `Rank` est différent suivant la VO utilisée car toutes les sites n'acceptent pas les mêmes VOs. On peut connaitre le résultat de l'évaluation de `Requirements` et `Rank` avant de soumettre le job en utilisant la commande `glite-wms-job-list-match` et en indiquant le fichier JDL en paramètre. Cette commande retourne la liste des CEs sélectionnés par Requirements, classés dans l'ordre indiqué par `Rank`. On peut exécuter cette commande pour une VO pour laquelle on a pas de proxy en ajoutant l'option `--vo voname` (par exemple : `--vo dteam`).

__Exercices__ :

Dans les exercices proposés, vous allez éditer le fichier `HelloWorld.jdl` pour modifier les expressions `Requirements` et `Rank`. Pour voir l'effet de la modification, utiliser la commande `glite-wms-job-list-match` puis essayer de soumettre le job en utilisant la commande `glite-wms-job-submit`. Pour soumettre le job, vous devez avoir un proxy valide.

 1. Sélectionner les sites qui acceptent des jobs nécessitant plus de 1 heure de CPU :
{{{
Requirements = (other.GlueCEPolicyMaxCPUTime > 60);
}}}
 1. Essayer de modifier la clause `Requirements` pour demander plus de 2h, plus de 12h. Indiquer le besoin en temps d'exécution total plutôt qu'en temps CPU (`other.GlueCEPolicyMaxWallClockTime`).
 1. Choisir uniquement des sites francais. Pour cela on peut utiliser la valeur suivante (d'abord seule puis en la combinant avec la précédente avec l'opérateur `&&`) :
{{{
RegExp(`.*\.fr:.*`,other.GlueCEUniqueID)
}}}
 1. Ajoutez les lignes suivantes pour utiliser la ressource avec le plus grand nombre des CPUs libres et comparer le CE qui sera sélectionné. 
{{{
Rank = other.GlueCEStateFreeCPUs;
}}}
 1. Utiliser la valeur `-other.GlueCEStateFreeCPUs` : quelle est l'effet ?
 1. Que se passe-t-il si on utilise `Rank = 1;`?

`Note : Une option `-r` existe pour la commande  `glite-wms-job-submit` qui permet de choisir une ressource spécifique. Cependant cette option évite tous le processus `MatchMaking` de Resource Broker et n'ajoute pasle fichier nécessaire (le fichier `BrokerInfo`) pour la gestion de données. La technique avec other.GlueCEUniqueID est plus flexible et plus sûre.`

Pour plus d'information, consulter la liste des [http://server11.infn.it/workload-grid/docs/DataGrid-01-NOT-0101-0_6-Note.pdf attributs] JDL valides.

== L'environnent d'exécution sur le Worker Node ==

Chaque utilisateur de la grille est mappé dans un compte local pour chaque site. Maintenant l'accès aux ressources locales est contrôlé par les droits de ce compte. Réinitialisez votre proxy avec l'option `--voms  vo.lal.in2p3.fr`.
 1. Visualisez le contenu du fichier JDL `whoami.jdl.` Lancez le job et récupérez l'output. Visualisez le fichier `std.out`. Sur quel compte êtes-vous mappé?
 1. Visualisez le contenu du script `envvar.jdl`. Soumettez un  job qui lance ce script dans la grille. Regardez la liste des  variables.  Combien de variables concernent la grille?
 1. Ecrivez un job qui liste les versions des logiciels disponibles  dans le `Worker Node`. On peut utiliser la commande `rpm`  pour le faire.


== Renouveler le proxy en cours de job ==

Par défaut, la validité d'un proxy est relativement courte, généralement entre 12 et 96h. La durée maximale est fixée par le serveur VOMS de la VO. Si le proxy expire avant la fin du job, il ne sera pas possible de récupérer les résultats. S'il expire avant le début du job, le job échouera.

Pour permettre à un job de s'exécuter sans problème quelque soit son temps d'attente et sa durée, il faut utiliser un service de renouvellement de proxy, appelé MyProxy. Son utilisation est très simple. Il faut d'abord ajouter la ligne suivante dans le JDL du job (la valeur du paramètre doit être un serveur MyProxy acceptant la VO utilisée pour le `voms-proxy-init` et le resource broker utilisé pour soumettre le job, `myproxy.grif.fr` est le serveur MyProxy de GRIF) :
{{{
MyProxyServer = `myproxy.grif.fr`;
}}}

Après avoir fait le `voms-proxy-init` et avant de soumettre le job, il faut exécuter la commande `myproxy-init`, comme suit :
{{{
myproxy-init -d -s myproxy.grif.fr
}}}

La configuration d'un serveur MyProxy détermine les resource brokers autorisés à utiliser le service pour renouveler des proxies. Le serveur MyProxy de GRIF, `myproxy.grif.fr`, accepte les demandes de renouvellement en provenance du RB de GRIF, `grid09.lal.in2p3.fr`.  

On peut voir la liste des proxies valides avec la commande `myproxy-info` et on peut mettre fin au renouvellement du proxy (avant ou pendant l'exécution du job) avec la commande `myproxy-destroy`.  `L'option `-d` doit être toujours être utilisée avec l'ensemble des commandes myproxy-*.` 

`Note : les commandes `myproxy-xxx` utilisent un nom de fichier différent des autres commandes gLite si on utilise un fichier unique pour le certificat et la clé privée (extension `.p12`). Pour résoudre le problème, il faut créer le lien symbolique suivant :`
{{{
cd ~/.globus
ln -s usercert.p12 usercred.p12
}}}

`Note2 : la version actuelle de serveur MyProxy ne comprend pas les extensions VOMS dans un proxy.  Si l'accès aux services grille par un job requiert un extension VOMS valide (par exemple pour l'accès à un SE), MyProxy ne résoud pas le problème des jobs qui durent  (ou restent dans queue) longtemps.`

== Soumission d'un job MPI ==
Beaucoup de disciplines utilisent des jobs parallèles. MPI (Message PassingInterface) est un protocole qui permet la communication entre les tâches parallèles. Les jobs MPIs sont supportés dans la grille. La grille permet d'utiliser les différentes versions et implémentations de MPI :
 * MPI v1 : LAM MPICH
 * MPI v2 : openMPI et MPICH2

Le logiciel `mpi-start` développé par le projet européen [http://www.interactive-grid.eu/ int.eu.grid] facilite l'utilisation du MPI dans la grille. L'utilisateur peut définir :
 1. Un script à exécuter avant le binaire MPI (par exemple pour compiler le programme),
 1. Le programme lui-même, et
 1. Un script à exécuter après le binaire MPI (par exemple pour enregistrer les résultats dans un SE). 
Le fichier `mpi-hooks.sh` définit les scripts à exécuter avant et après le binaire MPI. Le fichier JDL définit les paramètres comme des nombres de CPU pour le job.
 1. Lancez un job avec `mpi-start-lam.jdl` Regardez la sortie du job. S'il a fonctionné correctement, on pourra lire des lignes telles que:  
  * `Hello world! from processor 3 out of 8`
 1. Changez le nombre de CPUs utilisé par le job. Vérifiez que le job marche toujours. Fonctionne t-il aussi si vous spécifiez 1000 CPU?
La grille supporte les jobs MPI sur un seul site. MPI avec esclaves sur plusieurs sites n'est pas supporté. Le support du MPI évolue très rapidement dans la grille en ce moment. Ceci va se stabiliser dans quelques mois.

Les informations officielles à jour pour l'utilisation de MPI sur la grille EGEE sont disponibles sur le site [http://egee-uig.web.cern.ch/egee-uig/production_pages/MPIJobs.html EGEE UIG]. Plus de détails sont disponibles sur le site du [http://www.grid.ie/mpi/wiki MPI Working Group].