Difference: TestPlan (4 vs. 5)

Revision 52011-10-03 - AlessioGianelle

Line: 1 to 1

META TOPICPARENT	name="WebHome"

Line: 33 to 33

/opt/glite/yaim/bin/yaim -c -s site-info.def -n WMS

Added:

>
> At the end of the installation the various init script should be checked with all parameters (start | stop | restart | status | version) (TBD)

Update test

Starting from a production WMS add the patch repository then issue:

Line: 43 to 44

/opt/glite/yaim/bin/yaim -c -s site-info.def -n WMS

Added:

>
> At the end of the update the various init script should be checked with all parameters (start | stop | restart | status | version) (TBD)

Functionality tests

Features/Scenarios to be tested

Line: 97 to 100

Parallel Job

Jobs that can be running in one or more cpus in parallel. Implemented.

Added:

>
>

One of the charactheristics of this type of jobs is the possibility to pass these parameters directly to the CE:
- WHOLENODES
- SMPGRANULARITY
- HOSTNUMBER
- CPUNUMBER

Jdls combining these parameters should be used. TBD

Delegation

Line: 144 to 153

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

Changed:

<
<

Gang-Matching TBD

>
>

Gang-Matching

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.

Changed:

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

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

anyMatch()
whichMatch()
allMatch()

Line: 178 to 187

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.

Changed:

<
<

WMS feedback (TBD)

>
>

WMS feedback

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

Changed:

<
< 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.

>
>

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. (TBD)

Limiter mechanism

The WMS has implemented a limiter mechanism to protect himself from overload. This mechanism is based on different parameters anc can be configured inside wms configuration file. All these parameters should be checked and tested. (TBD)

 
Usage:/usr/sbin/glite_wms_wmproxy_load_monitor [OPTIONS]...
      --load1       threshold for load average (1min)
      --load5       threshold for load average (5min)
      --load15    threshold for load average (15min)
      --memusage    threshold for memory usage (%)
      --swapusage    threshold for swap usage (%)
      --fdnum       threshold for used file descriptor
      --diskusage    threshold for disk usage (%)
      --flsize    threshold for input filelist size (KB)
      --flnum    threshold for number of unprocessed jobs (for filelist)
      --jdsize    threshold for input jobdir size (KB)
      --jdnum    threshold for number of unprocessed jobs (for jobdir)
       --ftpconn    threshold for number of FTP connections
       --oper       operation to monitor (can be listed with --list)
      --list       list operation supported
      --show       show all the current values

Purging

There are differents purging mechanisms on the WMS:

SandboxDir purging done by a cron script using command: /usr/sbin/glite-wms-purgeStorage.sh
Internal purging which means removal of files used by the various daemons as temporary information store. This purging should be done by the daemons themself.
Proxy purging done by a cron script using the command: /usr/bin/glite-wms-wmproxy-purge-proxycache

All these mechanism should be tested, i.e. check if all the unused files are removed at the end of the job. (TBD)

Configuration file

The file /etc/glite-wms/glite_wms.conf is used to configure all the daemons running on a WMS. A lot of parameters should be set with this file. Almost all these parameters should be checked. (TBD)

Performance tests

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