Struttura generale

Usiamo ogni sito computazionale che ci venga messo a disposizione da INFN-GRID e sperabilemente da EGEE-II, ma solo due siti (PD e CT) per lo storage dei dati. Dei servizi centrali privati conserviamo solo LFC (egrid-lfc-01.pd.infn.it, a Padova), LDAP dei gruppi (egrid-doc.egrid.it, sala macchine ICTP) e portale (portale.egrid.it, ICTP, attualmente in stanza EGRID). Deve essere previsto che la macchina ospitante il portale vada in sala macchine ICTP.

In ciascuno dei due siti di PD e CT è installato StoRM (versione "30 Giugno", SRM v2.1.1), configurato per prendere le ACL attraverso ECAR.

Job submission

Viene data priorità al portale, e gli utenti verranno incoraggiati a usare quello.

Viene conservata l'interfaccia a riga di comando e i comandi aggiuntivi EGRID solo se mantenere la compatibilità all'indietro è banale. Altrimenti, viene data priorità alle soluzioni e alle implementazioni nuove.

(nota Stefano: questo e' stato verificato ?)

Data management

Il data management si fa primariamente con i comandi egrid-get ed egrid-put (attenzione! potrebbero venire rinominati in egrid-upload e egrid-download per retrocompatibilità).

(Nota Stefano: questo serve ? come abbiamo deciso di chiamare i comandi ?)

Questi comandi avranno configurato (in un loro file di configurazione, oppure prendendo la lista da un sito online) una lista degli SE "sicuri" e limiteranno le operazioni di upload&download a quei siti.

Non verranno usati i comandi di data management di EGEE/LCG (lcg-*) perché non hanno modo di distinguere gli SE "sicuri" da quelli "insicuri" (e, tra l'altro, al momento attuale non interagiscono nemmeno correttamente con SRM v2).

Importante conseguenza: non si può usare il campo OutputData nel JDL, perché il RB/WMSLB usa GFAL (i.e., i comandi lcg-*) per le operazioni di data management.

NOTA (Antonio):

con Massimo ed Alessio avevamo studiato la possibilità di far sì che i job sottomessi dal portale possano utilizzare il campo OutputData, apportando opportune modifiche al sistema di generazione dello script proprio del portale; il portale genera uno script che lancia effettivamente il job, e si preoccupa di chiamare lcg-cp/lcg-cr; dovrebbe quindi essere sufficiente far sì che vengano chiamati egrid-download/egrid-upload.

(Riccardo M.):

1. ha funzionato? cioè: siete riusciti a far sì che il portale chiami egrid-upload/egruid-download invece di lcg-*?

2. questo introdurrebbe ancora un'altra dissimmetria tra la sottomissione tramite portale e quella a riga di comando, che può confondere ulteriormente gli utenti. Io sarei per semplificare e uniformare, a costo anche di perdere un po' di funzionalità.

   (Di Meo):

   per quanto lodevoli, secondo me tali modifiche ci (ri)mettono nella spiacevole posizione di dover ridiscutere tutta/parte della nostra architettura ad ogni variazione di _implementazione_ (e non solo funzionalita', come sarebbe lecito) del software che usiamo.

   (Riccardo M.):

   Non mi è molto chiaro: "tali modifiche": quali modifiche intendi? Rispondevi a me o ad Antonio?

Resta comunque aperta la possibilità per gli utenti di utilizzare i comandi lcg-* e globus-url-copy, a loro rischio e pericolo.

Sul sito di Padova verrà installato ELFI e verrà pubblicato un tag nel CE di Padova per indicare la disponibilità di ELFI. Gli utenti che vorranno usare ELFI, potranno farlo richiedendo il tag apposito nel JDL dei loro job.

Circa l'uso di ELFI Riccardo Murri, di fronte all'impossibilita' di gestire ELFI da sistema con script di prologue/epilogue (vedi nota di Alessio piu' sotto) propone:

uno script chiamato -mettiamo- elficmd che viene chiamato con un comando e i suoi eventuali argomenti (p.es.: elficmd echo "hello world") e fa le seguenti cose:

1. monta il fs ELFI sulla directory ./elfi
2. esegue il comando che gli viene passato (con i suoi eventuali argomenti)
3. smonta il fs ELFI da ./elfi

In codice shell:

mkdir -p ./elfi
elfi ./elfi
(exec "$@")
fusermount -u ./elfi

In questo modo un utente potrebbe lanciare un job con ELFI sottomettendo un JDL di questo tipo:

Executable="elficmd"
Arguments={"echo", "Hello world"};
Requirements = .... # quello che serve per il tag "VO-egrid-ELFI"

In pratica, nel JDL si metterebbe elficmd come comando da eseguire, ed il vero comando da eseguire con i suoi argomenti vanno tutti nel parametro Arguments.

L'idea viene accettata: va solo rilevato, che per avere concordanza con la sottomissione via portale lo script deve essere idempotente: se invocato per due volte agisce una sola.

(Riccardo M.)

Lo script elficmd è stato inserito nel subversion di ELFI dal 2006-10-09; attendo feedback.

Gestione dei permessi di accesso ai dati

Viene decisa l'abolizione del sistema della directory progetti/.

Rimane in uso l'applet di Angelo per la creazione e popolazione dei gruppi nel server LDAP; Massimo si occuperà della sua integrazione nell'attuale struttura del portale.

Per la concessione/revoca dei permessi di accesso a file condivisi, gli utenti useranno il comando lfc-setacl. Un sistema per l'impostazione di questi permessi attraverso il portale verrà creato dopo la release del 30 Ottobre.

ELFI

Sono individuati due usi per ELFI:

1. sulla macchina portale.egrid.it, per permettere il funzionamento della applet di data management del portale
2. sui WN di Padova, per promuoverne l'uso - ma i job dovranno farne esplicita richiesta attraverso l'apposito tag.

L'uso sulla macchina del portale è prioritaria e della massima importanza. L'uso sui WN di Padova è caldeggiato, ma non così importante, perché il meccanismo di default per il data management prevede l'uso dei client egrid-get e egrid-put.

Nella sottimissione dei job da portale dovrebbe essere possibile anche specificare l'uso di elfi al posto dei client egrid.

Stefano:

È vero questo ? Massimo puoi commentare?

Non è prevista nessuna azione di promozione o supporto di ELFI per le installazioni sulle UI.