The Community Scheduler Framework (CSF) is a set of Grid Services, implemented using the Globus Toolkit, which provides an environment for the development of metaschedulers that can dispatch jobs to resource managers such as LSF, SGE, PBS and Condor.
The Opal CSF plugin has been tested with CSF 4.0.5.1. You can download CSF 4.0.5.1 as well as its documentation from the CSF Source Forge download page.
The CSF plugin requires a valid proxy from the user who starts Tomcat. Please see Appendix on proxy scripts for a sample script to generate proxy.
In the opal.properties file, set opal.jobmanager to edu.sdsc.nbcr.opal.manager.CSFJobManager.
Create an Opal directory on all machines that CSF4 will be scheduling jobs to. The Opal job manager requires these directories to have the same name on all resources. In opal.properties, set csf4.workingDir to the relative path of this working directory with respect to the home directory of the CSF4 user.
If you have already sourced $GLOBUS_LOCATION/etc/globus-user-env.sh and $GLOBUS_LOCATION/etc/globus-devel-env.sh, then you need to unset the CLASSPATH. This is because there are jar conflicts between the library files used by gt4 and the library files used by Opal. The command below unsets the CLASSPATH.
export CLASSPATH="" |
Reinstall Opal by running the following command:
ant install |
Before restarting Tomcat, ensure that the environment for Globus and CSF4 is set up correctly by execute the following command:
source $GLOBUS_LOCATION/etc/globus-user-env.sh source $GLOBUS_LOCATION/etc/globus-devel-env.sh export CSF_CLASSPATH=$CLASSPATH |
Restart Tomcat for changes to take effect.
In your application configuration files, the binaryLocation element needs to be of the form $APPNAME:$BINARY. For example,
<binaryLocation>PDB2PQR:pdb2pqr.py</binaryLocation> |
This is because CSF4 can figure out the exact path of the application on a particular resource using the $APPNAME.