**** Phone : Jérôme Pansanel, Xavier Jeanin, Etienne Dublé, Jean-Michel Barbet, Pierrick Le Corre, Présents : Nadia Lajili, David Bouvet, Cyril L'Orphelin, Julien Nauroy, Guillaume Philippon, Carlos Carranza, Sorina Pop, Efith Knoops, Christine Gondrand, Flavian, Dorine Fouossong, Emmanuel Medernach, Romain Tartière, Hélène Cordeir Discussion basée sur les slides uploadées à http://indico.in2p3.fr/conferenceDisplay.py?confId=4131 *** Pour l'instant il faut utiliser 2 my proxy serveur- GRIF et CERN - pour pouvoir court-circuiter la consigne de 2 certificats nationaux - C Leroy et Carlos Carrranza - Une solution pourrait être d'utiliser les Certificats robots - mécanisme physique - plutôt que certificats utilisateurs à voir avec Alice de Bignicourt [CLeroy, AdBignicourt ] pour la récupération de proxy via les serveurs GRIF/CERN. Mécanisme à étudier (Biomed ?). Remarque : Déjà mis en place par le CERN. Update : Alice de Bignicourt fera un exposé dans une prochaine visio d'ici Noël concernant l'utilisation des certificats robots. S. Pop précise que les besoins d'une Nagios box séparée découlent d'un besoin de soumettre les tests avec aucun rôle particulier mais soumission avec une extension voms biomed -- necessité de comprendre si on peut paramétrer les timeout sur les sondes N. Lajili précise qu'il est possible d'annoter des résultats de la sonde dans Nagios pour son propore site pour des besoins de Reporting et d'Historique - explication pour les av/rel reports: Depuis l'interface nagios : depuis le host ou bien le service en bas de page il est possible d'utiliser "add a new comment". Il est possible de visualiser l'ensemble des commentaires par le menu à gauche "Comments" [NL, CLeroy, HC] Vérifier si la Nagios box recupère les DT de la GOCDB et les prend en compte pour la soumission des tests ou définir pour quelle finalité. J-M Barbet fait remonter le besoin de faire des sondes passives par un site, et de comprendre exactement ce sur quoi Nagios envoie des tests (sur ce qui est déclaré dans la GOCDB, ce qui est publié). Nadia précise que Nagios teste les noeuds qu'il trouve dans le TopBDII qui est alimenté à partir des BDII de sites enregistrés en GOC DB. Update :Nadia demande si la notion de sonde passive ne devrait pas être dans une documentation à publier sur le wiki [HC] envoie un mail au groupe monitoring dans ce sens. le filtre est effectué au niveau du dashboard - un ticket est ouvert sur les sites s'il y a mismatch de publication GOCDB/BDII par les ROD. Le dasboard remonte toutes les alertes et signale clairement les downtimes; il est recommandé de ne pas créer de ticket pour un site/noeud en downtime. [DB] Inclure dans un repository de bonnes pratiques : (1) "déclarer un noeud en construction dans la GOCDB et le mettre en downtime" pour ne pas avoir de "ticket" ouvert par les ROD sur les sites qui mettent un noeud en construction ou alors "monitoring off" tant que le noeud n'est pas en production. (2) En cas d'unscheduled downtime long, pour améliorer la disponibilité/fiabilité, déclarer un DT de 24h qui sera unscheduled (car il est déclaré moins de 24h avant son début) puis compléter avec un scheduled DT commençant exactement à la fin du unscheduled DT. (3) inclure un lien sur le wiki des ROD qui liste les sondes problématiques pour une visibilité des sondes problématiques en cours. (4) procedure d'utilisation du dashboard par un site : création/fermeture de ticket, utilisation du notepad en émission/reception [JMBarbet, Mario David, CLeroy] Pourquoi ca mets autant de temps pour introduire le cream-ce dans le calcul d'availability/reliability - Update : le cream-ce doit entrer doit le calcul d'availability très bientôt - cf OMB minutes du 26 Octobre. [DB, GGUS, CLeroy] Inventaire des catégories de sondes modifiables et des profils de "criticité" auxquels les sondes sont rattachées. JC Chevaleyre et C Carranza précisent que notre dépendance aux outils annexes à Nagios - My EGI, gridmap - doit rendre prudent tout effort de developpement/personnalisation de la part de la France. Notamment il faut vérifier la conformité de notre architecture - profils locaux - vis-à-vis des recommendations EGI s'il y a une configuration spécifique poussée de la part de la NGI_FRANCE. De plus, il y a un risque que les prochaines releases Nagios écrasent les configurations faites manuellement par la NGI_FRANCE. Il faut autant que possible faire remonter nos besoins au niveau du projet européen - suggestions sur le status des sondes - "warning" pour la sonde GGUS ou bien sur le service auquel rattacher une sonde - exemple sonde GGUS, ou bien encore sur le paramétrage des seuils temporels - exemple sonde GGUS qui devrait se déclencher suivant une procédure *a établir* soit au niveau de la NGI soit au niveau EGI, les 2 devant être compatibles. Update : La procédure de release des sondes Nagios est en cours de construction et doit être présentée à l'OMB du 23 Novpour approbation par les NGI. C. L'Ophelin annonce la release de My EGI en novembre ainsi qu'une version de gridmap version Nagios. HC pense que ces annonces doivent être relayées à operations-l, cc au groupe de monitoring. J-M Barbet réagit à la qualité des sondes qui n'est pas satisfaisante, et demande les moyens de masquer pour les rapports av/rel les périodes ou le site est pas responsable . HC précise que la méthode est manuelle et à posteriori à la publication des rapports d'av/rel pour l'instant. Update : [HC] a fait remonter cela à L'OMB du 26 Octobre et à la task-force en charge de la définition de l'OLA. Le groupe mentionne que le passage au Nagios régional induit une étape supplémentaire dans la mis à jour des CA, alors que la procédure actuelle ne prend pas en compte les délais nécessaires. David Groep doit mettre à jour la procédure héritée de EGEE. [CL] doit ouvrir un ticket concernant la procédure de mise à jour des CAs sur le Securrity management en "involvant" le EGI CSIRT, le groupe monitoring et le groupe de sécurité français. David Bouvet doit suivre, relancer ce ticket. Update: le ticket est GGUS#63145. HC rappelle que tout feedback des sites concernant MyEGEE/MyEGI, le comportement des sondes Nagios doit donner lieu à un mail au groupe monitoring qui ouvrira des tickets GGUS. HC doit pourvoir avoir des references GGUS pour pouvoir relayer les tickets qui stagnent. Prochaine réunion de OMB le 26/10/10. Update : Nadia demande si une rubrique dans le wiki France-Grilles ne peut être utilisée pour collecter les retours des sites avant aggrégation et ouverture de tickets GGUS [HC] envoie un mail au groupe monitoring dans ce sens. Exemples : (1) délai de création des sondes Nagios et leur prise en compte dans les algorithmes de calcul d'av/rel (cream-ce)- SUBATECH, (2) les inconsistences de My EGEE - LPC ne supporterait que la VO OPS - le vocabulaire dans My EGEE ( ROC-CRITICAL), (3) les problèmes sur le fonctionnement des sondes NAGIOS - possibilité de personnaliser les timeout des sondes (4) la prise en compte des downtimes dans NAGIOS - SUBATECH. *** H.C demande s'il existe une procedure d'utilisation du dashboard par les sites admins ==> les sites peuvent voir les alarmes sur ls autres sites et ouvrir des tickets sur eux-mêmes - il faut alors fermer des tickets via le dashboard. G. Philippon demande s'il peut y avoir une procedure et des outils simplifiés pour le changement du certificat du serveur VOMS. Cyril mentionne un tel outil pour 1er trimestre 2011 dans la release du broadcast v 2.0. *** Questions ouvertes de Christine Leroy - à aborder aussi dans la session Infrastructure: Y-at-il besoin d'intégrer des sondes grilles dans le Nagios local? ***