Comitato Tecnico sullInteroperabilità MUR, 22-07-2008 L. Merola.

Presentazione sul tema: "Comitato Tecnico sullInteroperabilità MUR, 22-07-2008 L. Merola."— Transcript della presentazione:

1 Comitato Tecnico sullInteroperabilità MUR, 22-07-2008 L. Merola

2 2 Agenda della riunione del Comitato Tecnico sullInteroperabilità dei progetti dellAvviso 1575/2004 MUR, P.le Kennedy, 20 – EUR ROMA 22 luglio 2008 - Ore 10, Sala CUN - I piano 1) Resoconto del convegno sullHPC (Cetraro) e di altri eventi. 2) Preparazione della partecipazione a SuperComputing 2008. 3) Stato dei lavori sullInteroperabilità e cooperazione in IGI. 4) Resoconto dellincontro di Catania tra i rappresentanti del ROC di INFNGrid e i progetti 1575 e discussione sulle azioni da prendere. Approvazione dellExecutive Summary.

3 3 Servizi aggiuntivi per gLite

4 4 Breve Verbale della Riunione: LIncontro dei Progetti PON Avviso 1575 con il ROC di INFN Grid, tenutosi a Catania il 4 Luglio 2008, ha mostrato la presenza di nuovi requirements provenienti dalle nuove comunità scientifiche utilizzatrici del Grid Computing supportante dai Progetti PON.Incontro dei Progetti PON Avviso 1575 con il ROC di INFN Grid Accanto a questi nuovi requirements ci sono delle customizzazioni del middleware prodotte dai PON, sia in termini di nuove componenti, sia di modifiche di quelle esistenti, per supportare specifici requisiti come: MPI, MPI2, Librerie Scientifiche, Software Commerciale, Accounting ed altro. E stata inoltre trattata la questione dei certificati robot, molto richiesti dalle comunità applicative. I progetti PON hanno segnalato la necessità che tali componenti vengano supportate sullinfrastruttura nazionale come condizione essenziale per la condivisione delle risorse. I rappresentanti del ROC hanno sottolineato la criticità dellargomento e lesigenza di selezionare le componenti più mature, in base anche ai requisiti delle comunità scientifiche di utenti che devono essere supportate. Executive Summary dell Incontro dei Progetti PON Avviso 1575 con il ROC di INFN Grid

5 5 Dal confronto dellattività di interoperabilità svolta con linfrastruttura del ROC, al di là del middleware di base, sono emersi altresì molti punti di contatto tra le due esperienze, in particolare lutilizzo di GStat, il concetto di un'unica VO che esegue i test di certificazione tramite SAM, la gestione dei downtime. Manca invece nellesperienza PON lutilizzo di alcuni strumenti ed automatismi come quelli forniti dal GOCDB. E stato segnalato che in prospettiva EGEE-III è stato pianificato di trasferire lonere di eseguire i job di certificazione a livello locale attraverso dei server di sito su cui gira Nagios. Ancora in relazione alla release, i progetti PON hanno segnalato le difficoltà riscontrate negli upgrade del middleware. Il ROC ha presentato il processo di rilascio della release INFN-GRID che pone rimedio ad alcuni bachi di gLite diminuendo altresì il numero di update. Resta aperto il problema di supportare più versioni della release o di avere delle guide per passare dalla versione n alla versione n+m, con m anche dellordine di 10 e oltre. Relativamente ai sistemi di ticket è stato presentato lattuale implementazione del supporto di EGEE-III che prevede un approccio centralizzato verso il Global Grid User Support (GGUS), al quale si agganciano i sistemi dei singoli ROC. Il ROC italiano utilizza un sistema basato su Xoops/Xhelp che parla con il GGUS tramite gSOAP in uscita e SMTP in ingresso. Non ci sono state proposte unitarie rilevanti per linteroperabilità tra i sistemi PON.

6 6 Possibile Piano Operativo (fino alla fine del 2008): 1)Partire subito con abilitare i job di Certificazione SAM fatti da EGEE. Questo permetterebbe di capire quanto le infrastrutture PON sono vicine dall'essere standard secondo i criteri di EGEE. 2)Abilitare quindi le VO OPS, DTEAM e INFNGRID, utilizzate unicamente per i job di certificazione, su uno o più siti pilota tra quelli dei PON e far partire dei test ad alta priorità e bassissimo numero di job contemporanei (per esempio, 1). 3)Interfacciare i sistemi di supporto dei PON a quello di INFN-GRID. 4)Definire e distribuire il questionario sulle componenti middleware aggiuntive da inserire nella release. 5)Definire un gruppo che studi e testi il supporto ai job MPI sviluppato allinterno del progetto PI2S2 su alcuni dei siti di INFN-GRID e dei PON, abilitando una o più delle VO dei PON. 6)Definire un gruppo che studi e testi il sistema di storage accounting sviluppato allinterno del progetto PI2S2 su alcuni dei siti di INFN-GRID e dei PON, verificando la sua integrabilità con DGAS. 7)Decidere una tipologia condivisa di hardware da acquistare allinterno dellinfrastruttura italiana nelle prossime gare. 8)Definire, da un punto di vista di politica scientifica, le condizioni per la condivisione delle risorse.

7 7 Sono emerse quindi le seguenti questioni: Studiare quali componenti middleware e quali software applicativi tra quelli prodotti e supportati dai PON possono essere introdotte nella release di INFN-GRID e diffusi nelle infrastrutture nazionali, e in che modalità. La collezione dei requirement sarà fatta mediante un unico questionario, opportunamente concordato, che sarà distribuito a tutti gli utenti delle varie infrastrutture (PON, INFN-GRID, altri membri di IGI, ecc.) Necessità di creare un gruppo tecnico operativo nazionale, eventualmente in ambito IGI, per gestire le questioni di release ed il supporto. Creare una release nazionale nata come customizzazione di gLite, che contenga i contributi di tutti: dei PON, di INFN-GRID e, in prospettiva, degli altri attori di IGI. La possibilità nellimmediato di inserire i progetti PON nel circuito di job di certificazione di EGEE al fine di vedere quali sono le difficoltà nel mantenere queste infrastrutture nel circuito EGEE puro, senza requirement specifici di INFN-GRID.