Difference: TestPlan (3 vs. 4)

Revision 42011-09-21 - AlessioGianelle

Line: 1 to 1

META TOPICPARENT	name="WebHome"

Line: 47 to 47

Features/Scenarios to be tested

Added:

>
>

WMS can be deployed into two modes:

Using an LB server installed in the same machine (BOTH mode)
Using an external LB server (PROXY mode)

Both scenarios should be tested.

Test job cycle (from submission to output retrieve)

Submit a job to the WMS service and when finished retrieve the output; a the end the final status of the jobs should be Cleared.

Added:

>
>

Submission can be tested using different type of proxy:

Proxy from different VO (TBD)
Proxy with different ROLE (TBD)
Delegated proxy retrieved from a MyproxyServer (TBD)
RFC 3820 compliant proxy (TBD)

Test job submission with the following type of jobs:

Normal Job

Test the complete cycle submitting to the two types of CE: lcg and Cream Implemented.

Changed:

<
<

More different jdls can added in the future.

>
>

More different jdls can added in the future. In particular these attributes should be tested:

DataRequirements (with differents DataCatalogType) (TBD)
OutputData (TBD)
InputSandboxBaseURI, OutputSandboxDestURI and OutputSandboxBaseDestURI (TBD)
AllowZippedISB and ZippedISB (TBD)
ExpiryTime (TBD)
ShortDeadlineJob (TBD)

Perusal job

Line: 98 to 114

Test various matching requests Implemented.

Changed:

<
<

With data

>
>

With data

Changed:

<
<

Test matchmaking using data requests (gang matchmaking) TBD

>
>

Test matchmaking using data requests TBD

Changed:

<
<

You need to register a file on an SE, then submit a jdl like this one (as InputData put the lfn(s) registered before):

>
>

You need to register a file on an SE, then try a list-match using a jdl like this one (as InputData put the lfn(s) registered before):

###########################################
#      JDL with Data Requirements         #

Line: 126 to 142

}; DataAccessProtocol = "gsiftp";

Changed:

<
<

Then try a list-match, the listed CEs should be the ones "close" to the used SE

>
>

The listed CEs should be the ones "close" to the used SE

Gang-Matching TBD

If we consider for example a job that requires a CE and a determined amount of free space on a close SE to run successfully, the matchmaking solution to this problem requires three participants in the match (i.e., job, CE and SE), which cannot be accommodated by conventional (bilateral) matchmaking. The gangmatching feature of the classads library provides a multilateral matchmaking formalism to address this deficiency.

Try some listmatch using different expressions of Requirements which use these built-in functions:

anyMatch()
whichMatch()
allMatch()

WMS Job Cancel Testing

Line: 144 to 169

Cancellation of a Done job should fails. Implemented.

Changed:

<
<

Prologue and Epilogue jobs

>
>

Prologue and Epilogue jobs

In the jdl you can specify two attributes prologue and epilogue which are scripts that are execute respectively before and after the user's job. Implemented.

Line: 153 to 178

Submit a long job with myproxyserver set using a short proxy to both CE (lcg and CREAM). Job should finishes Done (Success) Implemented.
Submit a long job without setting myproxyserver using a short proxy to both CE (lcg and CREAM). Job should finishes Aborted with reason "proxy expired" Implemented.

Added:

>
>

WMS feedback (TBD)

This mechanism avoid a job to remain stuck for long time in queue waiting to be assigned to a worker node for execution. There are three parameters in the jdl that can be used to manage this mechanism:

EnableWMSFeedback
ReplanGracePeriod
MaxRetryCount

The test should submit a lot of long jobs with short ReplanGracePeriod using a small number of resources, at the end of the test some jobs should be replanned (i.e. reassigned to different CEs). This can be evinced from the logging info of the jobs.

Performance tests

Changed:

<
<

Collection of 1000 nodes

>
>

Collection of multiple nodes

Changed:

<
<

Submit a collection of 1000 nodes. (TBD)

>
>

Submit a collection of n (a good compromise should be 1000) nodes. (TBD)

Stress test

Changed:

<
<

This could be an example of stress test (partially implemented)

2880 collections each of 20 jobs

>
>

Stress tests can parametrized some features: (partially implemented)

Type of submitted job (e.g. Collections, normal, dag, parametric)
Submission frequency (i.e. number of submissions for minute)
Number of submission (i.e. duration of test)
Number of parallel submission threads (i.e. each one with a different user proxy)
With or without automatic delegation
With or without resubmission enable
With or without proxy renewal enable
Jdl description
- with or without sandbox
- with or without cpu computation
- executable duration
- with or without data transfer
- etc...

This could be an example of stress test

2880 collections each of 20 jobs (2 days of test)

One collection every 60 seconds
Four users
Use LCG-CEs and CREAM-CEs (with different batch systems)

Line: 178 to 223

Note

Deleted:

<
<

Implemented. means that an automatic test exists. Otherwise test must be execute by hand.

\ No newline at end of file

Added:

>
>

Implemented. means that an automatic test exists. Otherwise test must be developed and or execute by hand.

View topic | History: r18 < r17 < r16 < r15 | More topic actions...