Tags:
, view all tags

TESTS

  • Normal jobs work: OK

  • Dag jobs work: OK

  • Collection jobs work: OK

  • Parametric jobs work: OK

  • Bulk jobs work: OK
    • Submit a bulk of 3 jobs
    • Submit a bulk of 50 jobs
    • Submit a bulk of 100 jobs
    • Submit a bulk of 500 jobs
    • Submit a bulk of 1000 jobs

  • Perusal jobs work: OK

  • MPICH jobs work: OK

Check bugs:

  • BUG #35250: "glite_wms_wmproxy_dirmanager does not extract links from tar.gz" FIXED
    • submit a dag job with the .jdl attribute AllowZippedISB=true set
    • Check the job finishes successfully

  • BUG #39903: "Fermilab proxy cannot submit to WMS SL4, they are ok with SL3" FIXED
    • submit a job using a proxy with UID or USERID in the DN
    • check that the sandbox gets transferred correctly and the job finishes successfully

  • BUG #42587: FIXED
    • Submit a dag with these dependencies:
      • dependencies = { {{nodo1,nodo2,nodo3},final} };
    • and in the final node description set:
      • InputSandbox = {root.nodes.nodo1.description.OutputSandbox,root.nodes.nodo2.description.OutputSandbox,root.nodes.nodo3.description.OutputSandbox};
    • Then issuing the command glite-wms-job-info --jdl <jobid> the InputSandbox of the final node should be:
        InputSandbox = { "gsiftp://devel14.cnaf.infn.it:2811/var/glite/SandboxDir/2P/https_3a_2f_2fdevel17.cnaf.infn.it_3a9000_2f2Pa1jpof6pDVca7mBfZVCg/output/std1.out","gsiftp://devel14.cnaf.infn.it:2811/var/glite/SandboxDir/SF/https_3a_2f_2fdevel17.cnaf.infn.it_3a9000_2fSFC5OGoUDPmB5f32n60w9A/output/std2.out","gsiftp://devel14.cnaf.infn.it:2811/var/glite/SandboxDir/Ux/https_3a_2f_2fdevel17.cnaf.infn.it_3a9000_2fUxUdVBRNPOX0u3vDHJ3X1Q/output/std3.out" }

  • BUG #42590: "The WM terminates unexpectly handing a cancel request." HOPEFULLY FIXED
    • Submit several collections made of 100 nodes
    • Send cancel on some children nodes
    • The wm keeps running happily smile

  • BUGs #44761, #44762: HOPEFULLY FIXED
    • It is very difficult to replicate these bugs, you can try submitting a lot of collections setting short expire and matchmaking periods (i.e. ExpiryPeriod and MatchRetryPeriod) in the configuration file and then restarting some times the workload manager on the WMS to trigger the recovery mechanism.

  • BUG #44763: FIXED
    • Submit a collection with an expired time (i.e. ExpiryTime=
    • The collection and all its nodes should be Aborted with reason "request expired"

  • BUG #45391: FIXED
    • Submit a collection with at least a node that doesn't match (e.g. put requirements=false)
    • After the match making of the collection, the node should be put in state Waiting with reason: "BrokerHelper: no compatible resources"
    • Check if the request of the collection is in the directory $GLITE_LOCATION_VAR/workload_manager/jobdir/old (i.e. you should find a file like 20081218T092023.381155_3086493376)
    • Manually restart the wm on the WMS (i.e. $GLITE_WMS_LOCATION/etc/init.d/glite-wms-wm restart)
    • In a while the recovery process should re-match the node and the request should be put again in the $GLITE_LOCATION_VAR/workload_manager/jobdir/old directory
    • Check that after the node request will expire (i.e. after ExpiryPeriod seconds), at the next matching session the node should be aborted (with reason: "request expired") and the file should be removed from the $GLITE_LOCATION_VAR/workload_manager/jobdir/old directory

-- AlessioGianelle - 02 Dec 2008

Edit | Attach | PDF | History: r13 < r12 < r11 < r10 < r9 | Backlinks | Raw View | More topic actions...
Topic revision: r12 - 2008-12-23 - AlessioGianelle
 
  • Edit
  • Attach
This site is powered by the TWiki collaboration platformCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback