Rappel du contexte Room: 323 <br> Fiabilité insuffisante du protocole <code>gsidcap</code> utilisé par les jobs LHCb s'exécutant sur site pour l'accès aux fichiers gérés par dCache. Cette instabilité pénalise les utilisateurs LHCb. Le site a été banni par l'expérience à partir du 17/12/2009 pour cette raison. <br> <ul> <li>Ticket GGUS ouvert par LHCb daté 2009-12-14 13:16 UTC: <a href="https://gus.fzk.de/ws/ticket_info.php?ticket=54090">https://gus.fzk.de/ws/ticket_info.php?ticket=54090</a></li> <li>Ticket interne développeurs dCache: <a href="http://www.dcache.org/rt/index.html?q=5313">http://www.dcache.org/rt/index.html?q=5313</a> (accès restreint). Le problème a été observé par les développeurs mais il n'est pas facile de le reproduire. Il est donc difficile à ce jour d'avoir une estimation du temps nécessaire pour la correction du problème.</li> <li>Ce sujet a été abordé lors des réunions des développeurs dCache avec les représentants des tier-1s WLCG du 15/12/2009 et 05/01/2010. Des symptômes similaires ont été observés à SARA. Voir les minutes de ces réunions à l'adresse <a href="http://trac.dcache.org/projects/dcache/wiki/developers-meetings">http://trac.dcache.org/projects/dcache/wiki/developers-meetings</a></li> <li>La version dCache v1.9.5-11 déployée le 04/01/2009 ne corrige pas le problème</li> <li>La fréquence d'apparition de ce problème sur notre site est plus élevée que celle observée à SARA, qui rapporte de l'ordre de 2 échecs pour 3000 fichiers accédés.</li> </ul>

Discussion Room: 323 <br> Nous explorons les conséquences de l'introduction du support du protocole dcap, en particulier: <br> <ul> <li><i>LHCb: comment le logiciel de l'expérience sélectionne-t-il le protocole à utiliser (commande <code>lcg-gt</code> et/ou API GFAL)? L'ajout du protocole 'dcap' à la liste de protocoles supportés par notre instance dCache/SRM serait-il suffisant?</i></li> <br> Luisa a collecté et synthétisé les informations ci-dessous: <ul> <li>Les jobs LHCb s'exécutant sur notre site, comme sur les autres sites supportant l'expérience, sont en mesure d'utiliser les protocoles ci-après, dans l'ordre de préférence: <b>file, dcap, gsidcap, root, rfio</b></li> <li>Les jobs utilisent une API GFAL (<code>gfal_turlsfromsurls</code>) pour interagir avec le serveur SRM et obtenir le TURL d'un fichier en fonction des protocoles supportés par ce service.</li> <li>Du point de vue LHCb, il suffirait donc que le service SRM annonce le support du protocole <i>dcap</i> pour que le logiciel LHCb puisse l'utiliser, sans modification du logiciel de l'expérience.</li> </ul> <br> <li><i>Tests SAM: y a-t-il des conséquences sur les tests SAM de la VO OPS et ceux spécifiques à LHCb?</i></li> <br> Il y a 2 types de tests SAM des VOs OPS et LHCb qui ont rapport avec l'accès aux fichiers. D'une part, ceux qui testent l'accès aux fichiers à partir d'un site distant utilisent le protocole <code>gsiftp</code> uniquement. D'autre part, les test SAM qui s'exécutent sur site utilisent l'un des protocoles annoncés. <br> Par ailleurs, quelques un de ces tests récupèrent (via <code>lcg-gt</code>) la liste des protocoles supportés pour l'accès à un SURL mais ne déclenchent pas le transfert ou l'ouverture effective du ficher. <br><br> <li><i>dCache: quelles modifications sont nécessaires pour activer <i>dcap</i> pour LHCb? Y a-t-il des restrictions/contraintes à intégrer?</i></li> <br> Le protocole <i>dcap</i> peut être activé et servira à l'accès en read-only aux fichiers par les jobs s'exécutant sur le site. En conséquent, en absence d'identification du client (inhérente au protocole) l'accès en écriture à dCache pour la création de nouveaux fichiers ne sera pas possible. D'autre part, <i>dcap</i> ne peut être utilisé que par les jobs s'exécutant sur les worker nodes et les machines interactives du site. </ul>

Conclusions et Calendrier Room: 323 <br> Nous avons convenu les actions ci-dessous: <ul> <li>[dCache Masters] Le service dCache/SRM sera configuré pour supporter le protocole <i>dcap</i>. Les portes correspondantes seront activées dans l'instance de tests avant leur mise en production. <br>Uniquement les jobs s'exécutant sur site pourront utiliser ce protocole pour l'accès aux fichiers gérés par dCache. En conséquence, il n'y a pas besoin de modifier la configuration réseau au niveau de l'ouverture des ports. <br>D'autre part, le protocole <code>dcap</code> via SRM sera alors utilisable par toutes les expériences LHC, mais il est attendu qu'uniquement LHCb l'utilise, puisque Atlas et CMS utilisent <code>dcap</code> sans passer par la négociation de protocole SRM et Alice utilise Xrootd. <br>Aucun impact négatif n'est attendu pour ces expériences suite à cette reconfiguration, mais les experts locaux de ces expériences seront tenus informés du changement. </li> <i>Date limite: lundi 11/01/2010</i> <br><br> <li>[Luisa] Une fois les portes dcap configurées, valider que les jobs LHCb peuvent accéder les fichiers en utilisant le protocole <code>dcap</code>.</li> <i>Date limite: mardi 12/01/2010</i> <br><br> <li>[Luisa] Informer LHCb du changement de configuration afin que le site soit à nouveau considéré utilisable par l'expérience.</li> </ul>