...............FAQ ABOUT TANK & SPARK

Q. Cosa accade se un WN che e' appena stato inserito nella farm (e non shera spazio disco) e' il WN su cui approda un nuovo job che installa nuovo software?

A. Se il WN condividisse l'area con altri WN, il problema cessa di esistere sia che ci sia o no "T&S". Qualora invece e' un nodo singolo ci sono due possibilita': installazione e disinstallazione.
Qualora il job installa nuovo software la sincronizzazione di questo nuovo software avviene senza causare danni al software preinstallato nella repository centrale. Successivamente il WN verra' sincronizzato con tutte le altre flags che ancora non ha avuto il tempo di installare.
Qualora si abbia un processo di rimozione di software (rsync usato con opzione --delete) non si corre alcun rischio in ogni caso perche' si presume che il software debba essere prima rimosso e se il WN e' vergine ed e' disk alone, non avendo il software per definizione, il processo di disintallazione fallisce e spark non deve essere invocato. In ogni caso rispetto al semplice caso "non shared", "T&S" apporta senza alcun rischio la possibilita' di inserire e automaticamente e aggiornare nodi e di permette un automatico recovery di nodi che erano un tempo della farm, poi dismessi e poi ristorati...

Q. Cosa accade quando un job di installazione arriva in un WN che monta un file system e questo, dopo l'installazione diventa irrensponsivo(NFS server down)?

A. Se si assume che nel WN lo spazio disco per il software dell'esperimento sia fornito tramite NFS questo e' un problema comunque (sia che ci sia "T&S" sia che non ci sia). Dei tests fatti simulando una tale situazione portano ancora una volta a dire che il software di esperimento nell'area shared e' sempre tutelato. Si e' provato a montare in una macchina un'area NFS e da questa si e' fatto rsnync verso una repository centrale. Poi si e' spento nfs nel server. Ogni comando (es. ls o du) della directory montata vanno stuck. Anche rsync non ritorna il prompt (anche settando un timeout). Una volta che ritorna su NFS rsync non compie alcuna azione e il contenuto della repository rimane immutato. Il tutto sarebbe riportato comunque come un errore di installazione al site e all'esm e pubblicato come failure nell'Information System. Tutto questo senza scancellare il software che c'era nella repository prima dell'installazione (o comunque non tanto piu' di quanto verrebbe fatto direttamente su NFS in caso di area condivisa.
Per il futuro si sta' pensando comunque ad un modo di controllo automatico dello stato del mounting nei WN che darebbe valore aggiunto alla semplice situazione di un file system shared, triggerando subito un allarme al site admin.

Q. Cosa accade alle flags nell'Information System per job di installazione che prescindono dal framework lcg-ManageSoftare?

A. Ci sono alcune cose da mettere in luce. "T&S" puo' agire sia come componente di un progetto piu' grande di cui lcg-ManageSoftware rappresenta il framwerk sia come applicazione client/server indipendente, usata perpropagare il software. Nel primo caso "T&S" e' stato pensato per modificare lo stato di alcuni processi (installazione/rimozione/validazione) in accordo all'esito della propagazione stessa. Tuttavia l'utente puo' benissimo usare "T&S" per propagare il suo sofwtare se non esiste il file system shared in mamiera trasparente. E' bene tuttavia che esso sappia che ci sono due casi in cui "T&S" puo' alterare cio' che l'ESM ha publicato nell'Information System del sito.

1. Un job di disinstallazione che rimuove la flag prima di iniziare la propagazione. Non esiste alcuna flag relativa a quel processo nell'IS e se qualcosa va storto, "T&S" riscrivera' questa flag come TAG-general-problem ed una e-mail notifichera' il site (e l'ESM) di quale il problema fosse.
2. Analogo al punto precedente. Un job di installazione arriva e non publica, (come accade spesso) la flag nell'IS (va detto che alcuni esperimenti tipo Geant4 fanno installazione senza validazione e pubblicano subito la flag). Siccome "T&S" non puo' sapere se e' fallito un processo di rimozione e/o di installazione, qualora qualcosa va storto nella sincronizzazione dei suoi WN, riscrive questa flag nell'IS come TAG-general-problem.
3. Un job di installazione/validazione simultanea arriva e pubblica subito la tag nel sito (TAG); qualcosa fallisce nella sincronizzazione. "T&S"cambiera' questa TAG pubblicata da TAG a TAG-aborted-validated significando che per lui il processo di validazione e' fallito.

Ogni altro caso e' il successo della propagazione e T&S e' backward compatible con il vecchio modo di operare. Rispetto ad una assenza di T&S di nuovo non e' tanto un limite quanto un valore aggiunto questo, in quanto, se si ha caso shared, comunque non ci sono fallimenti e le TAG rimangono tale e quali a quelle che l'ESM ha deciso, mentre se non c'e' file system shared si ha tracciabilita' di eventuali fallimenti.

Q. Cosa accade qualora la repository centrale e' accidentalmente scratchata?

