Latest WMS news and more ALICE TF Meeting 06/11/08

WMS: Current situation (I) The (WMS usage) random distribution implementation has been included at CERN and Torino since more than 1 week with good results Case: WMS is temporary overloaded Problem: Jobs will be kept and then submitted in one bunch Solution: A «drain flag» definition is foreseen for the WMS In this case if one WMS is overloaded, the submission will pass automatically to the 2nd WMS defined (UI feature) This is true if the list of WMS contains multiple nodes

WMS: Current situation (II) In order to explote all the potential of the drain flag feature we should be: Use RB1 OR RB2 OR RB3. If all these WMS fail… Use RB4 OR RB5 OR RB6 The defined code is now implemented at CERN and in Torino LDAP configuration wms1;wms2,wms3;wms4 1st group 2nd group Into the VOBOX, this means the following: $HOME/alien-logs/wms103.cern.ch;wms109.cern.ch.vo.conf Where this files looks like as: [ VirtualOrganisation = "alice"; WMProxyEndpoints = {"https://wms103.cern.ch:7443/glite_wms_wmproxy_server","https://wms109.cern.ch:7443/glite_wms_wmproxy_server"}; MyProxyServer = "myproxy.cern.ch"; ]

WMS news GRIF (France) will provide ALICE in few days with a WMS (latest version) Definition of the configuration already discussed this morning with the site NIKHEF (NL) has already one WMS in testing and will be provided also soon to ALICE GD team is encouraging us to have a more direct approach with the sites regarding the CREAM setup We must go for this negociation site per site

Bugs affecting Alice (I) Problem: If none of the listed WMS is able to accept job requirements, a random WMS in the Grid will be chosen and it might be typically not registered into myproxy server Solution:  EnableServiceDiscovery  =  false; In addition, remember the field suggested last week: Problem: If not specified, job request will be resent until 10 times if it fails before arriving to the WN Solution: ShallowRetryCount = 0; (shallow resubmission) This is what we already have: RetryCount = 0; (deep resubmission) Differences: The resubmission is deep when the job fails after it has started running on the WN, and shallow otherwise

Bugs affecting ALICE (II) Problem: When the target WMS node is in drain mode, job submission may hang as follows: glite-wms-job-submit -a -c ui/glite_wms_wms116.conf --noint simple.jdl Connecting to the service https://wms116.cern.ch:7443/glite_w... Warning - Unable to register the job to the service: https://wms116.cern.ch:7443/glite_w... Unavailable service (the server is temporarily drained) Method: jobRegister <?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/env..." xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/enc..." xmlns:xsi="http://www.w3.org/2001/XMLSchema-in..." xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:delegationns="http://www.gridsite.org/namespaces/..." xmlns:ns1="http://glite.org/wms/wmproxy"> <SOAP-ENV:Body> <delegationns:getProxyReq> <delegationID>Jze-MmXbCVwyttoaLL9lbQ</delegationID> </delegationns:getProxyReq> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Solution: The workaround is to submit jobs with stdin redirected from /dev/null:   glite-wms-job-submit ..... < /dev/null

In addition: SLC5 tests in place We have been asked to provide the deployment and the FIO teams with a feedback of the experiment experiences running in SLC5 Whole setup done this week in voalice03 After several cnfiguration issues solved directly with FIO, the system is perfectly running for ALICE More than 14 jobs running concurrently this morning Working in compatibility mode (all s/w SLC4 compiled) The current configuration is 32b The final must be 64b mode: Upgrade foreseen at the beginning of the next week