Introduzione
6
Figura 1 Le risorse del CINECA
All’interno del gruppo Sistemi ad Alte Prestazioni (SIAP) si colloca appunto il mio tirocinio,
durante il quale ho svolto attività di supporto nella realizzazione del portale. La macchina
su cui ho lavorato, denominata FEC (Front-End Cluster) ha le seguenti caratteristiche
hardware-software:
Modello: IBM x346
Architettura: IBM Linux Cluster
Tipo di Processore: Intel® Xeon™ 3.20GHz (1024 KB cache)
Nodi: 14, con 2 CPU per nodo
RAM: 8306004 KB (8 GB)
Rete Interna: Ethernet
Hard Disk: 4 da 36 GB
Sistema Operativo: SLES 9 i386 (SuSE)
Il portale dei servizi si compone di 7 componenti: un sistema di gestione dei contenuti
(Plone), un sistema di Grid (Enginframe), un gestore delle risorse si storage (SRB), un
insieme di repository per la gestione concorrente del codice sorgente (CVS), un sistema
di trouble ticketing (RT), una directory per l’identificazione e l’autorizzazione degli utenti
(LDAP) e infine un sistema per monitorare gli accessi ai siti Web (Webstats Manager).
Introduzione
7
Una architettura così complessa non può prescindere da un aspetto dell’informatica che
prende il nome di “standard”. Nel seguito del documento sarà quindi analizzato JSR-168,
insieme di specifiche per l’interoperabilità di portali grid e portlet basate su Java. Di
alcune di queste parti (Plone ed Enginframe) mi sono occupato direttamente tramite
ricerche sul Web e confronti di tecnologie e software, di altre (Webstats Manager) sono
stato sviluppatore, di altre ancora (SRB, CVS, RT, LDAP) ho avuto invece una semplice
visione dall’esterno.
Il lavoro svolto con il team SIAP si è articolato in varie fasi, che sono qui brevemente
riassunte:
Inizialmente ho svolto lavori di documentazione effettuando recensioni di software
CMS, CMF e grid. Tali recensioni hanno avuto da un lato lo scopo di analizzare lo
stato dell’arte nel campo dei software di gestione dei contenuti della gestione di job
remoti e dall’altro lato di servire come mia personale documentazione sugli
argomenti che avrei approfondito in seguito. I lavori di recensione e confronto da me
svolti sono stati utilizzati per confermare la scelta di Plone ed Enginframe come
software CMS e grid e per focalizzare l’attenzione su alcune tecnologie che vale la
pena di monitorare per il futuro.
In un secondo momento ho concentrato la mia attenzione sul lato CMS, studiando la
software stack del FEC, composta dal linguaggio di programmazione Python,
dall’application server Zope e dal Content Management System Plone.
Infine, mi sono occupato dell’analisi delle statistiche dei siti Web ospitati sul FEC, e in
seguito dell’automazione di questo lavoro tramite lo sviluppo di Webstats Manager,
un prodotto per Plone il cui scopo è la creazione di un’interfaccia Web per la gestione
dei file di configurazione di Analog e Report Magic, due strumenti per il calcolo delle
statistiche di accesso ai siti Web a partire dai log di Apache.
La presente tesi è organizzata in 6 capitoli principali:
Capitolo 1 (Specifiche del Progetto) Il primo capitolo descrive il modello XP utilizzato
per l’organizzazione e la suddivisione del lavoro all’interno del team SIAP ed elenca gli
use case del portale dei servizi. Al termine del capitolo si osserva come la realizzazione
del portale non possa prescindere da un’attenta analisi degli standard, quindi segue una
breve analisi dello standard Java per le portlet, JSR-168.
Capitolo 2 (Gestione dei Contenuti: Plone) Il secondo capitolo si occupa della parte
del portale che ha l’onere di gestire la documentazione. Dopo una sommaria analisi dei
requisiti richiesti sono recensiti alcuni dei più famosi Content Management System. Nella
Introduzione
8
seconda parte del capitolo si passa dal CMS al CMF, il Content Management Framework, e
dopo aver discusso su analogie e differenze tra queste due categorie di software si
confrontano i due maggiori CMF: Plone e Lenya.
Capitolo 3 (Gestione dei Job: Enginframe) Il terzo capitolo va in profondità nel
portale e analizza la parte di gestione dei job che è il vero cuore pulsante del sistema. In
questo capitolo si parla di Grid Computing e sono recensiti alcuni dei sistemi di Grid più
diffusi, quali OGCE, GridSphere, uPortal e – appunto – Enginframe.
Capitolo 4 (Altre tecnologie: SRB, CVS, RT, LDAP) Il capitolo quarto riassume tutte
le tecnologie delle quali non mi sono occupato direttamente ma che per completezza vale
la pena di citare. Nella fattispecie è presentato il sistema di gestione dei dati, SRB
(Storage Resource Broker), il sistema di versioning del codice sorgente, CVS (Concurrent
Versioning System), il sistema di gestione dei ticket, RT (Request Tracker) e il sistema di
memorizzazione degli utenti, LDAP (Lightweight Directory Access Protocol).
Capitolo 5 (Webstats Manager) Nel quinto capitolo è descritto il sistema di gestione
delle statistiche dei siti Web, interamente sviluppato dal sottoscritto come prodotto Plone
e frutto di oltre un mese di lavoro.
Capitolo 6 (Analisi delle Statistiche Web) Nel sesto ed ultimo capitolo sono analizzate
le statistiche di accesso ad alcuni dei siti ospitati dal CINECA al momento della stesura del
presente documento.
Specifiche del Progetto
9
Capitolo 1
Specifiche del Progetto
Theory is when you know everything, and nothing works.
Practice is when everything works and no one knows why.
In our lab, theory and practice are combined:
nothing works and no one knows why – Lockheed Martin
Obiettivo di questo capitolo è definire il piano di sviluppo di una parte del portale dei
servizi, partendo dalle user requirement a disposizione. Per lo sviluppo adottiamo un
modello XP-like
1
, fatto di storie che descrivano gli use case e le feature da implementare,
e delle release che raggruppino queste storie in insiemi coerenti, da rilasciare nel corso
del periodo di sviluppo.
Iterazioni Il piano di release si basa su cicli di sviluppo, iterazioni, di durata settimanale,
eventualmente estendibili a bisettimanali in un secondo momento; al termine di ogni
iterazione saranno valutate le storie implementate e assegnati i task per lo sviluppo
nell'iterazione successiva. La fine dell'iterazione prevede in genere un breve incontro,
mentre durante l'iterazione si susseguono le comunicazioni informali tra sviluppatori e
sviluppatori ed expert.
Release Per i cicli di release si immagina di raggruppare all'incirca 6-9 iterazioni (1.5-2
mesi), variabili a seconda del numero di storie assegnate e della stima preliminare sui
tempi di implementazione. Le release si intendono come interne, lasciando al
responsabile dei servizi la decisione di quali di volta in volta mettere in produzione.
Expert Lo sviluppo è guidato dalle storie, che rappresentano le user requirment spezzate
in elementi funzionali. Le storie vengono scritte dagli expert (persone autorizzate a
definire i requirement), che sono responsabili di certificarne l'avvenuta implementazione.
Dagli expert ci si aspetta la disponibilità a provare e certificare la chiusura non solo delle
storie ma anche i singoli task che le compongono.
Test di accettazione Ad ogni storia dove corrispondere un test di accettazione che ne
attesti l'implementazione. I test di accettazione devono essere definiti dall'expert, e la
dove possibile implementati con il supporto dello sviluppatore di modo da poterli
automatizzare. I test di accettazione possono essere costituiti, o affiancati, da un insieme
1
XP (che in questo contesto non ha niente a che vedere con i sistemi operativi di casa Redmond) è
un modello di sviluppo del software basato su “semplicità, comunicazione, feedback e coraggio”. Cfr.
http://www.xprogramming.com/xpmag/whatisxp.htm.
Specifiche del Progetto
10
di test sul codice, unit test, che consentano di testare le funzionalità di singoli componenti
nel tempo. Questi test rimangono poi come regression test e consentono di verificare la
funzionalità del portale nel tempo (vedi prossimo paragrafo).
Test di regressione Gli unit test, non nascono in genere non come strumento per
certificare la chiusura di una storia, ma soprattutto per verificare la funzionalità del
codice nel tempo, di modo che future modifiche al codice non compromettano funzionalità
delle storie già implementate. Al fine di dotarsi di strumenti automatici per il regression
testing, si dovrà allocare delle spike per individuare dei prodotti di test.
Velocity Le stime di tempo vanno sempre considerate in giorni uomo equivalenti, valore
che và diviso per la velocity per ottenere le stime in giorni uomo reali. Mediamente le
velocity si attestano intorno a .5, quindi si può partire con questa prima ipotesi. Ogni task
può essere affrontato da 1 o 2 persone in coppia. Nel caso due persone debbano lavorare
allo stesso task, chiaramente la velocity tende a scendere in modo naturale a 0.5.
Piano di release "Portale dei Servizi"
XP-Release 1 / Tecnologia di Base
Sistemi di Autenticazione e Autorizzazione del portale:
1. Integrazione fra l'authentication di EF e LDAP cineca: gli utenti di EF devono
essere gli utenti CINECA (gli stessi usati da plone)
(EF<->LDAP) spike 3gg + 3-5gg lavoro GESI
2. Integrazione fra l'authentication di Plone e LDAP cineca.
(Plone<->LDAP ) spike 7gg+ 1-3gg lavoro GESI [vedi Storia (1) di User
Account Preferences]
3. Sigle sing On fra Plone ed EF (e viceversa da EF verso Plone)
(Plone-EF Single SignON) spike 5gg
Installazione della software stack:
1. Definizione, installazione e configurazione della SW necessaria per Plone.
(Installazione Istanze Plone) task da 2gg per l'installazione del SW, la
creazione delle istanze di produzione e di pre-produzione
Specifiche del Progetto
11
2. Definizione, installazione e configurazione della SW necessaria per Enginframe.
(Spike migrazione EF 4.1) spike di 5gg per l'adattamento della struttura dei
plugins alla versione di EF corrente
3. Creazione di una Customization Policy per creare il sito base del portale (solo
servizi base e NO contenuti!) Questa policy andrà poi aggiornata nel tempo...
(Plone Install Policy) task da 5gg per la parte di oggetti custom, struttura e
permessi + 3gg per la parte di layout
XP-Release 1 / Servizi per la gestione degli Account
User account preferences. Questo servizio fornisce un'interfaccia WEB che consente ad
un utente di modificare le informazioni relative al proprio account:
1. L'utente fa accesso al portale tramite user e password che sono gli stessi delle
macchine (LDAP).
Per questa storia si tratta procedere con lo studio e l'integrazione di uno dei
prodotti di autenticazione tramite LDAP. Sembrano ce ne siano vari, alcuni
dei quali possono integrarsi con un DB esterno.
(Plone<->LDAP ) Prevederei una Spike (5gg) per analizzare uno o due di
questi prodotti Plone e provare ad installarli. (vedi anche "Tecnologia di
Base") Alla fine della spike un task da 2gg per finalizzare l'installazione nel
portale e creare il test....
Si deve scegliere la forma di autenticazione condivisa: se si opta per LDAP si
tratta di predisporre il server LDAP del gruppo GESI per l'accesso da parte
del plone del portale (solo quello?), o di creare un nuovo LDAP che mirrori
tutti e soli gli utenti per il portale. Immagino sia necessario del lavoro da
parte di GESI in tal senso: diciamo un task di 2-3gg se è già tutto chiaro, od
eventualmente una spike di 5gg se a loro non è chiaro come fare. Alla fine
della spike si dovrebbe disporre della miglior soluzione per eseguire
l'integrazione dell'autenticazione.
(Plone-EF Single SignON) Una spike di 5gg per analizzare il problema del
single sing-on fra fra plone ed EF (vedi anche "Tecnologia di Base").
Specifiche del Progetto
12
Tempo già conteggiato nelle storie di "Tecnologia di Base -> Sistema di
Autenticazione e Autorizzazione del Portale"
2. L'utente può modificare la propria password tramite portale.
(change password) Per questa storia si potrebbe modificare la portlet per il
change password che viene richiamata dal "change password" del "my
preferences". Questa cosa potrebbe venire abbastanza gratis
dall'integrazione con l'LDAP GESI, ma è tutto da verificare. Direi che questa
storia dovrebbe seguire alla (1). Diciamo un task da 3gg + 1gg per ritocchi
di presentazione
3. L'utente che ha dimenticato la propria password non può recuperare la propria
password da portale, ma può utilizzare un sistema basato sul proprio e-mail,
registrato nel portale stesso, per autenticarsi e resettare la propria password. La
cosa è molto usata nei portali commerciali.
(password forgotten) questo è già disponibile come funzionalità di Plone,
una volta che sia integrato con il sistema di autenticazione. Direi 1gg di
lavoro giusto per verificare che si comporti come deve.
4. L'utente autenticato ha accesso alle informazioni che lo riguardano: quelle
"anagrafiche" (nome, cognome, indirizzo)... e quelle "operative" (e-mail). Può
modificare tutte le informazioni (dipartimento, indirizzo, n. di telefono,...
soprattutto e-mail) tranne quelle "invariabili" (nome, cognome, data di nascita,
CF): l'utente non può modificare l'intestatario di uno username, ma se cambia
affiliazione deve poterlo fare da solo. Gli username sono personali.
Credo che questa parte rientri nel progetto "Gestione Utenti": in questo caso
si tratterebbe di creare un nuovo tool nelle preferences dell'utente, che
riproduca le funzionalità previste per la registrazione dei nuovi utenti del
progetto gestione utenti. Forse si può riciclare gli stessi oggetti o
quantomeno riadattarli. (3-5gg.)
5. L'utente può decidere con un "tick-mark" a fianco del campo "e-mail" se ricevere
o meno le informazioni da hpc-news (mailing list cineca). Non credo che il
portale debba sostituire la mailing list. Abilitato di default.
Questa cosa credo rientri nella form di gestione utenti.
Specifiche del Progetto
13
6. L'utente può inserire una lista di e-mail di collaboratori nel portale: Può decidere
per ciascun e-mail se iscriverlo in hpc-news o meno. Questo permette di
mantenere inalterato l'approccio corrente "a gruppo di ricerca", ma sottolinea il
ruolo del responsabile dell'account.
anche questo rientra nella gestione utenti. Si tratterà di implementare ed
integrare l'oggetto collaboratore: 2-5gg
Account administration Questo servizio fornisce l'interfaccia Web che consente ad un
interno di amministrare gli utenti dei servizi.
1. L'interno può reimpostare la password di ogni utente.
(internal change password) Da vedere come integrare con la gestione
utenti, in particolare si ricollega alla storia (2) delle "Account Preferences".
Si tratta più che altro di capire come gestire i permessi perché anche un
utente interno possa modificare la password: spike 3gg
XP Release 1 / Servizi per l'accesso ai Filesystem
Remote File System Browsing. Questo Servizio consente all'utente di scorrere il FS
interno del CINECA. Per l'accesso ad SRB immagino si nasceranno altre storie...
1. L'utente deve poter accedere dal portale a $CINECA_HOME e $CINECA_DATA.
(spike FS browser) Spike con Nice (Bruno) per trovare soluzioni migliori al
meccanismo di browsing 5gg.
(FS browser V1 ) OK. Si tratta di finalizzare l'implementazione (con l'attuale
tecnica od una nuova derivante dalla (spike FS browser), risolvendo il bacco
del "Your Data". 3gg per la logica + 2gg per il layout.
2. L'utente deve aver percezione immediata che su $CINECA_HOME è disponibile il
backup, su $CINECA_DATA no.
Rientra nel lavoro di presentazione del precedente.
3. L'utente deve poter accedere anche a $CINECA_SCRATCH delle macchine su cui
è definito il suo username (ragionare se $CINECA_SCRATCH debba ancora
essere /scratch e basta o possa diventare /scratch/$USER).
Specifiche del Progetto
14
(SCRATCH FS browser) Spike da 5gg per capire come implementare questa
cosa dell'accesso allo scratch, che sta sulle singole macchine e non è un FS
condiviso.
Advanced Features:
1. Per accedervi si può immaginare una struttura ad albero, tipo questa di plone.
OK viene con "FS browser V1" della precedente
2. L'utente deve poter fare "bookmark" di posizioni nel filesystem. Sia che si tratti
del bookmark del browser che di un bookmark mantenuto internamente al
portale.
Da verificare: se fa bookmark del browser potrebbe essere OK, perché si
tratta di un servizio che usa il metodo "get" per passare il path.
3. La visualizzazione da portale deve (poter) contenere almeno le stesse
informazioni accessibili da ls -l: permissi, data ultima modifica, dimensione.
(FS browser V1 permissions) Nella spike su FS browser verificare se ci sia
da riadattare il servizio di browsing fornito di serie da EF. Se NO + 1gg per
la finalizzazione del codice + 2gg per sistemare il layout. Se si rimandato a
prossima release.
4. L'utente può decidere se ordinare i file per nome, data, size,...
(FS browsing sort) da verificare il discorso del sorting fornito da EF: spike
1gg. Nel caso non sia supporto si rimanda a release successiva con
reimplementazione del bowsing.
5. Per l'utente deve essere possibile effettuare le operazioni tipiche di un generico
filemanager (copia, rename, move, delete, mkdir,...) sia all'interno dello stesso
filesystem, che tra filesystem diversi che verso il client Web (get, put di file). Si
possono pensare anche operazioni "intelligenti". Per esempio facendo "get" di
una directory, viene trasferito un tar gzipped della directory stessa. Use case da
migliorare se necessario. Immagino ci siano strumenti già pronti per questo tipo
di interfaccia.
OK, EF dà già delle azioni (quindi rientra in "FS Browser V1"), nel caso non
bastino si deve mettere in campo il task di reimplementazione NON previsto
per questa release.
Specifiche del Progetto
15
File System browsing managment. Questo servizio consente all'interno di decidere
cosa l'utente può vedere e di vedere le informazioni relative al FS per tutti gli utenti.
L'utente comune può vedere le proprie info ma non quelle altrui.
1. L'interno deve poter definire anche altri filesystem a cui l'utente ha accesso. Per
esempio, per gli username di AGIP Simone deve poter dar loro accesso ad
/agip_scratch. Questi filesystem possono essere o locali ad una macchina, o
condivisi.
o (FS Managment V1) la lista dei FS abilitati dovrebbe quindi essere una
lista di servizi ognuno con i suoi permessi, di modo da differenziare. In
prima istanza per aggiungere nuovi FS è necessario aggiungere un
servizio, non si può semplicemente aggiungere un path ad una lista. In
tal caso questa storia si chiude con un piccolo lavoro per definire come
lasciare all'interno gestire i permessi plone 1gg per implementare
questa modalitàNB: per limitare l'accesso al FS sottostante al portale si
deve usare il tool per settare i permessi del FS!
o (FS Managment V2) In seconda istanza si può prevedere di
reingegnerizzare il servizio di browsing dei FS perché peschi da una
lista di risorse FS. NO in questa release.
XP-Release 1 / Applicazioni di Calcolo
Applicazione Fluent:
1. Creazione di servizio per l'esecuzione del Codice di calcolo Fluent.
L'interfaccia di sottomissione deve consentire di passare i parametri
necessario all'esecuzione dell'applicazione
L'utente deve poter selezionare i file di input già presenti sul server o di
caricare file da locale.
Terminata l'esecuzione deve essere possibile scaricare i file risultato della
simulazione
(Fluent Web) Crezione dell'applicazione EF che definisce la maschera di
sottomissione e lancia lo script di Fluent passando tutti i parametri necessari
(7gg)
Specifiche del Progetto
16
(Fluent Script) Integrazione dello script di esecuzione dell'applicazione
fluent: importante integrarsi con lo scheduler per quel che riguarda code e
macchina su cui eseguire (5gg)
Per quel che riguarda il caricamento e download file questi dovrebbero
venire con l'interfaccia di EF nella applicazione e agli spoolers.
Documentazione:
1. La documentazione sulle macchine del CINECA è accessibile a tutti, anche agli
esterni. Vedi anche "software".
2. E' possibile realizzare aree documentali (plone, twiki,...) accessibili solo ad
uno/alcuni utenti/gruppi di utenti.
(Doc Areas) Plone fa proprio al caso. 3gg per crearle nel posto giusto e con
i permessi giusti
(Doc Publish) Lavoro nel caso ci sia della documentazione già esistente da
preparare e mettere sul sito 2-5gg
3. L'interno può scrivere la documentazione come qui con plone.
4. La documentazione non è automaticamente pubblicata: l'interno deve fare
"publish" per rendere visibile la documentazione a tutti. Prima di publish e
visibile e modificabile anche dagli altri interni.
(Doc Review) OK si manterrà il workflow di pubblicazione di plone: le cose
da mantenere nascoste del portale dovranno essere messe "private" o altri
stati con permessi limitati solo ai ruoli autorizzati. Gli interni saranno inseriti
nel gruppo dei Reviewers, di modo da assumere ruolo "Reviewer". 3gg di
lavoro per verificare i permessi ed i workflow.
5. L'interno può fare upload di documenti o immagini (ed impostarli come copyright
o no).
OK.
Specifiche del Progetto
17
6. Nel momento in cui un interno modifica o aggiunge della documentazione, viene
inviato un avviso agli utenti che l'anno consultata recentemente (es: entro un
mese prima).
(Doc Watching) questo è già più difficile: spike 3gg cercare un prodotto per
il watching!
7. Eventuale documentazione caricata con Copyright è accessibile solo da utenti ed
interni.
OK. Rientra in "Doc Areas"
8. La struttura della documentazione deve essere studiata a tavolino, ed affidata a
poche persone (doc manager).
OK. Rientra in "Doc Areas"
Avvisi:
1. Gli interni possono inviare avvisi agli utenti.
Servizi di avvisi per tutti si possono implementare usando come base gli
oggetti News di plone: vedi dopo "News Service".
2. Un utente può ricevere uno di questi avvisi:
e-mail: avviso personale, interrupt. Non è necessario l'accesso al portale Æ
OK. Il portale prevede già di mandare mail in varie condizioni. Casi extra
vanno gestiti uno per uno.
hpc-news: avviso collettivo, interrupt. Non è necessario l'accesso al portale
Æ da integrare con la gestione utenti e servizio News: registrazione alla
mailing list dalla form dell'account. Vedi inoltre "News Service".
recent items: avviso personale o collettivo, polling. L'utente vede tali avvisi
solo quando si collega al portale Æ (News Service) Servizio di News. Con
questo l'utente autorizzato può pubblicare News e quando una news è
pubblicata viene anche inviata una news sulla mailing list hpc-news: 5gg per
capire le use case esatte ed implementarle.
XP-Release 2 / Tecnologia di Base
Specifiche del Progetto
18
Sistemi di Autenticazione e Autorizzazione del portale:
1. Uso della authorization di EF per limitare l'accesibilità ad un servizio a seconda
dell'utente: ad esempio certi servizi devono essere fruibili soltanto agli utenti
interni, o presentarsi in modo diverso a seconda del profilo dell'utente. Si
suggerisce di prendere uno o due dei casi che prevedono questa situazione e di
applicare il lavoro a quel caso.
(Authorization EF) Spike 5gg
XP-Release 2 / Servizi per l'accesso ai Filesystem
File System browsing managment:
1. L'Interno può definire e modificare la quota dei filesystem degli utenti.
o (Disk Quota Admin) un servizio per settare le quote (lato Unix).
Dovrebbe però poi esserci una parte in "Gestione Utenti" per specificare
le quote disco. 5gg per l'implementazione+1gg per il layout
XP-Release 2 / System Monitor
Stato delle macchine:
1. L'utente ha modo di vedere sul portale lo stato delle macchine a cui:
ha accesso;
potrebbe avere accesso, ma non ce l'ha Æ nel caso si voglia limitare la
visibilità dello stato c'è dà far sì che il servizio di monitoring interroghi il
portale per sapere a quali macchine ha accesso l'utente (vedi gestione
risorse)e filtri l'output dei comandi di sistema, in quanto quest'ultimi (e.g.
lsfcluster) non pone limiti nella visibilità dello stato. vedi "System Monitor"
2. L'utente non può vedere lo stato delle macchine a cui non può avere accesso
(non può vederne nemmeno la presenza).
vedi "System Monitor"
3. Lo stato di una macchina è rappresentato dalle seguenti condizioni:
in produzione (accounting attivo) o in fase di test (accounting non attivo);
Specifiche del Progetto
19
OK (verde), temporary problems (giallo) o not available (rosso). Corrente e
storico.
carico della macchina, utilizzo della memoria, dimensione/spazio libero dei
filesystem locali ($CINECA_SCRATCH) corrente e storico (tipo ganglia);
tempo di attesa di un job corrente e storico. In questo caso è utile definire
una metrica, tipo: tempo di attesa del job medio che ha girato nelle ultime
24 ore, oppure istogramma dei tempi di attesa vs numero di processori
richiesti. Queste metriche sono molto utili a noi ed agli utenti per stabilire
quale macchina utilizzare e se una macchina si sta "comportando bene":
dato il sistema di code il carico istantaneo non è un buon indice del carico
della macchina, che dovrebbe essere sempre "piena", mentre lo è il tempo
di attesa dei job Æ (System Monitor) c'è da capire da dove prendere l'info
sull'attivazione (sistema informativo?). Per le informazioni storiche si può
pensare di prendere l'output di ganglia, però quest'ultimo deve essere un
servizo garantito! per le stime sui jobs c'è da sviluppare un modulino che le
faccia. 5gg per la parte del sistema informativo + 3gg per l'integrazione
delle info da ganglia, o 5gg per lo sviluppo di un modulo che le generi da
altre fonti. 5gg per la stima del tempo del job. Più 5gg per il layout -> tot.
+/- 18-20gg
4. La macchina deve comunicare il proprio stato al portale in modo indipendente.
Non deve essere un'azione da eseguire da parte di un interno. Affidare lo stato
della macchina al lavoro umano significa che non è aggiornato, quindi non
affidabile, quindi inutile.
In generale OK, se c'è un posto dove andare a predere le info. Però per lo
stato della macchina (account attivo, debug, produzione), forse è una info
che va messa nel sistema informativo (nell'oggetto risorsa).(vedi "Gestione
Risorse")
XP-Release 2 / Servizi per la gestione dei Jobs
Servizio di Job Monitoring. Questo servizio consente all'utente di visualizzare i job che
girano, sono in coda o sono già terminati.
1. L'utente può vedere in un'unica schermata (job screen) tutti i job che ha in coda,
che stanno girando e che hanno girato su tutte le macchine.
Ricevi informazioni sui nostri servizi, sulle offerte e non perdere news e consigli su università e lavoro.
