[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [HTCondor-users] Condor & Bosco submissions




On Wed, 6 Mar 2013, Guillermo Marco Puche wrote:

Hello Derek,

Hi Guillermo: let's see if we can make some progress while our timezone
is awake.

At this moment i'm submiting jobs to remote SGE in this way.

I've a Condor Job file which specifies Grid Universe, remote cluster user and host etc... Executable specified in this Condor file is a bash script that starts a small workflow.

Problem is that all SGE parameters inside my bash script are being ignored. And I'm in need of different SGE configuration for each different Workflow (select different queue, slot number, max memory, etc..)

This can indeed be done via the '+remote_cerequirements' attribute, but depends on the contents of this file:
~/bosco/glite/bin/sge_local_submit_attributes.sh

What do you find there ?
The CErequirements are translated into a set of bourne shell attributes
(common for all batch systems), that are then turned into SGE-specific submit directives by sge_local_submit_attributes.sh.

Are custom submit properties simple variables? I don't understand the concept with the example in manual.

If you set remote_cerequirements as follows:
+remote_cerequirements = NumJobs == 100 && Queue == "all.q"

the sge_local_submit_attributes.sh script
will be executed when the job is submitted with these (Bourne shell)
attributes set:

NumJobs='100'
Queue='"all.q"'

The output of the script will then be merged with the submit script.

So, *if* sge_local_submit_attributes.sh contains something like this:

if [ -n "$Queue" ]; then
  echo "#\$ -q ${Queue}"
fi
if [ -n "$NumJobs" ]; then
  echo "#\$ -t ${NumJobs}"
fi

then your requirements will translate into proper SGE qsub directives.

In case you (sanely) wonder about the complexity: this arrangement was built around the needs of batch system administrators at large sites (most requirements came from CERN): they would prefer to be in control of what user jobs can request to their batch system, and use a system-wide script to translate (and clamp) the user 'requirements' to what makes sense to their installation. This approach tries to push the Condor semantics of requirements matching as close as possible to the internals of the batch system installation at a given site. This also explains why it's hard to standardize these 'local_submit_attributes' scripts into something that makes sense everywhere.

Hope this helps.
Francesco Prelz
INFN Milano