A. Perdita globale di dati. Detta cosi' nessuno vorra' T&S nel proprio sito ma a questo punto ho alcuni argomenti che dovrebbero far ricredere. Qualora T&S runna in concomitanza di shared file system, la repository dovrebbe montare lo stesso file system dei WNs (un nodo piu' o un nodo meno non e' una grande differenza). Quindi se e' scratched questa area non vedo la differenza fra presenza ed assenza di T&S. Se tuttavia l'area non e' shared, la differenza rispetto la situazione attuale (WN stand alone) non puo' essere peggiore. In questo caso il software non e' mai nei WN!. Apparte queste considerazioni banali la prima cosa che mi viene in mente e' l'esigenza di rendere la repository quanto piu' stabile e difficilmente attaccabile (backup di questa area, mirrorring e quant'altro).Un accortezza che stiamo pensando e' quella di fare dei check periodici del contenuto di questa area rispetto alla situazione precedente. Il che significa che se qualcosa e' successo di recente (tipo la size della directrory VO_ATLAS_EXP_DIR e' zero, venga scatenato un allarme e si blocchino (gia' in piedi questo aspetto) tutte le future sincronizzazioni. Il software nel WN e' salvo. Una situazione analoga appare allorche' si accende T&S su un sito in cui gia' c'e' installato software e la repository non e' l'area shared ma bensi' una qualche altra area vuota. In questo caso bisogna seguire le istruzioni di configurazione prima di accendere Tank

Q. Cosa succede se ci sono piu' installazioni concorrenti per una stessa VO?

A. Tank gestisce questa casistica evitando che ci siano conflitti nella sincronizzazione. Solo quando la prima installazione e' stata propagata allora si sblocca e avra' inizio la seconda sincronizzazione.

Q. Cosa succede se l'installazione avviene su un WN che condivide il file system con altri WN?

A. Tank registra la nuova installazione e sa che essendo shared, il software e' anche in tutti gli altri WN che condividono l'area. Durante il processo di installazione tutti i nodi che sharano hanno bloccata la sincronizzazione lato server cosi' che non c'e' possibilita' di triggerare un'altro processo di installazione/sincronizzazione concorrente.

Q. Cosa succede se la propagazione fallisce?

A. Tank ha nota, nodo per nodo come la propagazione e' andata a finire. Se tutti i nodi hanno sincronizzato con successo, allora successo altrimenti se anche un nodo ha fallito si manda una email al site manager, all'esm se provvisto e si modifica la flag (il sapore) nell'information system. In caso di successo una e-mail e' mandata al site e all'ESM (se provvede l'indirizzo). Prevediamo un meccanismo di failure recovery che riprova sui nodi che hanno fallito fino a quando ha successo.

Q. Cosa succede se un WN va giu'?

A. Tank riceve ad ogni cron un segnale dai WNs. Se per qualunque ragione il segnale non arriva per 3 volte di seguito (30 minuti) considera il WN giu' e setta il suo status OFF. E' come se il WN non e' stato usato

Q. Tank supporta AFS?

A. al momento T&S supporta AFS relegando il mapping GSI->KRB5 tokens al tool gssklog.

Q. Cosa succede se Tank va giu'?

A Si ritorna al caso attuale. No intelligenza per la gestione del software

Q. Cosa succede se r-sync va giu'?

A Falliranno tutte le sincronizzazioni ma di fatto il sofwtare che sta nel WN (o nell'area shared) e' comunque salvo.

Q. Cosa succede se l'ESM si accorge che il sofwtare che ha installato e' bacato'?

A. Quello che succede con o senza T&S. Inzattera l'area shared e/o propaga una directory locale sporca. Per questo esistono i job di validazione.

Q.Nel caso pero' non sia possibile ripristinare la situazione prima di questa installazione (una libreria che andava bene prima ora e' stata rimpiazzata)?

A. Problema.. Tuttavia si stava pensando ad un meccanismo di roll back. Questo darebbe molto valore aggiunto a T&S anche con area shared. L'idea di base e' questa. Tramite l'intelligenza di Tank si fa una foto della repository quando l'ESM e' contento (cioe' nell'Information System tutte le flag sono pubblicate senza nessun strano flavour e tutti i processi di propagazione sono over con successo.). Questa condizione significa che tutto il software e' stato validato e quindi se ne fa una copia altrove. Se ora un ESM installa un qualcosa e si accorge che non va bene, si fa un bel roll back e la repository ridiventa come era prima. Prossima versione di T&S

Q. Come posso dare precedenza ai miei jobs di installazione? Meglio ancora come posso instyallare con una riga di comando dalla UI?

A. Si pensava di implementare l'installazione diretta da UI. In questo caso si bypassa tutta la catena del WP1 e si triggera l'eseguibile (che l'esperimento deve fornire) direttamente nel WN tramite T&S. Altro valore aggiunto allo shared file system attuale. Tutto e' in piedi, bisognerebbe solo assemblare.

Q. Cosa succede se nell'Information System la flag dice che il software e' in piedi in quel sito ma ancora non ha potuto finire di propagare il sofwtare a tutti i WN e un jobs atterra in un WN scoperto?

A.Questo non accadrebbe se si usasse tutto il framework che si basa appunto sull'uso di flag e sapori delle flag che monitorano come vanno i processi di Mangement di softare di esperimento. Tuttavia, come su tutte le cose, il job semplicemente fallisce e magari da li a qualche ora, il software sara' anche li'. L'esm potrebbe aspettare una notifica via e-mail da Tank per sapere se e' il momento di pubblicare la flag del proprio software installato in un certo sito