Toward a stand alone distributed management system Generalization of SuperB distributed production system as stand alone, general purpose infrastructure to accomplish small and medium VO requirements ENRICO VIANELLO & MATTEO MANZALI > Progettazione del nuovo database
> Progettazione del nuovo database - idea di base db comune (elenco di tutte le possibili simulazioni - es. fast, full,... - informazioni sui siti) entità utili per l interfaccia (inserimento dei parametri del job e var ambiente) entità utili per il bookkeeping (produzioni, request, job, output, log...) db specializzato per un tipo di simulazione (es: fast simulation, full simulation,...)
> Progettazione del nuovo database - idea di base > Passi per la creazione dell ambiente di simulazione della VO: 1. inserimento del nome della simulazione (es. fast_sim, full_sim)
> Progettazione del nuovo database - idea di base > Passi per la creazione dell ambiente di simulazione della VO: 2. generazione del database di interfaccia per la simulazione inserita
> Progettazione del nuovo database - idea di base > Passi per la creazione dell ambiente di simulazione della VO: 3. inserimento dati riguardo: a. software da eseguire b. parametri dell eseguibile c. variabili d ambiente I punti b e c li chiameremo per comodità configurazione e ad ogni simulazione creata al punto 1 verrà associata una ed una sola configurazione b a c
> Progettazione del nuovo database - gestione parametri...stiamo valutando anche gli eventuali possibili benefici nell utilizzo di xml in supporto alla gestione dei parametri - work in progress!
> Progettazione del nuovo database - idea di base > Passi per la creazione dell ambiente di simulazione della VO: 4. salvataggio della configurazione e generazione del database di bookkeeping 5. uso dell interfaccia...
> Progettazione del nuovo database - diagramma ER riassuntivo:
> Progettazione del nuovo database - vincoli e problematiche ad ogni simulazione (fast, full,...) verrà associata una ed una sola configurazione di parametri PERCHE? - per generare una tabella {sim_name}_job che abbia tante colonne quanti sono i suoi parametri di input per semplificare il lavoro di visualizzazione lato monitoring - ad una simulazione associamo il test di un particolare software che avrà il suo insieme di parametri in input per ogni simulazione potranno essere create 1..n produzioni ( prod_series ) associate ognuna ad una particolare versione del software (tripletta: nome, version, revision) PROBLEMA? Cambio configurazione = creo nuova simulazione - avrei un nuovo tab nell interfaccia per ogni simulazione si può offrire la possibilità per l utente di nascondere simulazioni obsolete (senza eliminarle dal db) - ogni simulazione creata aumenta il numero di tabelle, però la presenza di tante simulazioni non appesantisce le query su una singola in quanto ogni simulazione agisce su un gruppo di tabelle separato (se avessimo tutti i job di tutte le simulazioni in un unica tabella...!)
> Progettazione del nuovo database - proposte consultandoci con Matteo Favaro, per una migliore generalizzazione, si pensava di: non imporre alla VO/noi di implementare una parte dello script Python per eseguire i propri job, ma bensì di implementare un generico modulo per l esecuzione di un job problematiche: tale modulo lancerà un file eseguibile prevediamo la possibilità di passargli parametri a riga di comando? forziamo il passaggio di parametri a coppie <chiave,valore> tra le variabili d ambiente? (già ora Bruno e PacProductionApp ricevono alcuni parametri d esecuzione in questo modo, come pure altri a riga di comando)
> Prossimi passi se il lavoro fatto fin qui può andare: creiamo sbk4 iniziamo il lavoro sulle classi php utili per: generare le parti del db interfaccia per l inserimento/gestione dei parametri inizio lavoro sulla web interface?