 pour Maxime Garcia aujourd'hui encore et donc nous allons commencer cette dernière session en regardant tout ce qu'on est possible de faire à des configurations donc voilà reprenons notre environnement guide pod donc niveau configuration moi c'est vraiment quelque chose que j'aime bien faire parce que ça va me permettre de vraiment découpler tout cet aspect configuration du pipeline généralement j'aime bien garder d'un côté tout ce qui va être paramètres pour le pipeline dans un fichier de configuration spécifique et avoir dans un autre fichier de configuration puisqu'il va être plutôt ressource ce qui va me permettre pouvoir d'utiliser le pipeline plus facilement sur une autre infrastructure et de rendre ça d'une manière portable beaucoup plus simple donc après c'est vraiment à vous de voir donc pour tous ces configurations moi je conseille aussi de regarder la documentation et la documentation surtout je pense que la partie la plus importante c'est cette première partie qui va nous dire quelle est la priorité pour toutes les variables définies donc si il moins prioritaire ça va être les variables définies dans le script lui-même ensuite ça va être les variables que chaque personne va pouvoir avoir dans la configuration de nextflow dans notre homme donc il y a un fichier calcé point nextflow et il y a un fichier config qui va avoir des informations là ensuite nous avons des infos dans la racine du projet dans un fichier nextflow.config puis dans le fichier nextflow.config dans le répertoire courant où on est tout ce que l'on spécifie avec l'option minus tiré c avec le fichier config tous les paramètres que l'on peut donner après avec le paramètre tiré params tiré file et notre fichier de paramètres de configuration ici a noté que ici pour les fichiers de paramètres le format ne sera pas le même que pour les autres fichiers donc on va en parler plus tard et après tous les paramètres qu'on va pouvoir spécifier ici en ligne de commande donc pour tout mis à part ici les paramètres et ici les paramètres ça va voir vraiment tout ce qui va avoir rapport avec de la configuration du pipeline que ce soit les paramètres ou que ce soit les ressources ici et ici ça va être uniquement pour les parallètes du pipeline on peut paramétriser des ressources aussi mais c'est uniquement les options avec deux tirés dans nextflow donc en fait ce qui se passe c'est que nextflow va prendre en compte toutes ces différentes configurations créer un grand fichier de configuration et calculer qu'est ce qui est la priorité sur l'autre suivant l'ordre dont je viens de vous expliquer et nous faire tout ça alors la syntaxe pour tous les fichiers de configuration est très simple donc mis à part le fichier que l'on peut passer avec l'option tiré params tiré file et pour les fichiers tiré params tiré file c'est uniquement pour des tout ce qu'on va trouver comme paramètres params et ce format là va être un format yamel ou json donc pour tout le reste un fichier de configuration de configuration c'est juste un fichier texte qui va contenir une propriété auquel on va assigner une valeur avec un signe égal la chose importante à savoir les chaînes de caractère n'ont pas besoin non on besoin d'avoir des aiguillemets que ce soit des simples ou des ou des doubles guillemets pour tout le reste il n'y a pas besoin d'avoir de guillemets donc pour les boulevins trou ou false pas besoin de guillemets pour les nombres pas besoin de guillemets mais du coup si vous mettez un nombre entre guillemets ça va être interprété comme une chaîne de caractère et pas comme un nombre voilà c'est à peu près les choses que vous savez après on peut référencer une propriété en utilisant le signe dollar et on peut aussi donc que ce soit la propriété en tant que tel ou la propriété dans une collade on peut aussi référencer des variables d'environnement pour faire des commentaires comme un extra double slash ou slash étoiles étoiles slash si ce n'est pas une ligne l'extra aussi va gérer plusieurs configs qui vont avoir rapport à la même propriété dans ce qu'on appelle ici des scopes faudrait que je trouve un terme bien français pour définir ça donc en fait les scopes vont nous permettre d'embriquer directement des sous propriétés pour une propriété très simple et donc on va appeler tout ce qui est comme sous propriété de beta tout ce qui est dans le scope beta voilà et donc en fait ici cette notation est très similaire à cette notation sauf ici c'est le scope beta ici c'est le scope alpha mais sinon vous voyez l'idée reste la même ici donc ce qu'on va utiliser beaucoup nous ça va être le scope param donc le scope param on va pouvoir utiliser toutes les mêmes propriétés que je vous ai expliqué avant en suivant la liste la liste de priorités défini ici dans la documentation et donc tout ce qui est tout ce qui est écrit dans le script comme on a vu précédemment va être écrasé par tout ce qu'on va pouvoir éclair d'autres que ce soit en ligne de commande ou dans un fil de configuration donc là on veut enregistrer ça dans un fichier nexlo.config voilà on veut enregistrer ça dans un fichier par rams.ns voilà donc si je sais nexlo run alors ici on a notre fichier param.f qui contient ici des paramètres en interne dans le workflow en tant que tel et on a ici les mêmes paramètres définis dans mon fichier de configuration donc ce qui va se passer c'est qu'en faisant nexlo run par rams.ns on va utiliser les paramètres qui sont définis ici dans le fil de configuration et pas ceux qui sont définis dans le script donc là si je fais tourner par rams.ns ce qui va se passer on va avoir bonjour le monde si j'efface ici on va commenter plutôt qu'il fait assez tant qu'à faire on peut les garder qu'est ce qui va passer si je refais tourner le même script ces paramètres là ne vont plus être en compte et on va prendre les paramètres par défaut qui sont définis dans le script voilà ok ce qu'on peut faire aussi vérifier redécoumentons ici redécoumentons là donc si on refait tourner on a bien bonjour le monde qui va s'afficher voilà et si on décide de changer un paramètre voilà on voit ici le paramètre qu'on a tapé en ligne de commande ola écrase le paramètre qui est ici dans mon fichier de configuration qui écrase vraiment ce qui est défini là voilà on a bien tout ça donc de la même façon on a un scope env qui va nous permettre d'avoir des variables d'environnement donc ici sauvons dossier new file nigh nv.config.uk ici on refait un nouveau un nouveau fichier fous.nf et ici nexforan fous.nf si je vous exécute ça et ça devrait il devrait voilà ça marche pas parce que nexfous on n'a pas trouvé les variables d'environnement mais si je spécifie ma mon fichier d'environnement ici qu'est ce qui va se passer nexfous a trouvé mes variables d'environnement on a juste spécifié à nexfous notre fichier de configuration avec l'option ici petit c voilà de la même manière maintenant on va pouvoir on pouvait déjà mais on peut utiliser un process scope pour pour vraiment rajouter tous les directives qu'on veut dans un fichier de configuration donc ici ce qu'on fait par exemple on va définir pour tous les process le nombre de CPU qu'on veut utiliser quelle mémoire la taille en mémoire les containers etc etc etc toutes les infos je vous conseille vraiment de regarder ce qui est possible à faire alors on peut sélectionner non seulement que ce soit tous les process d'un coups ou uniquement un process particulier avec des sélecteurs de process que ce soit un sélecteur with label ou un sélecteur ou un sélecteur with name donc là je vous conseille vraiment de regarder ici de voir ce qui est possible de faire on peut sélectionner plusieurs voilà c'était la with name et with label on peut sélectionner plusieurs label en même temps sans aucun problème avec ici des expressions régulières et comme précédemment il y a une priorité au niveau de qu'est ce qui va être appliqué donc ici ah oui ce qui est mémoire étant peut-être spécifié soit dans une chaîne de caractère avec les noms séparés des unités soit en valeur numérique avec un point séparant les noms des unités ah si on a besoin de faire quelque chose de dynamique il est très important de donner toutes les valeurs dans des closures ce qui vont nous permettre ici on spécifie que la mémoire est égale au nombre de cpu utilisé qu'on multiplie par 4 giga donc si on utilise un seul cpu ça va faire 4 giga si j'en utilise 2 ça va faire 8 mais il faut vraiment mettre ça dans dans une closure sinon ça va être interprété de suite et ça va pas marcher il faut vraiment attendre que la tâche soit commencée pour pouvoir interpréter cette chaîne de caractère et là dans ce cas-là utiliser une closure va permettre de délayer cette interprétation pour vraiment nous interpréter ça au dernier moment on peut utiliser des maps pour avoir pour avoir pour des objets de maps dont de dictionnaires avec des clés valeurs dans un pour une va pour une pour une propriété dans un scope et on peut aussi faire une liste de faire une liste de dictionnaires de la même manière on a il est possible de configurer d'aucœur donc ça on avait déjà vu précédemment parce qu'on avait des options d'aucœur ici qui était spécifié on avait des options process mais c'est vrai qu'on était pas en train d'étail et donc là pareil avec d'aucœur je vais pouvoir spécifier tout ce dont j'ai besoin donc à ce niveau là pareil moi je conseille vraiment d'aller regarder les configs les scopes dans les configs tout ce qui est possible de faire pour le scope d'aucœur on a pas mal de propriété qui sont là définie de base pareil pour le scope environnement pareil après pour condas les exécuteurs là vous allez vraiment pouvoir détailler tout ce dont vous allez tout ce dont vous allez pouvoir avoir besoin donc ici singularity je vais pas faire l'exercice parce que sur guide pod c'était pas possible mais la même chose après pour condas ça va être pareil et merci d'avoir écouté si vous avez des questions n'hésitez pas à les poser sur slack et on va voir la suite et on va donc pouvoir continuer avec quels sont les possibilités de déploiement donc pour moi c'est plus vraiment comment on va pouvoir utiliser ça dans différentes infrastructures mais on va voir ça plus en détail donc n'explo peut tout faire marcher avec un exécuteur en local sur votre porte-machines ou peut vous gérer les appels à vos exécuteurs sur votre infrastructure ou dans le cloud en passant par des par par par un ordonnanceur particulier donc à ce niveau là on va devoir définir avec le procès scope un exécuteur et là dans ce cas là par exemple sur l'orbe on aime bien utiliser sur l'orbe comme exemple passer je pense un des un des ordonnanceurs les plus utilisés donc pour détailler vraiment toutes les ressources disponibles niveau du cluster on a ces propriétés qui vont être ces directives qu'on va pouvoir utiliser que qui va être quel que sur le cluster on va vouloir utiliser le nombre de processeurs la mémoire le temps l'espace de disque nécessaire pour le pour le stockage des tâches on peut soit définir ça pour tous les process soit toujours en utilisant le process et un selector spécifique définir ça pour un procès en particulier donc vous avez plusieurs possibilités de faire ça soit utiliser une exo sur votre nez sur lequel on se log sur votre cluster qu'on peut appeler log in nod ou le head nod du cluster et après on peut utiliser une exo directement pour lancer tous les appels à votre cluster ou sinon ce qu'il est possible de faire c'est directement utiliser votre ordonnanceur pour lancer votre job next low donc ici par exemple pour cela on va pouvoir créer ce genre de fichier qui va faire en sorte de lancer next low et votre pipeline pour vous je vais conseiller à ce niveau là vraiment de vous renseigner pour voir ce qu'il est possible de faire dans votre infrastructure ici on a des petits détails des petits articles de blog que l'on a écrit sur le blog de next low sur vraiment comment utiliser ça sur votre infrastructure mais enfin comment utiliser sur une infrastructure mais après ça va vraiment être à vous de voir ce qui est possible nous c'est à ce niveau là qu'au sein de neuf corps on a vraiment essayé de centraliser tout ça niveau des étapes et pas ça du tout oui je cherche quelque chose mais c'est pas rangé là du tout contre le c'est ce qu'on a vraiment essayé ici de centraliser avec notre répertoire de configuration qui vont vraiment définir tous les filets de configuration qui vont vous permettre d'utiliser les pipelines déjà définie pour vous donc ici par exemple si je si je vais prendre un fichier de configuration va prendre quelque chose de français qui est à dire les filets de configuration pour l'ifb et donc pour l'ifb ce qu'on va vraiment demander aux gens quand on va créer c'est d'avoir une petite documentation qui va détailler tout ce qui va pouvoir se passer ou comment lancer un pipeline et après ce que je fais le pipeline il va utiliser ce fichier de configuration qui va avoir des informations détaillées ici nous avons détaillé qu'il faut utiliser qu'il faut utiliser cagularity qu'il faut avoir ces options spécifiques dans cagularity niveau des exécuteurs on utilise sur l'homme et niveau des paramètres on a ses paramètres de définie et ses paramètres aussi voilà donc vous allez vraiment pouvoir faire ça niveau niveau de la configuration donc on peut considérer les process avec des noms spécifiques en utilisant le selector name donc là on pourrait réutiliser ce qu'on peut faire alors le script numéro 7 d'accord quantification d'accord est ce qu'on veut faire dans d'exploit.config c'est dans un process on veut un pipeline quantification je fais un peu exactement de la syntaxe pour ça c'est deux points pipeline 2 points quantification et c'est quoi la question qu'on demande ici c'est une quantification donc on veut 2 CPU on veut 5 giga de mémoire donc ici reprenons notre truc alors on avait dit 2 CPU et on a dit 5 giga de mémoire voilà donc là juste pour voir ce qui se passe ici bon ben ça tourne mais je voudrais juste vérifier qu'on a bien fait ce qu'on voulait faire donc je vais regarder pour le work folder ce qui s'est passé niveau des scripts donc le script pour la tournée on a bien demandé 2 CPU et niveau de la mémoire est ce qu'on a détaillé ça quelque part est ce que ça ça correspondrait pas à mes cinq donc ici on demande bien du CPU et cinq mémoire alors je voudrais juste vérifier que c'est bien ça qu'on a fait remettons des commentaires ici relançons la même chose ici ce qu'on a différent il n'a pas aimé que je lui fasse quelque chose j'aime bien faire des commentaires juste avec double slush plus tôt que faire des trucs multi-links parce que moi ça me permet très facilement de décommenter quelque chose en nommant le juge de bout qui m'intéresse et pas tout après je pense c'est plus une question d'habitude quelque chose donc regardons dans le 1d qu'est ce qui se passe donc le command message par défaut on est reparti sur un seul cpu ici je regarde le command point run qu'est ce qui s'est passé ici on spécifie juste un cpu on ne spécifie plus de mémoire donc on a bien vu qu'ici notre procès code nous a vraiment permis de spécifier la mémoire utilisée pour ce process particulier et on lui a dit utilise deux de processeur et utilise 5 giga de mémoire on a fait exactement la même chose voilà configurer les process avec des labels alors pour chaque process on va pouvoir spécifier un label donc nous au sein de neuf corps on fait ça automatique on fait ça dans les modules donc au moins vous avez utilisé déjà tous ces labels à ce niveau là c'est vrai que après quand je vais créer moi même un nouveau process j'ai tendance aussi à mettre des labels à ce niveau là pour pouvoir détailler les consommations des ressources ça va être assez pratique et donc après niveau pour les récupérer on peut faire un bif label qui va nous permettre de récupérer directement tous les process qui utilisent le même label et donc tant qu'à faire moi je vais conseiller aux gens de d'avoir des labels qui vont pouvoir être utilisables non seulement au sein d'un même pipeline mais aussi de tous les pipelines que vous allez vouloir développer au sein de votre au sein de votre travail de l'ensemble de vos scripts au moins c'est rééquiliable on peut également configurer directement des containers avec avec notre ici avec configuration au niveau du process donc au lieu d'avoir un container pour tout on peut avoir un container par process donc là c'est vraiment à voir l'approche que vous voulez faire nous c'est vrai qu'au sein de neuf corps on est partis vraiment sur une approche un container pour chaque tâche donc une tâche un container après certains containers vont être réutilisables d'une tâche et une autre si c'est le même outil mais au moins on n'a pas un gros container contenant tout mais un seul container ce qui va nous permettre de nous plutôt c'est d'avoir au moins des versions d'outils qui peuvent être qui peuvent avoir des conflits et on peut peut-être utiliser différentes versions qui ne marcheraient pas ensemble si on utilisait un seul container donc voilà chose très importante niveau des configurations dont j'ai pas parlé avant parce que c'était dans cette session là on va pouvoir définir des profils donc on a un scope profil dans lequel des profils vont pouvoir être définis ce qui va permettre directement avec en utilisant ce terme là utiliser toute une configuration qui en découle ce qui va nous permettre d'avoir des ben d'avoir plein de fichiers de configuration plein d'options de configuration juste utilisables en changeant de profils donc c'est ce qu'on fait nous dans un score très souvent où on a tous nos profils de test on a un profil qu'on a appelé test qui va avoir toutes les options pour faire des tests voilà ici on a défini trois profils standard cluster et cloud qui vont avoir différentes différentes informations voilà et pour utiliser un profil en particulier il faut utiliser tirer profil par défaut enfin par convention le profil standard est implicite donc si vous définissez un profil standard et que vous ne spécifiez pas d'autres profils en ligne de commande c'est le profil standard qui va être utilisé moi j'ai tendance à plus utiliser ça du tout parce que je ne suis pas souvent sur les mains de la culture et j'ai tendance à vraiment changer beaucoup d'une chose à l'autre et au moins voilà je je me force vraiment à spécifier un profil à chaque fois bon après c'est pas très grave vous pouvez vraiment y aller et faire comme vous voulez pour le cloud donc de manière très similaire on va pouvoir utiliser un exécuteur ici AWS batch on peut définir des que spécifiques on peut redéfinir des containers on peut définir un work directory qui va être un bucket s3 une région sur le AWS et un chemin vers l'outil AWS en ligne de commande donc voilà moi pour tout ce genre de chose je conseille vraiment d'avoir ces infos là dans un fichier séparé dans un profil séparé et après par exemple dans ce cas là vous allez pouvoir utiliser ça juste pour Amazon si vous avez besoin on va pouvoir monter des volumes donc avoir ici ce qui est possible de faire donc là je vous vraiment conseille de regarder ce dont vous avez besoin et si vous avez besoin de plus de conseils sur comment faire marcher tout ça que ce soit sur votre cluster que ce soit sur le cloud ou que ce soit même en local n'hésitez pas nous voyons nous poser des questions on est là et on sera ravi de vous répondre voilà pareil ici alors custom job definition ça ça va être encore pour Amazon batch on peut donner une définition spécifique pour un custom job on peut donner des images vraiment spécifiques donc là c'est ce qu'on utilise donc là c'est vraiment vraiment tout ce qu'est spécifique à Amazon donc je ne vais pas trop en parler donc nous sommes à l'étape cache une résume donc n'explo on a vu précédemment que chaque tâche pour chaque process avait avait un identifiant donc cette identifiant est unique et il est généré c'est un hash qui va être composé des valeurs d'entrée de la tâche des fichiers et la ligne de commande utilisée on a un premier un premier indice avec juste deux chaînes de caractère puis après vraiment un identifiant unique voilà et dans ce dossier là on va avoir tout déjà nos fichiers d'entrée qui sont des liens symboliques et après tous les fichiers créés par la tâche également aussi tous les fichiers cachés créés créés par nexo donc voilà de la manière dont résume au work c'est qu'il va réutiliser la tâche l'IG unique pour vérifier si le work directory existe déjà si contient une commande valide et que ça a exécuté ça a marché et dans ce cas là il va réutiliser les mêmes résultats il va passer la tâche suivante et faire les mêmes choses et au fur et à mesure donc si si ici je relance la même chose avec résume comme on a vu précédemment nexo ne va pas prendre en compte les tâches qui ont déjà été exécutées parce qu'elles sont déjà en mémoire on a toutes nos infos dans notre work folder et on n'a pas besoin de recalculer tout ça donc ici on a eu un changement sur la quantification avec salmon parce qu'on a rechangé notre site configuration entre temps mais dans dans on a bien vu que les autres casque et les autres tâches n'ont pas été réexécutés si je recommence encore une fois tout est bien gardé dans mémoire et il n'est pas réexécuté donc nexo par défaut on a vraiment besoin de spécifier cette option de résume mais voilà quoi ça va être exactement la même chose on peut spécifier un autre endroit pour le work directory avec minus w par exemple si vous êtes sur un cluster souvent vous lancez vos scripts dans votre home mais votre home a une taille relativement réduite et vous n'allez pas pouvoir avoir un work folder complet donc on peut à ce niveau-là utiliser tirer w pour spécifier votre word dire où il doit être voilà on peut utiliser aussi alors quand on lance je vais juste relancer un script ici quand je lance un script next low à chaque fois on va avoir un petit identifiant pour le script qui va être composé d'un objectif puis après du nom d'un d'un scientifique donc ici il signe du bean ski ici distracted pastor ici franley gotier et ici festering poitras donc on a vraiment toute ligne d'adjectif next low va piquer au hasard un objectif toute une liste de noms next low va piquer au hasard un nom d'un scientifique et voilà et donc après ce qu'on peut faire on peut lui spécifier ben je veux que tu résumes plutôt celui là next low va regarder en amont regardez votre work folder voir les tâches qu'il peut réexécuter en se basant sur ce que vous avez déjà et gardez pas celui là donc ici on voit bien que c'était on a la même tâche ici que la première la même tâche de la deuxième on a les mêmes tâches parce que ça correspond à la même chose si je veux réexécuter j'en ai changé tellement de trucs je suis un peu donc on a bien su notre truc exécuté on peut utiliser la commande pour avoir des informations sur les rônes qu'on a fait et ici je vois que j'en ai beaucoup je vois niveau des statuts si ça marchait c'est une des erreurs quelle était la version du script utilisé et qu'elles étaient la dédile la session donc là je vois tous mes options de résumé on a recommencé on a fait la même chose donc c'est pour ça qu'on a les mêmes résultats d'accord d'accord voilà ah oui et on peut utiliser soit la dédile la session soit le petit nom voilà on peut aussi avec si je fais ici je fais une explore on peut utiliser ici disait naïm pour lui donner le nom qu'on veut voilà ça peut vous être utile dans certains des cas après c'est vraiment à vous de voir ce que vous voulez faire voilà on peut avoir beaucoup plus d'informations de necks flow log si je spécifie un nai dit en particulier j'ai toutes les informations j'ai uniquement j'ai tous les fissiers qu'on a été créé par ce log là on peut utiliser un paramètre fils pour nous donner toutes les informations sur les métalonnais qu'on veut avoir donc là j'en sais quelle est la tâche si ça a marché ou pas à quelle h est correspond quelle est la durée vous pouvez vraiment regarder tous les détails à ce niveau là il se voulait regarder tous les fils de compé c'est tiré elle il y en a beaucoup voilà manus ça veut nous permettre de filtrer ce qu'on veut oui ça va pouvoir vraiment détailler et on peut vraiment détailler tout ça et regarder ce qu'on veut après necks flow va nous permettre de va gérer tout ça de manière automatique et nous permettre de générer un fichier html générant tout ça moi j'ai tendance à pas le faire mais rien de vous l'empêche de pouvoir faire ça niveau de vraiment essayer de débugger un petit peu toute la fonction résume donc des fois ça peut pas marcher parce qu'il faut vraiment être sûr qu'il n'y a pas de changements dans votre fichier d'input il faut pas oublier que le h est unique et il prend en compte le donc le chemin complet le timestamp la dernière modification et la taille du fichier donc s'il y a une seule de ces choses qui a changé on va devoir recommencer si donc les procès ne devraient pas modifier un input parce que si un process modifie l'input dans ce cas la résume ne marchera pas dans certains cas nfs va pouvoir nous donner un timestamp qui va être pas forcément stable pour le même fichier même s'il n'a pas été modifié dans ce cas là on peut utiliser une stratégie particulière pour le cache qui est un cache lignante à ce qu'il va nous permettre de de faire en sorte que ça marche quand même voilà ici oui ça c'est un cas vraiment très specie où vous pouvez avoir une une course entre deux entre deux fichiers des infos entre deux de procès ces deux interactions donc à ce niveau là ce qu'on va conseiller plutôt s'utiliser de f pour qu'il n'y ait pas de problème ici l'autre problème qu'on peut avoir c'est on peut avoir des input de channel qui sont pas déterministiques comme on a vu au tout début du tutoriel où on peut avoir word hello ou hello world donc à ce niveau là tout ce qui va être vraiment option de résume va être un peu plus compliqué mais bon voilà c'est pour ça qu'on a une directive qui a été rajoutée récemment en extra qui fait une directive faire qui vous garantit que l'ordre des output va matcher l'ordre des input mais utiliser cette directive suivant votre situation ça peut amener à une une perte de performance donc j'espère avoir été assez clair à ce niveau là si vous avez des questions supplémentaires moi je conseille vraiment de regarder en détail les blogs qui ont été écrits par les créateurs d'exfo pour vraiment détailler mais tout en détail quelle est l'option résume comment ça marche pourquoi débuger entièrement et expliciter vraiment tout ce qu'on peut faire niveau du cache avec des pipeline merci de la tension et donc avant dernière étape du jour étape de débugage donc pour le débugage moi je pense que mon meilleur outil c'est tout d'abord en quiconnard en plastique 9 corps toujours utile d'avoir un petit gain en plastique pour expliquer quels sont nos soucis voilà alors ici qu'est ce qui peut se passer quand il y a un problème donc on avait vu cette cette cette erreur le premier jour et on va exactement la reproduire donc je la reproduis peut-être sur voilà ici alors qu'est ce qui s'est passé je vois qu'il y a une erreur sur un process en particulier donc ici ça c'est sur le process index je vois que ce process aussi a pas marché donc ici ça va nous dire quel est l'erreur enfin pourquoi il y a une erreur et là on voit que ce process là c'est terminé avec ce avec ce statut d'erreur donc 127 qualité la command exéputé donc on retrouve le statut de sortie est-ce qu'on avait une sortie ici il n'y a pas eu de sortie quel était l'erreur ici l'erreur est seulement command not front généralement moi quand je vois command not front je me doute que c'est qu'on a eu un souci de configuration de docker singular ici et donc tout simplement que la ligne de command ici l'outil n'a pas été trouvé donc pour ce genre de débugage c'est relativement simple je vais regarder tout d'abord moi pour ce process là donc c'était le 92 92 le 23 c'est bien lui je regarde le fichier command point sh pour voir déjà j'ai ma ligne de command qui correspond à ce que je veux il n'y a pas de problème je regarde toujours la command run après derrière et là dans run dans le fichier point command point run je vois bien que le fichier nx nxn xf que la la fonction nxf launch me juste exécute cette commande là d'embâche et n'est pas n'utilise ni docker ni singular et qu'on a donc c'est pour ça que nxl n'a pas trouvé le n'a pas trouvé la commande ça n'a pas pu marcher donc pour débuguer ça la puissance très simple c'est de remettre le docker on peut recommencer ici et ici en referment on a on a fait un tour que d'amour donc ici quels sont les détails oui les descriptions de l'erreur la commande des idées le statut de sortie la sortie standard si disponible la sortie d'art quand quand il existe et le fichier fin le dossier où on peut regarder à l'intérieur donc voilà ce que j'ai détaillé c'est vraiment pouvoir regarder tous les fichiers point command et ce qu'il y a l'intérieur donc vérifier bien toujours que le fichier command point sage contient les lignes de commande auquel on s'attendu et que toutes les variables sont correctement résolues donc quand je regarde ici un fichier command point sage je devrais plus voir deux variables nxn intérieur on peut effectivement avoir encore des variables bâches mais les variables bâches devraient être à ce moment là juste uniquement avec un avec un simple diaz et non plus échappé comme précédemment qu'on les écrit dans nexlo avec un antislash devant voilà donc moi je regarde en toute premier la plus décide vers celle là je regarde après commande run pour voir vraiment tout ce que nexlo a besoin de faire dans le script et moi là dedans je regarde vraiment plutôt comme je vous ai détaillé avant cette fonction la nxf launch parce que pour moi c'est vraiment celle qui est la plus la plus utile à mon sens après les autres sont utiles aussi évidemment mais pour moi c'est celle qui est la plus informative command out out qui va me donner toute la sortie standard command dot r qui va donner toute la sortie d'erreur donc je vais regarder vraiment ces deux là command dot log qui va être vraiment toute l'exécution toute le log d'exécution complet command out begin c'est un fichier qui est créé dès le début quand le job a commencé et exit code ça contient le code de sortie après on peut vérifier que toutes les tas toutes les fichiers nécessaires c'est à dire si je vais ici ce fichier là et et lié et lié c'est un fichier tant qu'attendez on va se mettre ici le work on voit bien ici que le fichier transcriptum est lié donc je vois bien que les fichiers d'entrée marchent et je vois bien que ce fichier aussi exite c'est important à savoir parce que souvent on peut avoir des problèmes d'un déclaration de calcul ou d'exploit un fichier mais le il y a un menthe a pu mal se passer ou un menthe n'a plus très bien de pas se faire et ce niveau là que ça ne marche pas donc soit parce que ça mal était paramétré soit parce que des fois il y a des problèmes aussi donc il faut pas hésiter de tout regarder à ce niveau là pour les bugger donc moi je vais pas pas hésiter à regarder ce qu'on va pouvoir faire dans au niveau de l'exploit c'est lui dire que des fois certaines erreurs on va les on va les ignorer il peut lui demander automatiquement dans certains cas de recommencer une tâche et donc ce qu'on aime bien faire à ce niveau là quand on retente des tâches on va pas les retenter indéfiniment on va plutôt lui mettre aussi un max de un nombre max de décès pour lui dire bah voilà tu peux recommencer une fois tu peux recommencer deux fois trois fois mais pas quatre pas cinq c'est vous qui voyez ce qu'on peut faire aussi pour toutes les stratégies quand on recommence on peut lui dire d'attendre on peut lui dire on peut donner aussi des ressources supplémentaires puisque souvent quand une tâche va échouer c'est qu'il n'y a pas assez de ressources donc ce qu'on va avoir à faire c'est de dire bah voilà tu n'as pas marché avec 2 giga pour le premier essai donc on va retenter avec toujours 2 giga mais qu'on multiplie par le nombre d'essai donc ici on fait 2 giga par deux essais qu'on multiplie par deux donc pour deux essais ce que nous faire 4 giga ou 6 giga pour 3 essais etc vous pouvez après même décider de faire ça au carré suivant la mémoire dont vous avez besoin là c'est vraiment à vous de voir ça niveau ici des erreurs stratégie on peut récuiser aussi un if ternerre pour dire voilà si l'oeuvre de stratégie est 140 dans ce cas là 140 c'est un code de stratégie spécifique qui je pense va avoir rapport avec la mémoire et le temps et dans ce cas là si on a ce code d'erreur on va refaire un essai sinon on va on va on va arrêter le pipeline et dire non mais là c'est pas possible et on dit bah on recommence que trois fois donc vous allez vraiment pouvoir voir à ce niveau là niveau de l'exécution détaillé et débugué tout ce que vous voulez moi après vraiment pour débuguer je vais déjà regarder tout d'abord où est l'erreur trouver l'erreur si l'erreur c'est au niveau de nexlo si l'erreur est au niveau du script si l'erreur est au niveau de l'infrastructure et à tous ces niveaux là on va avoir moyen de regarder des choses et voir comment on va pouvoir regarder donc moi vraiment je regarde tout ça je vais regarder aussi le fissier point nexlo.log qui va me donner encore plus d'informations nécessaires toutes les informations sur toutes les tâches qu'est ce qui s'est passé, quelles ont été les lignes de commande que j'ai pu utiliser ici par exemple là quelle était la version de nexlo très important de savoir quelles sont les versions utilisées à chaque fois donc toutes les infos sont bonnes à savoir je demande aussi souvent les fissiles configurations quand je vais débuguer parce que ça va me permettre de savoir ben quelles sont les paramètres que j'ai donné en plus quelles sont les fissiles configuration que j'ai plus donné en plus et à ce niveau là on va vraiment pouvoir faire un petit travail d'enquête et voir un petit peu où on en est bon c'est pas les experts mais on s'améliore ça nous permet vraiment de faire une piste. Oui puis bien évidemment c'est pour ça que c'est bien pratique aussi au sein du pipeline de réafficher tous les paramètres qu'on doit utiliser parce qu'au moins on voit tout directement dans le log et après pour la personne derrière qui va débuguer ça vous permet de voir tout ce qu'il y a à l'intérieur. Ici au sein du pipeline là on a vraiment toutes l'exécution et on va pouvoir directement voir quelle tâche est exécutée pourquoi donc ce qui peut être pratique quand on n'a pas activé le nclog false et qu'on voit pas toutes les infos ici dans notre terminal. Et bien évidemment moi quand j'ai des soucis sur un script j'ai d'abord essayé de faire de débuguer tout ce que je peux débuguer par moi même et après si j'ai des problèmes supplémentaires j'hésite pas à en parler sur Slack donc sur le Slack Nextlo si c'est vraiment quelque chose de plus spécifique à Nextlo ou sur Slack de nf core si c'est plus spécifique un pipeline nf core et donc pareil si vous avez des questions hésitez pas on est là pour ça on a tous vraiment commencé quelque part et moi même j'ai commencé à proposer toutes plein de questions sur ce qu'on utilisait avant d'utiliser maintenant le Slack de Nextlo et c'est comme ça que j'ai commencé. Et donc on va pouvoir finir la session du jour en regardant Tower donc Tower Grossomodel principe ça va permettre de gérer et de pré-configurer tous les pipelines qu'on veut utiliser, enfin tous les pipelines Nextlo qu'on veut utiliser avec une interface graphique dans un navigateur internet. Tous les pipelines vont être, on pourra pouvoir partager tous les pipelines au sein d'une organisation et ça va vraiment permettre de gérer tout ça pour une infrastructure. C'est utilisable aussi même si vous êtes seul de votre côté ça peut utiliser soit en ligne de commande en ajoutant tiré with Tower quand vous utilisez Nextlo Run soit en utilisant une API, soit en utilisant une interface graphique par votre navigateur internet. Donc pour vraiment aller sur Tower donc on a une la Tower.nf ce qui va nous lancer Tower.nf donc il y a toute une session gratuite et Cloud qui est vraiment utilisable par tout le monde qui va permettre de détailler tous les exécuteurs que vous voulez que ce soit vos exécuteurs de vos instances locales ou sur le Cloud qui va permettre de gérer une option d'optimisation du workflow ce qui va être quand même très bien ce qui va permettre si vous avez votre pipeline que vous avez fait tourner vous vous rendez compte qu'ils consomment un petit peu trop de ressources sur votre sur votre infrastructure on va pouvoir optimiser ça. L'utilisation de fusion et de wave qui sont de nouveaux outils nous avons créé à Secura Lab qui vont permettre d'optimiser encore plus la consommation des ressources du pipeline. L'utilisation de GitHub, BitLab, BitBucket ou Githéa pour avoir toutes les options que vous voulez pour le versioning de vos scripts. Vous pouvez vous enregistrer, vous connecter avec soit Google soit GitHub, une API en OpenRest et un support communautaire sur Slack. Pour l'option gratuite c'est limité à cinq visateurs, trois workspace, une historique de run de 250 et uniquement trois run concurrent. La version professionnelle va avoir plus de possibilités notamment un support professionnel 24x24, un nombre du visateur dépendant de ce qui est vu. Cinquante workspace, une historique de run complètement limitée et sans pipeline à faire tourner en même temps en parallèle. Et chose importante c'est gratuit pour un usage académique donc ça je pense ça peut être important pour vous. Après il y a vraiment toute une option plutôt entre Enterprise qui va permettre d'utiliser un Tower directement mis en place sur votre propre structure et gérer après tout ça. Après c'est vraiment à voir si vous avez une utilité ou quoi. Donc on va juste s'y mettre, moi je m'en mets avec mon bel amour. Voilà là alors que fait le workspace ? Ah oui donc on a ici dans mon infrastructure je vais avoir accès à mes tokens, mes credentials, mes secrets, toutes les infos que j'ai à ce niveau là. Vous vous allez avoir un token que vous allez pouvoir récupérer. Vous allez pouvoir exporter vous en ligne de commande dans votre terminal et ce qui va faire quand vous allez faire tourner Nexo avec Tower, vous allez pouvoir le voir directement. Donc moi par exemple si je me mets ici sur ma machine Nexo Rencité Elo 1. Si je lance Elo 1. Si je vais pouvoir directement monitorer l'exécution du pipeline par Tower, il ne m'a pas ouvert ça dans le même container ici. Là je vois que mon pipeline a été exécuté et je vois que tout s'est bien passé et ça a marché. J'ai toutes mes tâches ici et là bon ça me donne très peu d'informations à ce niveau là mais laissez moi revoir quelque chose ici. Si je vais vous montrer plutôt ce qu'on fait nous au sein d'un F-Core ou au sein d'un F-Core pour chaque pipeline qui est réalise, on va lancer une exécution sur AWS pour vérifier que ça marche et donc on peut ici dans l'onglet run regarder pour chaque pipeline ce qui s'est passé. Donc ici je sais qu'un pipeline a été lancé récemment et là je vois qu'effectivement il n'a pas marché, ce que je pouvais le voir directement en voyant ici la couleur des choses. Si je vais sur un pipeline ici envers, je vois ici ça c'est le pipeline via American. Donc je vois un peu ce qui s'est passé. Je vois qu'il y a mille tâches qui ont été exécutées avec succès. J'ai accès ici à tous les paramètres de l'exécution du pipeline. Toute la configuration complète, les jeux de données, si on a guisé des jeux de données dans ce cas là ou pas, tout le log d'exécution c'est à dire tout ce qu'on a ici par NextLog et ici on peut détailler aussi en plus des logs d'exécution ce qui va donner ici par exemple un fichier PDF qu'on va pouvoir regarder, qu'il va donner une information ici sur le coverage de tous les impliquants avec Unitmap et là on a vraiment plein de fichiers différents générés par un pipeline. On voit que le pipeline a duré 50 minutes qu'il a consommé un certain nombre d'heures de mémoire et il a eu un coût estimé à moins de 3 dollars. Après l'option d'optimisation dont j'ai parlé précédemment est activable ici et ce que va calculer ici, c'est qu'il va vraiment regarder ce qu'on a exécuté. Si je reviens ici, on va regarder ici vraiment l'exécution de chacun des process, voire que la consommation en CPU, la consommation en mémoire, la tente travail des jobs, toutes les informations à ce niveau là. Tower va regarder vraiment tout ça et va redonner des paramètres, il va redonner des fichiers de configuration. On va réutiliser ici des sélecteurs Wysnive. On va sélectionner chaque paramètre et pour chaque paramètre on va redonner un nombre de CPU et une mémoire précise. Donc des fois moi je me suis rendu compte que c'est peut-être un petit peu trop strict et qu'il va falloir peut-être un petit peu plus coût à ce niveau là mais ça peut vraiment aider de réduire les coûts à ce niveau là et je crois qu'on a dû écrire un blog post à ce niveau là sur les optimisations qu'on avait pu faire mais voilà, juste le conseil de regarder, ça peut être toujours utile de savoir ce qui est possible de faire à ce niveau là. Moi je sais que j'ai tendance à plutôt tout faire en ligne de commande parce que c'est un peu mon background qui est comme ça mais je me suis rendu compte depuis que je suis à Sekira où j'ai commencé à utiliser un peu plus Tower que ça n'est quand même utile en fait. J'ai dû déployer des pipeline dans différentes infrastructures et utiliser Tower m'a vraiment simplifié pas mal de choses donc moi c'est pour ça que je conseille d'utiliser quand je pouvais notamment si vous utilisez le cloud donc que ce soit Amazon, Google ou Azure, Tower va vous créer toute votre infrastructure pour vous sans que vous ayez à le faire. Donc je pense que quelqu'un qui s'y connaît va à peu près mettre autant de temps que Tower a créé toute une infrastructure pour quelqu'un qui s'y connaît pas, bah ouais non non je pense qu'il y a moyen de gagner facilement plusieurs heures de travail à ce niveau là. Donc là vraiment à regarder tout ce que vous voulez, à regarder tout ce qui est détaillé, je crois que Sekira Labs on organise des démos régulièrement de Tower donc je conseille vraiment de regarder tout ça à ce niveau là. Après il y en a plus d'informations. Moi je conseille vraiment juste de lire ça si vous avez besoin, si vous avez envie et si vous avez plus de questions n'hésitez pas à venir nous poser des questions sur ça qu'on est toujours ravi de pouvoir répondre à tout ça. Voilà pour cette session et c'est fini en fait. Donc je voulais vous remercier tous de m'avoir écouté d'avoir été attentif à ces sessions. Si vous avez des retours à faire à quel niveau que ce soit notamment sur le rythme, prix, sur la session, peut-être un peu la traduction parce que bon je sais que je ne suis pas forcément à jour niveau de mon français, niveau des termes techniques utilisés. Donc on va pouvoir agir sur ça sur notre prochaine session de tutoriel qui va être dans 6 mois. Donc n'hésitez pas vraiment quel que soit les critiques que vous avez à faire, allez faire. On sera là pour les lire et les prendre en compte pour améliorer les choses. Moi c'est quelque chose qui est important pour moi de vraiment pouvoir travailler en communauté avec d'autres personnes et si vous m'écoutez ça y est on fait partie de la même communauté donc on travaille ensemble donc si vous pouvez m'aider à vous rendre service ça me fait plaisir. Merci beaucoup d'avoir été attentif et donc à bientôt j'espère.