[drmaa-wg] Jini+DRMAA integration plus Condor problem

Peter Troeger peter.troeger at hpi.uni-potsdam.de
Wed Nov 24 18:11:42 CST 2004


Hello,

> We are also creating a version with a backend interface to the Condor 
> system. This is where we have a problem and perhaps some of you can 
> help us
>
You may be interested in a DRMAA Condor demo I gave on GGF12. One of the 
outcomes is a configure script which supports both SGE and Condor:

http://www.dcl.hpi.uni-potsdam.de/research/grid/drmaa/

> out. Since Condor only provides a C implementation of the DRMAA spec 
> we our creating a new Java/JNI JDRMAA version based on the SGE one. 
> The first real problem we have is that Condor does not support the 
> mandatory Working Directory attribute and at the moment I cannot see 
> how one can programmatically submit jobs to Condor without this. Where 
> should users put their executables? Will all go to a system-wide 
> submit directory? There may be a simple answer to this, so excuse me 
> if I just miss some information or don’t understand how Condor uses 
> the file system for this.
>
Condor distinguishes between installations with and without a shared 
file system. This is configured with the FILESYSTEM_DOMAIN configuration 
parameter.
In the first case you need to give an absolute path for the executable 
in the job template. Condor will use exactly this path in order to find 
the executable, which may lead sometimes to problems with automounter paths.
In the second case, Condor will transfer your executable to a spool 
directory on the destination machine. Therefore it should be enough to 
use the executable name only, all file accesses are relative to the 
spool directory.
The latest Condor 6.7.2 version lacks some DRMAA functionality, you can 
find more information in the README file. Don't hesitate to contact me 
directly if you have any further questions.

Regards,

Peter.





More information about the drmaa-wg mailing list