WMS Test Plan

Service Description

Features/Scenarios to be tested

'JOB SUBMISSION' (implemented)

Registers the job into the wmproxy, delivers it to the WM that submits it to the grid.

Normal workflow - correct input
'Job submission' is to be tested with the following different types of jobs as input:
  • Normal
  • DAG
  • Perusal
  • MPICH
  • Collections

Pass/Fail Criteria
  • Pass -> when jobid is returned together with a message of the type:
     The job has been successfully submitted to the WMProxy
    Your job identifier is:
    https://egee-rb-01.mi.infn.it:9000/0YaNnA7vFfUgtZmflkgeHg
  • Fail -> No jobid is returned, but an error message instead

Error workflow - erroneous input
  • provide a jdl with a missing mandatory attribute

Pass/Fail Criteria
  • Pass -> the following error message is returned:
    Error -
    Executable: Jdl mandatory attribute is missing
  • Fail -> in all other cases

'JOB LISTMATCH' (implemented)

Delivers the job to the WM that selects the best matching resources for the job on the GRID.

Normal workflow - correct input
Job listmatch is to be tested with 'Normal' type of jobs

Pass/Fail Criteria
  • Pass -> when resources are found and a message as the following is returned:
    [atlfarm007] /home/emolinar > glite-wms-job-list-match --config glite_wms_egee-rb-01.conf -a myjob.jdl                                                                                                                            
    Connecting to the service https://egee-rb-01.mi.infn.it:7443/glite_wms_wmproxy_server
     
    ==========================================================================
     
                         COMPUTING ELEMENT IDs LIST
     The following CE(s) matching your job requirements have been found:
     
            *CEId*
     - argoce01.na.infn.it:2119/jobmanager-lcgpbs-cert
     - atlas-ce-01.roma1.infn.it:2119/jobmanager-lcglsf-atlasgcert
    ......
    
  • Fail -> in all other cases

Error workflow - erroneous input
  • provide a .jdl with a 'Requirements' attribute that will not be satidfied for sure, like for ex.
    Requirements = false ;

Pass/Fail Criteria
When no resources are found and a message such as the following is returned:
 
==================== glite-wms-job-list-match failure ====================
No Computing Element matching your job requirements has been found!
==========================================================================

'JOB OUTPUT' (implemented)

  • Submits a job
  • waits for it to be finished
  • retrieves the output and purges relative sandboxes.

Normal workflow - correct input
This feature is to be tested both for 'normal' and 'collection' type of jobs.

Pass/Fail Criteria
  • Pass -> When the output has been successfully retrieved and a message as the following is returned to the user:
    Output sandbox files for the job:
    https://egee-rb-01.mi.infn.it:9000/sXAnv_rUSBEC-WBoYv-88w
    have been successfully retrieved and stored in the directory:
    /tmp/jobOutput/emolinar_sXAnv_rUSBEC-WBoYv-88w
  • Fail -> when it returns an error message such as the following:
    • Job purging not allowed
      [atlfarm007] /home/emolinar > glite-wms-job-output https://egee-rb-01.mi.infn.it:9000/V-RzdU3mW22S95CleKF9WA
      Connecting to the service https://egee-rb-01.mi.infn.it:7443/glite_wms_wmproxy_server
      Warning - JobPurging not allowed
       (The Operation is not allowed: Unable to complete job purge)
      
Error workflow - erroneous input
  • trying to retrieve the output of a job for which it has already been retrieved
Pass/Fail Criteria
  • Pass -> Output files have already been retrieved and a message as the following is returned
    Error - Output not Allowed
    Output files already retrieved
Error workflow - erroneous input
  • trying to retrieve the output of a job that is not in the right status 'Done'
Pass/Fail Criteria
  • Pass -> a message as the following is returned
 
Error - Output not yet Ready
Current Job Status is: Scheduled

'JOB CANCEL' (implemented)

  • Submits a job
  • retrieves the jobid of the submitted job
  • forwards the cancel request to the WM and logs it into the LB.

Normal workflow - correct input
The feature is to be tested for 'Normal' type of jobs.

Pass/Fail Criteria
  • Pass -> the cancel request is successfully submitted and a message as the following is returned
    The cancellation request has been successfully submitted for the following job(s):
    
    - https://egee-rb-01.mi.infn.it:9000/OhtyUWZ0B-ABxEnGKnHmew
    

Error workflow - erroneous input
  • trying to cancel a job that was already cancelled
Pass/Fail Criteria
  • Pass -> The jobs has already been cancelled, a message as the following is returned
    Error - Operation Failed
    The Operation is not allowed: Cancel has already been requested
    
    Method: jobCancel

'JOB STATUS' (implemented)

  • Submits a job
  • retrieves the jobid of the submitted job
  • waits a few seconds and check the job status.

Pass/Fail Criteria
  • Pass -> The job status is successfully retrieved and a message as the following is returned:
    Status info for the Job : https://egee-rb-01.mi.infn.it:9000/OsyiuCMVZQqtr80254aGrg
    Current Status:     Ready
    Destination:        ce107.cern.ch:2119/jobmanager-lcglsf-grid_2nh_dteam
    Submitted:          Sun Mar  1 10:20:44 2009 CET
    

Error workflow - erroneous input
  • trying to get the status of a job that was submitted by another user
  • Pass -> status is not returned and a message such as the following is returned instead
**** Error: API_NATIVE_ERROR ****
Error while calling the "Status:getStatus" native api
Unable to retrieve the status for: https://egee-rb-01.mi.infn.it:9000/EJ8u22zlRLl5uBj7GJA0CQ
edg_wll_JobStatus: Operation not permitted: matching jobs found but authorization failed

Tests required that are not yet implemented

  • In general all the tests described above need to be enhanced, so that also the final status of the job is checked and it is what it was expected to be, In particular some of the following possible scenarios should be tested:
    • submission of a job type 'Collection' checking for coherence among the final status of all the nodes and of the parent node
    • submission of a job type 'normal' with different type of input checking for the final status and the job output
    • submission of a job type 'DAG' checking for the final status
  • Regression tests on already known bugs can be created using the info stored here http://glite.cvs.cern.ch/cgi-bin/glite.cgi/org.glite.testsuites.ctb/WMS/regression/

-- ElisabettMolinari - 27 Jan 2009

Edit | Attach | Watch | Print version | History: r14 < r13 < r12 < r11 < r10 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r14 - 2009-04-16 - ElisabettMolinari
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    EGEE All webs login

This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright & by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Ask a support question or Send feedback