Grid : CondorCE Test Job Submission

Querying a CondorCE

Test a CondorCE with condor_ce_ping to query some basic properties and functionality

You will need a valid Grid proxy, where the DN is accepted and mapped by the CondorCE to a user.

export X509_USER_CERT=/tmp/x509up_uSOMEUIDHERE
export X509_USER_CERT=/tmp/x509up_uSOMEUIDHERE

and ping the remote CondorCE pool with something like `condor_ce_ping -verbose -name condorce.fqdn.null -pool condorce.fqdn.null:9619 WRITE` which should return information like the mapped user

condor_ce_ping

> condor_ce_ping -verbose -name condorce.fqdn.null -pool condorce.fqdn.null:9619  WRITE
Remote Version:              $CondorVersion: 8.9.11 Dec 28 2020 BuildID: 526068 PackageID: 8.9.11-1 $
Local  Version:              $CondorVersion: 8.8.12 Nov 24 2020 BuildID: 524104 PackageID: 8.8.12-1 $
Session ID:                  condorce.name:315031:1613489177:17315
Instruction:                 WRITE
Command:                     60021
Encryption:                  none
Integrity:                   MD5
Authenticated using:         GSI
All authentication methods:  FS,GSI
Remote Mapping:              MAPPEDUSER@users.htcondor.org
Authorized:                  TRUE

Test Traces

condor_ce_trace available in the CondorCE package can be used to test the proper functionality of a CondorCE. It submits a small job running just `env` to the CE and regularly pools the job's status

You will need a valid Grid proxy, where the DN is accepted and mapped by the CondorCE to a user.

export X509_USER_CERT=/tmp/x509up_uSOMEUIDHERE
export X509_USER_CERT=/tmp/x509up_uSOMEUIDHERE
condor_ce_trace --debug condorce.fqdn.null

To increase the timeout for the trace to wait for the test job to start/finish, you can try to export CONDOR_CE_TRACE_ATTEMPTS a value larger than the default 300s.

Remote Submit

With a condor_ce_trace being successful, one should be able to submit to a running CondorCE from a node with Condor client tools available.
Ensure, that you have a valid grid proxy (voms-proxy-init, arcproxy,...); for simplicity you can export the proxy's path to a proper environment variable if not done automatically (since there seem to be different assumpions about a proxy/cert envvar name, you might want to export both).

export X509_USER_PROXY=/tmp/x509up_uSOMEUIDHERE
export X509_USER_CERT=/tmp/x509up_uSOMEUIDHERE

submit a vanilla-type job to your CE by giving its FQDN as -remote and -pool target

condor_submit -remote condorce.fqdn.null -pool condorce.fqdn.null:9619 htcondorce_job.submit

where the htcondorce_job.submit could look similar like

htcondorce_job.submit // Submission to a Remote CondorCE Scheduler

# universe = grid
# grid_resource = condor condorce.fqdn.null condorce.fqdn.null:9619
universe = vanilla
use_x509userproxy = true
X509UserProxy=$ENV(X509_USER_PROXY)
# how to deal with dn:uid mapping?
+Owner = undefined
# Files
executable = YOURPAYLOAD.sh
output = stdout
error = stderr
log = logs
# File transfer behavior
ShouldTransferFiles = YES
WhenToTransferOutput = ON_EXIT
####### Resources CE
## request number CPU cores
#+xcount = 1
## request memory in MB
#+maxMemory = 2000
## request runtime in minutes
#+maxWallTime = 10
##### queue??
### +remote_queue = "osg"  # Request the OSG queue #??
queue