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

Présentation au sujet: "Développement des templates Quattor de gLite à EMI Guillaume PHILIPPON."— Transcription de la présentation:

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

2 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, …)

3 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

4 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

5 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

6 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 »

7 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)

8 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)

9 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

10 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

11 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

12 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

13 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

14 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