Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Line: 55 to 56 | ||||||||
At the end of the update the various init script should be checked with all parameters (start | stop | restart | status | version) (TBD) | ||||||||
Added: | ||||||||
> > | Service configuration tests
| |||||||
Functionality testsFeatures/Scenarios to be tested |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Line: 7 to 7 | ||||||||
NOTICE: missing tests:
| ||||||||
Added: | ||||||||
> > |
| |||||||
|
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Line: 128 to 128 | ||||||||
| ||||||||
Added: | ||||||||
> > |
TEST: https://ggus.eu/ws/ticket_info.php?ticket=79096![]() | |||||||
Shallow and deep re-submissionThere two type of resubmission; the first is defined deep occurs when the user's job has stardted running on the WN and then the job itself or the WMS JobWrapper has failed. The second one is called shallow and occurs when the WMS JobWrapper has failed before starting the actual user's job. Implemented. | ||||||||
Line: 189 to 192 | ||||||||
| ||||||||
Added: | ||||||||
> > | It is important that the cancel is issued at different times from the submission. Id state is submitted, then WMP code is tested, waiting->scheduled wm (+jc), running, wm+lm | |||||||
Prologue and Epilogue jobsIn 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: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
WMS Test Plan | ||||||||
Added: | ||||||||
> > | NOTICE: missing tests:
| |||||||
Unit testsN/A |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Line: 450 to 450 | ||||||||
Complete list of Rfc tests![]() | ||||||||
Added: | ||||||||
> > | Nagios probe testFor tests about Nagios probes see here![]() | |||||||
NoteImplemented. means that an automatic test exists. Otherwise test must be developed and or execute by hand. \ No newline at end of file |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Line: 64 to 64 | ||||||||
| ||||||||
Added: | ||||||||
> > | Different types of CE must be used:
| |||||||
Test job submission with the following type of jobs:
Normal Job |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Line: 17 to 17 | ||||||||
| ||||||||
Changed: | ||||||||
< < | Operations/Installation test | |||||||
> > | Installation test | |||||||
First of all, install the yum-protectbase rpm: yum install yum-protectbase.noarch |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Line: 193 to 193 | ||||||||
| ||||||||
Added: | ||||||||
> > | A list-match with a jdl where EnableWMSFeedback is set to true must return only CREAM CE | |||||||
Limiter mechanismThe 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) |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Line: 17 to 17 | ||||||||
| ||||||||
Changed: | ||||||||
< < | Installation test | |||||||
> > | Operations/Installation test | |||||||
First of all, install the yum-protectbase rpm: yum install yum-protectbase.noarch |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
|
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Line: 63 to 63 | ||||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > | ||||||||
Test job submission with the following type of jobs:
Normal Job |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Line: 156 to 156 | ||||||||
Gang-MatchingIf 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: TBD | |||||||
> > | Try some listmatch using different expressions of Requirements which use the anyMatch() function: TBD | |||||||
Deleted: | ||||||||
< < |
| |||||||
WMS Job Cancel Testing | ||||||||
Line: 226 to 224 | ||||||||
Configuration fileThe 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) | ||||||||
Added: | ||||||||
> > | It should be verified that in the configuration file /etc/glite-wms/glite_wms.conf there are these hard-coded values:
For the common section:
DGUser = "\${GLITE_WMS_USER}" HostProxyFile = "\${WMS_LOCATION_VAR}/glite/wms.proxy" LBProxy = trueFor the JobController section: CondorSubmit = "${CONDORG_INSTALL_PATH}/bin/condor_submit" CondorRemove = "${CONDORG_INSTALL_PATH}/bin/condor_rm" CondorQuery = "${CONDORG_INSTALL_PATH}/bin/condor_q" CondorRelease = "${CONDORG_INSTALL_PATH}/bin/condor_release" CondorDagman = "${CONDORG_INSTALL_PATH}/bin/condor_dagman" DagmanMaxPre = 10 SubmitFileDir = "${WMS_LOCATION_VAR}/jobcontrol/submit" OutputFileDir = "${WMS_LOCATION_VAR}/jobcontrol/condorio" InputType = "jobdir" Input = "${WMS_LOCATION_VAR}/jobcontrol/jobdir/" LockFile = "${WMS_LOCATION_VAR}/jobcontrol/lock" LogFile = "\${WMS_LOCATION_LOG}/jobcontoller_events.log" LogLevel = 5 MaximumTimeAllowedForCondorMatch = 1800 ContainerRefreshThreshold = 1000For the NetworkServer section: II_Port = 2170 Gris_Port = 2170 II_Timeout = 100 Gris_Timeout = 20 II_DN = "mds-vo-name=local, o=grid" Gris_DN = "mds-vo-name=local, o=grid" BacklogSize = 64 ListeningPort = 7772 MasterThreads = 8 DispatcherThreads = 10 SandboxStagingPath = "${WMS_LOCATION_VAR}/SandboxDir" LogFile = "${WMS_LOCATION_LOG}/networkserver_events.log" LogLevel = 5 EnableQuotaManagement = false MaxInputSandboxSize = 10000000 EnableDynamicQuotaAdjustment = false QuotaAdjustmentAmount = 10000 QuotaInsensibleDiskPortion = 2.0 DLI_SI_CatalogTimeout = 60 ConnectionTimeout = 300For the LogMonitor section: JobsPerCondorLog = 1000 LockFile = "${WMS_LOCATION_VAR}/logmonitor/lock" LogFile = "${WMS_LOCATION_LOG}/logmonitor_events.log" LogLevel = 5 ExternalLogFile = "\${WMS_LOCATION_LOG}/logmonitor_external.log" MainLoopDuration = 5 CondorLogDir = "${WMS_LOCATION_VAR}/logmonitor/CondorG.log" CondorLogRecycleDir = "${WMS_LOCATION_VAR}/logmonitor/CondorG.log/recycle" MonitorInternalDir = "${WMS_LOCATION_VAR}/logmonitor/internal" IdRepositoryName = "irepository.dat" AbortedJobsTimeout = 600 GlobusDownTimeout = 7200 RemoveJobFiles = true ForceCancellationRetries = 2or the Workloadmanager section: PipeDepth = 200 WorkerThreads = 5 DispatcherType = "jobdir" Input = "${WMS_LOCATION_VAR}/workload_manager/jobdir" LogLevel = 5 LogFile = "${WMS_LOCATION_LOG}/workload_manager_events.log" MaxRetryCount = 10 CeMonitorServices = {} CeMonitorAsynchPort = 0 IsmBlackList = {} IsmUpdateRate = 600 IsmIiPurchasingRate = 480 JobWrapperTemplateDir = "${WMS_JOBWRAPPER_TEMPLATE}" IsmThreads = false IsmDump = "${WMS_LOCATION_VAR}/workload_manager/ismdump.fl" SiServiceName = "org.glite.SEIndex" DliServiceName = "data-location-interface" MaxRetryCount = 10 DisablePurchasingFromGris = true EnableBulkMM = true CeForwardParameters = {"GlueHostMainMemoryVirtualSize","GlueHostMainMemoryRAMSize","GlueCEPolicyMaxCPUTime"} MaxOutputSandboxSize = -1 EnableRecovery = true QueueSize = 1000 ReplanGracePeriod = 3600 MaxReplansCount = 5 WmsRequirements = ((ShortDeadlineJob =?= TRUE) ? RegExp(".*sdj$", other.GlueCEUniqueID) : !RegExp(".*sdj$", other.GlueCEUniqueID)) && (other.GlueCEPolicyMaxTotalJobs == 0 || other.GlueCEStateTotalJobs < other.GlueCEPolicyMaxTotalJobs) && (EnableWmsFeedback =?= TRUE ? RegExp("cream", other.GlueCEImplementationName, "i") : true)For the WorkloadManagerProxy: SandboxStagingPath = "${WMS_LOCATION_VAR}/SandboxDir" LogFile = "${WMS_LOCATION_LOG}/wmproxy.log" LogLevel = 5 MaxInputSandboxSize = 100000000 ListMatchRootPath = "/tmp" GridFTPPort = 2811 LBLocalLogger = "localhost:9002" MinPerusalTimeInterval = 1000 AsyncJobStart = true EnableServiceDiscovery = false LBServiceDiscoveryType = "org.glite.lb.server" ServiceDiscoveryInfoValidity = 3600 WeightsCacheValidity = 86400 MaxServedRequests = 50 OperationLoadScripts = [ jobRegister = "${WMS_LOCATION_SBIN}/glite_wms_wmproxy_load_monitor --oper jobRegister --load1 22 --load5 20 --load15 18 --memusage 99 --diskusage 95 --fdnum 1000 --jdnum 1500 --ftpconn 300" jobSubmit = "${WMS_LOCATION_SBIN}/glite_wms_wmproxy_load_monitor --oper jobSubmit --load1 22 --load5 20 --load15 18 --memusage 99 --diskusage 95 --fdnum 1000 --jdnum 1500 --ftpconn 300" RuntimeMalloc = "/usr/lib64/libtcmalloc_minimal.so" ]For the ICE section: start_listener = false start_lease_updater = false logfile = "${WMS_LOCATION_LOG}/ice.log" log_on_file = true creamdelegation_url_prefix = "https://" listener_enable_authz = true poller_status_threshold_time = 30*60 ice_topic = "CREAM_JOBS" subscription_update_threshold_time = 3600 lease_delta_time = 0 notification_frequency = 3*60 start_proxy_renewer = true max_logfile_size = 100*1024*1024 ice_host_cert = "${GLITE_HOST_CERT}" Input = "${WMS_LOCATION_VAR}/ice/jobdir" job_cancellation_threshold_time = 300 poller_delay = 2*60 persist_dir = "${WMS_LOCATION_VAR}/ice/persist_dir" lease_update_frequency = 20*60 log_on_console = false cream_url_postfix = "/ce-cream/services/CREAM2" subscription_duration = 86400 bulk_query_size = 100 purge_jobs = false InputType = "jobdir" listeneristener_enable_authn = true ice_host_key = "${GLITE_HOST_KEY}" start_poller = true creamdelegation_url_postfix = "/ce-cream/services/gridsite-delegation" cream_url_prefix = "https://" max_ice_threads = 10 cemon_url_prefix = "https://" start_subscription_updater = true proxy_renewal_frequency = 600 ice_log_level = 700 soap_timeout = 60 max_logfile_rotations = 10 cemon_url_postfix = "/ce-monitor/services/CEMonitor" max_ice_mem = 2096000 ice_empty_threshold = 600It should then be verified that:
| |||||||
Performance testsCollection of multiple nodes |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Line: 94 to 94 | ||||||||
Collection JobMultiple jobs with a common description. There are two ways to submit collection: | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Parallel Job |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
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 testStarting 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 testsFeatures/Scenarios to be tested | ||||||||
Line: 97 to 100 | ||||||||
Parallel JobJobs that can be running in one or more cpus in parallel. Implemented. | ||||||||
Added: | ||||||||
> > |
| |||||||
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 | |||||||
| ||||||||
Line: 178 to 187 | ||||||||
| ||||||||
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:
| ||||||||
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 mechanismThe 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 PurgingThere are differents purging mechanisms on the WMS:
Configuration fileThe 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 |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Line: 47 to 47 | ||||||||
Features/Scenarios to be tested | ||||||||
Added: | ||||||||
> > | WMS can be deployed into two modes:
| |||||||
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:
| |||||||
Test job submission with the following type of jobs:
Normal Job
| ||||||||
Changed: | ||||||||
< < | More different jdls can added in the future. | |||||||
> > | More different jdls can added in the future. In particular these attributes should be tested:
| |||||||
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: | ||||||||
< < |
| |||||||
> > |
| |||||||
########################################### # JDL with Data Requirements # | ||||||||
Line: 126 to 142 | ||||||||
}; DataAccessProtocol = "gsiftp"; | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > | The listed CEs should be the ones "close" to the used SE
Gang-Matching TBDIf 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:
| |||||||
WMS Job Cancel Testing | ||||||||
Line: 144 to 169 | ||||||||
| ||||||||
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 | ||||||||
| ||||||||
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:
| |||||||
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)
| |||||||
> > | Stress tests can parametrized some features: (partially implemented)
| |||||||
| ||||||||
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. |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Line: 157 to 157 | ||||||||
Collection of 1000 nodes | ||||||||
Changed: | ||||||||
< < | Submit a collection of 1000 nodes. | |||||||
> > | Submit a collection of 1000 nodes. (TBD) | |||||||
Stress test | ||||||||
Changed: | ||||||||
< < | This could be an example of stress test | |||||||
> > | This could be an example of stress test (partially implemented) | |||||||
|
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Line: 11 to 10 | ||||||||
Deployment tests | ||||||||
Changed: | ||||||||
< < | RepositoryThe EMI-1 RC4 repository can be found under:http://emisoft.web.cern.ch/emisoft/dist/EMI/1/RC4/sl5/x86_64 | |||||||
> > | Generic repository | |||||||
Deleted: | ||||||||
< < | Other repositories: | |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Installation test | ||||||||
Changed: | ||||||||
< < | First of all, install the yum-protectbase rpm:
yum install yum-protectbase.noarch | |||||||
> > | First of all, install the yum-protectbase rpm: yum install yum-protectbase.noarch | |||||||
Then proceed with the installation of the CA certificates by issuing: | ||||||||
Deleted: | ||||||||
< < | yum install ca-policy-egi-core | |||||||
Changed: | ||||||||
< < | Install the WMS metapackage:
yum install emi-wms | |||||||
> > | yum install ca-policy-egi-core | |||||||
Changed: | ||||||||
< < | Configure the WMS:
/opt/glite/yaim/bin/yaim -c -s site-info.def -n WMS | |||||||
> > | Install the WMS metapackage: | |||||||
Changed: | ||||||||
< < | Update test | |||||||
> > | yum install emi-wms | |||||||
Changed: | ||||||||
< < | N/A | |||||||
> > | After the definition of the site-info.def file configure the WMS: | |||||||
Changed: | ||||||||
< < | Functionality tests | |||||||
> > | /opt/glite/yaim/bin/yaim -c -s site-info.def -n WMS | |||||||
Changed: | ||||||||
< < | Features/Scenarios to be tested | |||||||
> > | Update test | |||||||
Changed: | ||||||||
< < | YAIM-WMS Configuration Testing
| |||||||
> > | Starting from a production WMS add the patch repository then issue: | |||||||
Changed: | ||||||||
< < | WMS Job Submission/GetOutput TestingSubmit a job to the WMS service and when finished retrieve the output. Test job submission with the following type of jobs: | |||||||
> > | yum update | |||||||
Added: | ||||||||
> > | If necessary reconfigure the WMS: | |||||||
Changed: | ||||||||
< < | Bunch #1: submission of normal jobs. | |||||||
> > | /opt/glite/yaim/bin/yaim -c -s site-info.def -n WMS | |||||||
Changed: | ||||||||
< < | Test 1.1: Test this JDL: | |||||||
> > | Functionality tests | |||||||
Changed: | ||||||||
< < | [ Executable = "/bin/echo"; Arguments = "Hello"; StdOutput = "out.log"; StdError = "err.log"; InputSandbox = {"Test.sh"}; OutputSandbox = {"out.log", "err.log"}; requirements = RegExp("cream.*", other.GlueCEUniqueID);; AllowZippedISB = false; rank=0; myproxyserver="myproxy.cnaf.infn.it"; RetryCount = 0; ShallowRetryCount = 1; ] | |||||||
> > | Features/Scenarios to be tested | |||||||
Changed: | ||||||||
< < | Test 1.10 submit a job with an empty file in ISB | |||||||
> > | Test job cycle (from submission to output retrieve) | |||||||
Changed: | ||||||||
< < | Normal Job
| |||||||
> > | 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. | |||||||
Changed: | ||||||||
< < |
| |||||||
> > | Test job submission with the following type of jobs: | |||||||
Added: | ||||||||
> > | Normal Job
| |||||||
More different jdls can added in the future.
Perusal job | ||||||||
Changed: | ||||||||
< < | Job perusal is the ability to view output from a job while it is running. Implemented![]() | |||||||
> > | Job perusal is the ability to view output from a job while it is running. Implemented. | |||||||
DAG job | ||||||||
Changed: | ||||||||
< < | Directed Acyclic Graphs (a set of jobs where the input/output/execution of one of more jobs may depend on one or more other jobs).
[ type = "dag"; DefaultNodeShallowRetryCount = 3; nodes = [ nodeA = [ node_type = "edg-jdl"; file ="jdl/arg.jdl" ; ]; nodeB = [ node_type = "edg-jdl"; file ="jdl/arg.jdl" ; ]; nodeC = [ node_type = "edg-jdl"; file ="jdl/arg.jdl" ; ]; dependencies = { { nodeA, nodeB }, { nodeA, nodeC } } ]; ]
| |||||||
> > | Directed Acyclic Graphs (a set of jobs where the input/output/execution of one of more jobs may depend on one or more other jobs). Implemented. | |||||||
Added: | ||||||||
> > |
| |||||||
More different jdls can added in the future.
Parametric Job | ||||||||
Changed: | ||||||||
< < | Multiple jobs with one parametrized description. Implemented![]() | |||||||
> > | Multiple jobs with one parametrized description. Implemented. | |||||||
Collection Job | ||||||||
Changed: | ||||||||
< < | Multiple jobs with a common description. There are two ways to submit collection: you can create a single jdl with all the jdls of nodes or you can submit all the jdls stored in a directory (bulk submission)
[ nodes = { [ file="jdl/arg.jdl"; ], [ executable="/bin/env"; ShallowRetryCount = 0; RetryCount = 0; Stdoutput = "file.out" ; StdError = "file.err" ; OutputSandbox ={ "file.out" ,"file.err"} ; FuzzyRank = true; ], [ NodeName="nodeA"; executable="/bin/ls" ; Stdoutput = "file.out" ; OutputSandbox ={ "file.out"} ; ] }; Type = "Collection" ; requirements = other.GlueCEStateStatus == "Production" ; rank = -other.GlueCEStateEstimatedResponseTime ; ]
| |||||||
> > | Multiple jobs with a common description. There are two ways to submit collection:
| |||||||
Parallel Job | ||||||||
Changed: | ||||||||
< < | Jobs that can be running in one or more cpus in parallel.
[ Executable = "cpi"; CpuNumber = 2; Stdoutput = "cpi.out" ; StdError = "cpi.err" ; OutputSandbox = { "cpi.out" ,"cpi.err"} ; InputSandbox = { "exe/cpi" }; FuzzyRank = true; usertags = [ exe = "cpi" ]; ]
| |||||||
> > | Jobs that can be running in one or more cpus in parallel. Implemented. | |||||||
Delegation | ||||||||
Deleted: | ||||||||
< < | Explicit delegation, automatic delegation | |||||||
Changed: | ||||||||
< < | Brokerinfo | |||||||
> > |
| |||||||
Changed: | ||||||||
< < | WMS Job shallow and deep re-submission | |||||||
> > |
| |||||||
Changed: | ||||||||
< < | There two type of resubmission; the first is defined deep occurs when the user's job has stardted running on the WN and then the job itself or the WMS JobWrapper has failed. The second one is called shallow and occurs when the WMS JobWrapper has failed before starting the actual user's job. Implemented![]() | |||||||
> > |
| |||||||
Changed: | ||||||||
< < | ReplanningMaxReplansCount in glite_wms.conf | |||||||
> > | Shallow and deep re-submission | |||||||
Changed: | ||||||||
< < | WMS Job List-match Testing | |||||||
> > | There two type of resubmission; the first is defined deep occurs when the user's job has stardted running on the WN and then the job itself or the WMS JobWrapper has failed. The second one is called shallow and occurs when the WMS JobWrapper has failed before starting the actual user's job. Implemented. | |||||||
Changed: | ||||||||
< < | Without data | |||||||
> > | Job List-match Testing | |||||||
Changed: | ||||||||
< < | Test job-list-command and its option Implemented![]() | |||||||
> > | Test various matching requests Implemented. | |||||||
Changed: | ||||||||
< < | With data | |||||||
> > | With dataTest matchmaking using data requests (gang matchmaking) TBD | |||||||
| ||||||||
Line: 239 to 126 | ||||||||
}; DataAccessProtocol = "gsiftp"; | ||||||||
Deleted: | ||||||||
< < | ||||||||
WMS Job Cancel Testing | ||||||||
Changed: | ||||||||
< < | Test the cancellation of these type of jobs (final status should be cleared):
Normal jobSubmit and cancel a normal job Implementd![]() DAG jobSubmit a dag job and then cancel it (the parent)Collection | |||||||
> > | Test the cancellation of these type of jobs (final status should be Cancelled): | |||||||
Changed: | ||||||||
< < | Submit a collection job and then cancel it (the parent) | |||||||
> > |
| |||||||
Changed: | ||||||||
< < | Node of a collection | |||||||
> > |
| |||||||
Changed: | ||||||||
< < | Submit a collection job and then some of its nodes | |||||||
> > |
| |||||||
Changed: | ||||||||
< < | Others | |||||||
> > |
| |||||||
Changed: | ||||||||
< < | Delegation Testing | |||||||
> > |
| |||||||
Changed: | ||||||||
< < | Test the delegation command and its options Implementd![]() | |||||||
> > |
| |||||||
Changed: | ||||||||
< < | Job-info Testing | |||||||
> > | Prologue and Epilogue jobs | |||||||
Changed: | ||||||||
< < | Test the job-info command and its options Implementd![]() | |||||||
> > | 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. | |||||||
Changed: | ||||||||
< < | Logging-info TestingTest the logging-info command and its options Implemented![]() Job Status TestingTest the job-status commend and its options Implemented![]() Prologue and Epilogue jobsIn 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![]() | |||||||
> > | Proxy renewal | |||||||
Added: | ||||||||
> > |
| |||||||
Performance tests | ||||||||
Line: 300 to 168 | ||||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Regression testsComplete list of Rfc tests![]() | ||||||||
Added: | ||||||||
> > |
NoteImplemented. means that an automatic test exists. Otherwise test must be execute by hand. |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Added: | ||||||||
> > |
WMS Test PlanUnit testsN/ADeployment testsRepositoryThe EMI-1 RC4 repository can be found under:Other repositories:http://emisoft.web.cern.ch/emisoft/dist/EMI/1/RC4/sl5/x86_64
Installation testFirst of all, install the yum-protectbase rpm:yum install yum-protectbase.noarchThen proceed with the installation of the CA certificates by issuing: yum install ca-policy-egi-coreInstall the WMS metapackage: yum install emi-wmsConfigure the WMS: /opt/glite/yaim/bin/yaim -c -s site-info.def -n WMS Update testN/AFunctionality testsFeatures/Scenarios to be testedYAIM-WMS Configuration Testing
WMS Job Submission/GetOutput TestingSubmit a job to the WMS service and when finished retrieve the output. Test job submission with the following type of jobs: Bunch #1: submission of normal jobs. Test 1.1: Test this JDL: [ Executable = "/bin/echo"; Arguments = "Hello"; StdOutput = "out.log"; StdError = "err.log"; InputSandbox = {"Test.sh"}; OutputSandbox = {"out.log", "err.log"}; requirements = RegExp("cream.*", other.GlueCEUniqueID);; AllowZippedISB = false; rank=0; myproxyserver="myproxy.cnaf.infn.it"; RetryCount = 0; ShallowRetryCount = 1; ] Test 1.10 submit a job with an empty file in ISBNormal Job
Perusal jobJob perusal is the ability to view output from a job while it is running. Implemented![]() DAG jobDirected Acyclic Graphs (a set of jobs where the input/output/execution of one of more jobs may depend on one or more other jobs).
[ type = "dag"; DefaultNodeShallowRetryCount = 3; nodes = [ nodeA = [ node_type = "edg-jdl"; file ="jdl/arg.jdl" ; ]; nodeB = [ node_type = "edg-jdl"; file ="jdl/arg.jdl" ; ]; nodeC = [ node_type = "edg-jdl"; file ="jdl/arg.jdl" ; ]; dependencies = { { nodeA, nodeB }, { nodeA, nodeC } } ]; ]
Parametric JobMultiple jobs with one parametrized description. Implemented![]() Collection JobMultiple jobs with a common description. There are two ways to submit collection: you can create a single jdl with all the jdls of nodes or you can submit all the jdls stored in a directory (bulk submission)
[ nodes = { [ file="jdl/arg.jdl"; ], [ executable="/bin/env"; ShallowRetryCount = 0; RetryCount = 0; Stdoutput = "file.out" ; StdError = "file.err" ; OutputSandbox ={ "file.out" ,"file.err"} ; FuzzyRank = true; ], [ NodeName="nodeA"; executable="/bin/ls" ; Stdoutput = "file.out" ; OutputSandbox ={ "file.out"} ; ] }; Type = "Collection" ; requirements = other.GlueCEStateStatus == "Production" ; rank = -other.GlueCEStateEstimatedResponseTime ; ]
Parallel JobJobs that can be running in one or more cpus in parallel.
[ Executable = "cpi"; CpuNumber = 2; Stdoutput = "cpi.out" ; StdError = "cpi.err" ; OutputSandbox = { "cpi.out" ,"cpi.err"} ; InputSandbox = { "exe/cpi" }; FuzzyRank = true; usertags = [ exe = "cpi" ]; ]
DelegationExplicit delegation, automatic delegationBrokerinfoWMS Job shallow and deep re-submissionThere two type of resubmission; the first is defined deep occurs when the user's job has stardted running on the WN and then the job itself or the WMS JobWrapper has failed. The second one is called shallow and occurs when the WMS JobWrapper has failed before starting the actual user's job. Implemented![]() ReplanningMaxReplansCount in glite_wms.confWMS Job List-match TestingWithout dataTest job-list-command and its option Implemented![]() With data
########################################### # JDL with Data Requirements # ########################################### Executable = "calc-pi.sh"; Arguments = "1000"; StdOutput = "std.out"; StdError = "std.err"; Prologue = "prologue.sh"; InputSandbox = {"calc-pi.sh", "fileA", "fileB","prologue.sh"}; OutputSandbox = {"std.out", "std.err","out-PI.txt","out-e.txt"}; Requirements = true; DataRequirements = { [ DataCatalogType = "DLI"; DataCatalog = "http://lfcserver.cnaf.infn.it:8085"; InputData = {"lfn:/grid/infngrid/cesini/PI_1M.txt","lfn:/grid/infngrid/cesini/e-2M.txt"}; ] }; DataAccessProtocol = "gsiftp";
WMS Job Cancel TestingTest the cancellation of these type of jobs (final status should be cleared):Normal jobSubmit and cancel a normal job Implementd![]() DAG jobSubmit a dag job and then cancel it (the parent)CollectionSubmit a collection job and then cancel it (the parent)Node of a collectionSubmit a collection job and then some of its nodesOthersDelegation TestingTest the delegation command and its options Implementd![]() Job-info TestingTest the job-info command and its options Implementd![]() Logging-info TestingTest the logging-info command and its options Implemented![]() Job Status TestingTest the job-status commend and its options Implemented![]() Prologue and Epilogue jobsIn 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![]() Performance testsCollection of 1000 nodesSubmit a collection of 1000 nodes.Stress testThis could be an example of stress test
Regression testsComplete list of Rfc tests![]() |