You are here: 9 General Job Administration > General Job Policies

9.7 General Job Policies

There are a number of configurable policies that help control advanced job functions. These policies help determine allowable job sizes and structures.

9.7.1 Multi-Node Support

You can configure the ability to allocate resources from multiple nodes to a job with the MAX.NODE limit.

9.7.2 Multi-Req Support

Jobs can specify multiple types of resources for allocation. For example, a job could request 4 nodes with 256 MB of memory and 8 nodes with feature fast present.

Resources specified in a multi-req job are delimited with a plus sign (+).

Neither SPANEVENLY nor DELAY values of the NODESETPLUS parameter will work with multi-req jobs or preemption.

Example 9-1:  

-l nodes=4:ppn=1+10:ppn=5+2:ppn=2

This example requests 4 nodes with 1 proc each, 10 nodes with 5 procs each, and 2 nodes with 2 procs each. The total number of processors requested is (4*1) + (10*5) + (2*2), or 58 processors.

Example 9-2:  

-l nodes=15+1:ppn=4

The job submitted in this example requests a total of 16 nodes. 15 of these nodes have no specific requirements, but the remaining node must have 4 processors.

Example 9-3:  

-l nodes=3:fast+1:io

The job requests a total of 4 nodes: 3 nodes with the fast feature and 1 node with the io feature.

9.7.3 Malleable Job Support

A job can specify whether it is able to use more processors or less processors and what effect, if any, that has on its wallclock time. For example, a job may run for 10 minutes on 1 processor, 5 minutes on 2 processors and 3 minutes on 3 processors. When a job is submitted with a task request list attached, Moab determines which task request fits best and molds the job based on its specifications. To submit a job with a task request list and allow Moab to mold it based on the current scheduler environment, use the TRL (Format 1) or the TRL (Format 2) flag in the Resource Manager Extension.

9.7.4 Enabling Job User Proxy

By default, user proxying is disabled. To be enabled, it must be authorized using the PROXYLIST attribute of the USERCFG parameter. This parameter can be specified either as a comma-delimited list of users or as the keyword validate. If the keyword validate is specified, the RMCFG attribute JOBVALIDATEURL should be set and used to confirm that the job's owner can proxy to the job's execution user. An example script performing this check for ssh-based systems is provided in the tools directory (See Job Validate Tool Overview.).

For some resource managers (RM), proxying must also be enabled at the RM level. The following example shows how ssh-based proxying can be accomplished in a Moab+Torque with SSH environment.

To validate proxy users, Moab must be running as root.

Example 9-4: SSH Proxy Settings

USERCFG[DEFAULT] PROXYLIST=validate
RMCFG[base]  TYPE=<resource manager>  JOBVALIDATEURL=exec://$HOME/tools/job.validate.sshproxy.pl
> qmgr -c 's s allow_proxy_user=true'
> su - testuser
> qsub -I -u testuser2 
qsub: waiting for job 533.igt.org to start
qsub: job 533.igt.org ready
testuser2@igt:~$

In this example, the validate tool, 'job.validate.sshproxy.pl', can verify proxying is allowed by becoming the submit user and determining if the submit user can achieve passwordless access to the specified execution user.  However, site-specific tools can use any method to determine proxy access including a flat file look-up, database lookup, querying of an information service such as NIS or LDAP, or other local or remote tests.   For example, if proxy validation is required but end-user accounts are not available on the management node running Moab, the job validate service could perform the validation test on a representative remote host such as a login host.

This feature supports qsub only.

The job validate tool is highly flexible allowing any combination of job attributes to be evaluated and tested using either local or remote validation tests.  The validate tool allows not only pass/fail responses but also allows the job to be modified, or rejected in a custom manner depending on the site or the nature of the failure.

Related Topics 

© 2017 Adaptive Computing