Développement des templates Quattor de gLite à EMI Guillaume PHILIPPON

Quattor n’est pas QWG Ce qu’on appelle communément quattor est en fait 2 parties distinctes – Quattor : fourni le compilateur PAN et les composants (ncm-xxx) – QWG : fourni un jeu de template ‘prêt à l’emploi’ pour la configuration de machine (StratusLab, Grille, machine de calcul classique, …)

Les QWGs Travailler sur les QWGs représentent 2 activités – Intégrer les nouveaux composants pour un meilleur support des services (SL6 par exemple) – Préparer les templates pour supporter la configuration de nouveaux services

Un passage vers EMI difficile Des changements très impactant entre gLite et EMI – Beaucoup d’informations étaient ‘hardcodé’ dans les composants ou les templates QWG – Passage de /opt a /usr pas systématique

Comment faire les templates On repart de la configuration gLite – Installation de la machine avec les RPMs EMI à partir des template gLite – Configuration du service pour voir ce qui a été changé / modifié – Modification des templates quattor pour intégrer les nouvelles modifications Peu de documentation de la configuration des composant – Yaim est a peu prêt la seule source d’information

Développement de composant Réutilisation des composants généraux (ncm- mysql, …) Le développement de composant n’est pas nécessaire – On peut toujours utiliser ncm-filecopy qui est le composant « couteau suisse »

Organisation du développement Un développeur est identifié pour chaque service – Il est difficile de travailler a plusieurs sur un même service – Encore plus quand on ne partage pas le même repository quattor (site différent)

Ncm-yaim Utilisé historiquement par NIKHEF Simple a utiliser – Il suffit de mettre les valeurs des variable yaim dans les templates Yaim ne permet pas de souplesse dans la configuration – Pas de système de personnalisation – Pas de reutilisation possible en dehors de la grille (création d’un cluster torque)

Et EMI 2.0 La migration sera plus simple car moins de changement en profondeur qu’entre gLite et EMI La migration gLite 3.0 / 3.1 / 3.2 c’est faite assez rapidement

Composant EMI 1/2 DPM : Passe les tests NGI sur le cluster de test de GRIF (sans xrootd) TopBDII : En production sur GRIF SiteBDII : En production sur GRIF LB : Installé sur GRIF (fonctionne avec un WMS gLite 3.1) mis en production après les journées LCG-France

Composant EMI 2/2 CREAM-CE/WN : La partie BDII n’est pas encore configuré WMS : Encore des problèmes de configuration Il manque encore d’autres services – VOMS (actuellement gLite 3.1 dans les QWGs) – Intégration du noveau aii-ks pour le support SL6

Prochaines étapes La priorité est sur le CREAM-CE / DPM pour permettre aux sites un passage vers EMI – Integration du dernier plugin xrootd qui doit résoudre les problèmes de performance de DPM- xrootd La configuration du serveur VOMS Mis à jour des composants pour EMI 2.0

Comment contribuer ? Essayer d’utiliser les templates gLite 3.2 pour installer / configurer un service en mettant a jour la liste des RPMs Noter les erreurs Configurer manuellement les services et noter les fichiers à modifier

Conclusion Faire les templates EMI c’est avant tout installer et configurer EMI – Pas besoin de compétence quattor particulière Processus de développement pas si différent que pour d’autres système de management de configuration