CapordiaEspace client Écrire le contrat minimal d’une demande
Une demande exploitable nomme un propriétaire, un projet, une entrée disponible, une commande ou procédure identifiée et un résultat attendu. Elle indique le nombre de cartes simultanées, la mémoire par carte, la durée estimée et la destination des sorties. Elle précise enfin l’échéance, la raison de cette échéance et la personne autorisée à accepter un retard ou une réduction du périmètre.
L’absence de ces informations ne doit pas être cachée par une priorité élevée. Une tâche dont les entrées ne sont pas prêtes reste non admissible, même si le projet est important. Demandez ce qui manque et fixez le point de réexamen. La file devient alors un outil de décision : elle ne se transforme pas en entrepôt de demandes impossibles à lancer que chacun espère voir traitées spontanément.
Distinguer admission, réservation et droit de passage
L’admission vérifie que la tâche peut être examinée : droits, données, compatibilité, capacité et procédure présents. Une réservation protège ensuite un créneau ou une ressource décidée. La priorité choisit l’ordre entre les demandes admissibles qui se disputent une ressource disponible. Ces trois décisions peuvent dépendre de personnes différentes ; rendez cette répartition explicite pour éviter une validation implicite du besoin technique.
Une carte libre ne rend pas toutes les tâches admissibles. Le disque nécessaire peut manquer, une licence peut limiter la concurrence ou le résultat précédent peut être requis. À l’inverse, une demande techniquement prête peut attendre une décision de calendrier. Affichez une raison compréhensible et une prochaine action, plutôt qu’un simple rang numérique que personne ne sait interpréter.
Définir des priorités qui ne deviennent pas des privilèges
Choisissez quelques classes lisibles, par exemple échéance externe confirmée, travail courant et exploration sans date ferme. Déterminez qui peut attribuer une classe et quelle pièce la justifie. À l’intérieur d’une classe, une règle d’ancienneté ou de rotation peut rendre le choix prévisible. Une demande découpée en cent petites soumissions ne doit pas obtenir mécaniquement cent fois plus de chances qu’une demande d’une autre équipe.
Slurm distingue notamment l’âge d’attente admissible et le partage équitable fondé sur les ressources attribuées et consommées. Cela illustre deux questions différentes : depuis quand attend-on, et quelle part a-t-on déjà utilisée ? Votre règle peut rester manuelle. Ne reprenez pas une formule de score sans comprendre ses paramètres ; les poids d’un ordonnanceur particulier ne constituent pas une norme d’équité universelle.
Exemple fictif : faire entrer une urgence sans chasser les autres
L’équipe fictive « Plans et repères » utilise une seule carte. À 9 h, une tâche du projet Plans dispose d’un créneau confirmé jusqu’à 11 h ; elle n’est pas interruptible. Deux demandes complètes attendent : Repères, quarante minutes, et Esquisses, quatre-vingts minutes. À 9 h 30 arrive une urgence de trente minutes, demandée par Repères pour une revue à midi. Tous ces temps sont des hypothèses pédagogiques, pas des mesures.
La règle locale autorise une urgence validée à passer au prochain point de libération, sans interrompre un travail déjà engagé. L’urgence démarre donc à 11 h et finit théoriquement à 11 h 30. L’équipe accorde ensuite le passage à Esquisses pour éviter que Repères, déjà servi par son urgence, monopolise la file. Cette exception et le nouveau départ attendu de Repères sont annoncés aux responsables concernés.
| Créneau hypothétique | Projet | Motif du passage |
|---|---|---|
| 9 h–11 h | Plans | Créneau déjà engagé, non interruptible |
| 11 h–11 h 30 | Repères, urgence | Échéance externe confirmée avant midi |
| 11 h 30–12 h 50 | Esquisses | Rotation après l’urgence servie à Repères |
| 12 h 50–13 h 30 | Repères, demande courante | Demande admissible suivante |
Prévenir la famine des travaux longs
Servir systématiquement la demande la plus courte donne une file apparemment fluide mais peut repousser indéfiniment un travail long. Prévoyez des fenêtres réservées ou un réexamen à partir d’un âge d’attente annoncé. Ce seuil est une règle interne à définir, pas un délai de service garanti. Si le travail long dépasse réellement la période disponible, son admission doit conduire à un nouveau calendrier plutôt qu’à une attente sans issue.
Les trous courts peuvent accueillir des tâches qui ne repoussent pas un départ réservé. Cette décision suppose une estimation crédible, une ressource réellement compatible et une possibilité de terminer dans la fenêtre. Ne remplissez pas toutes les marges du calendrier avec de nouveaux engagements. Une réserve destinée à absorber un écart n’est pas un créneau gratuit ; son utilisation doit avoir un responsable et une conséquence connue.
Prévoir une annulation dont le périmètre est clair
Désignez qui peut annuler sa propre demande, celle d’un projet ou une exécution devenue dangereuse pour les autres travaux. Pour une demande encore en attente, confirmez son retrait de l’ordre de passage. Pour un travail lancé, vérifiez d’abord ce qui est interrompable, ce qui doit être conservé et qui attend ses sorties. Un message « annulation demandée » ne prouve pas encore que la ressource est libre.
L’outil réel détermine les effets techniques. La documentation scancel distingue un travail et ses étapes, ainsi que l’envoi d’un signal et l’annulation du travail. Avant d’utiliser un outil équivalent, contrôlez l’identifiant et le périmètre concernés ; évitez une sélection globale par commodité. Vérifiez ensuite la fin des processus et la destination des sorties partielles. Le plan de reprise des données est traité dans le dossier de migration, séparément de cette règle de priorité.
Borner les tentatives et isoler une tâche défectueuse
Décidez avant l’exécution combien de tentatives automatiques sont acceptables pour une même cause. Une entrée invalide ne devient pas correcte parce qu’on la relance ; une dépendance temporairement inaccessible peut justifier une nouvelle tentative après vérification. La règle doit indiquer le nombre maximal, le délai éventuel et le responsable du réexamen. Un compteur remis à zéro à chaque nouvelle soumission annule cette protection : rattachez les demandes successives au même problème.
À la limite décidée, retirez la tâche défectueuse de la concurrence normale et placez-la en quarantaine logique, avec un motif lisible. Le reste des travaux admissibles peut continuer. La réintégration exige une correction ou une explication validée, un petit contrôle ciblé et une décision du propriétaire ; elle ne reprend pas automatiquement la priorité d’une urgence ancienne. Cette procédure règle l’admission après échec. La conservation des sorties et leur reprise restent dans le dossier de migration, sans inventer ici un nouveau registre d’états.
Tester la politique avec quatre situations simples
Faites relire la règle par les responsables de projets avec quatre cas : deux demandes identiques, une urgence pendant un travail non interruptible, une tâche longue entourée de demandes courtes et une demande incomplète classée urgente. Pour chaque cas, une personne différente doit parvenir au même prochain départ ou identifier explicitement l’arbitrage requis. Une règle que seul son auteur comprend n’est pas prête à être appliquée.
Contrôlez également qu’une annulation n’accorde pas deux fois la même capacité et qu’un travail bloqué n’empêche pas inutilement un autre travail admissible. Ces vérifications peuvent commencer sur papier ; elles ne prouvent pas l’implémentation d’un ordonnanceur. Si vous automatisez ensuite, reproduisez les mêmes scénarios sur l’outil configuré avant d’en faire dépendre un engagement de projet.
Mesurer le service rendu par la file
Suivez l’attente des demandes admissibles par classe et par projet, ainsi que les motifs de blocage. Séparez attente, occupation et délai jusqu’au résultat accepté. Un seul total de travaux terminés peut masquer une équipe toujours repoussée ou une accumulation de tâches urgentes. Examinez aussi les écarts entre occupation estimée et réelle : ils influencent directement les réservations futures.
Révisez la politique à une échéance choisie avec l’équipe, ou après un incident qui révèle une règle manquante. Changez une règle à la fois et annoncez son effet sur les demandes déjà présentes. Le résultat attendu est un ordre de passage explicable, des exceptions traçables et un calendrier cohérent. Il ne remplace ni l’authentification du compte Capordia ni les permissions de la machine, et il ne crée aucun engagement de support.
Questions pour décider
Faut-il toujours faire passer une urgence en premier ?
Une urgence doit être admissible, justifiée et validée selon la règle commune. Elle ne rend pas un travail en cours interruptible. Définissez son point de passage, les demandes déplacées et la personne qui assume l’effet sur leurs échéances.
Comment éviter qu’une équipe monopolise les créneaux ?
Regardez les ressources déjà obtenues et l’attente des autres projets, puis utilisez une rotation ou une règle de partage explicite. Le nombre brut de demandes n’est pas une mesure d’équité. Prévoyez aussi le traitement des travaux longs.
Cette méthode impose-t-elle d’installer Slurm ?
Non. Les documents Slurm éclairent certaines distinctions, mais la politique peut d’abord être appliquée dans l’outil de coordination de l’équipe. Une automatisation éventuelle demande sa propre configuration et ses contrôles ; aucun ordonnanceur n’est présumé fourni.