Moab Workload Manager

11.10 Job Templates

11.10.1 Job Template Overview

Job templates are used for two primary purposes: (1) to provide a means of generically matching and categorizing jobs, and (2) to provide a means of setting arbitrary default or forced attributes for certain jobs. Job templates can be used in many aspects of scheduling but they are most commonly applied in the area of Peer Based Grid usage policy. Job templates are defined using the JOBCFG configuration parameter.

11.10.2 Applying Job Templates

11.10.2.1 Matching

The JOBMATCHCFG parameter allows relationships to be established between a number of job templates. JMAX and JMIN function as filters to determine whether a job is eligible for a subsequent template to be applied to the job. If a job is eligible, JDEF and JSET templates apply attributes to the job. The table in section 11.10.3 Job Template Extension Attributes indicates which job template types are compatible with which job template extension attributes. The following types of templates can be specified with the JOBMATCHCFG parameter:

Attribute Description
A potential job is rejected if it has matching attributes set or has resource requests that exceed those specified in this template.
A potential job is rejected if it does not have matching attributes set or has resource requests that do not meet or exceed those specified in this template.
A matching job has the specified attributes set as defaults but all values can be overridden by the user if the matching attribute is explicitly set at job submission time.
A matching job has the specified attributes forced to these values and these values override any values specified by the submitter at job submission time.
A matching job has its usage statistics reported into this template.

Note For JMAX, a job template can specify only positive non-zero numbers as maximum limits for generic resources. If a job requests a generic resource that is not limited by the template, then the template can still be used.

# limit all users to a total of two non-interactive jobs

USERCFG[DEFAULT]  MAXJOB=2

# reservation configuration

SRCFG[test] DESCRIPTION="compute pool for interactive and short duration jobs"
SRCFG[test] JOBATTRLIST=INTERACTIVE
SRCFG[test] MAXTIME=1:00:00
SRCFG[test] HOSTLIST=R:atl[16-63]

# job template configuration

JOBCFG[inter.min] FLAGS=interactive
JOBCFG[inter.set] FLAGS=ignpolicies

JOBMATCHCFG[interactive] JMIN=inter.min JSET=inter.set

In the preceding example, a reservation called test is created. This reservation is only accessible by interactive jobs and jobs that will take less than one hour to complete. Specifying MAXJOB=2 means that each user on the system is only allowed to run two jobs simultaneously.

The job template configuration is signified by the JOBCFG parameter. The inter.min template (JMIN) determines that if a job is marked as interactive it is eligible to have inter.set template applied to it. The JOBMATCHCFG parameter establishes the relationship between inter.min and inter.set. The inter.set template forces the ignpolicies flag on the job, which allows the job to ignore the MAXJOB policy. Also, the job automatically requests the reservation named test. Any user submitting a job may have as many interactive jobs running as resources permit, and the job runs inside the test reservation, which constrains the jobs to run on nodes at1[16-63]. With this template, users do not need to know to which nodes to send interactive jobs; Moab automatically sends interactive jobs to the nodes specified in the reservation.

11.10.2.2 Selecting

Rather than matching a job automatically based on job attributes, a specific template can be directly requested by setting the SELECT attribute to TRUE. Attributes specified in the job template are applied to the job.

JOBCFG[inter.set] FLAGS=ignpolicies SELECT=true

In the preceding example, instead of the interactive jobs automatically going to the reservation named test (as in the Matching example), users can request the inter.set template for the ignpolicies flag and the requested reservation test to be applied to the job.

Use the following to request the job template:

msub -l template=inter.set myjob.sh

Selecting a specific reservation is often used in creating workflows. See 11.10.7 Creating Workflows with Job Templates for more information.

11.10.3 Job Template Extension Attributes

When creating a job template, any attribute acceptable within the WIKI workload query data format can be used. In addition, job templates can use any of the extension attributes in the following table. Note that a checkmark in the Template Type (JMIN, JMAX, JDEF, JSET) row indicates compatibility with the associated attribute.

ACCOUNT
<ACCOUNT>[,<ACCOUNT>]...
JMIN JMAX JDEF JSET
Yes Yes Yes Yes
Account credentials associated with job. Used in job template matching.
JOBCFG[public]      FLAGS=preemptee
JOBCFG[public.min]  ACCOUNT=public_acct
JOBMATCHCFG[public] JMIN=public.min JSET=public
   
ACTION
HOLD or CANCEL
JMIN JMAX JDEF JSET
      Yes
Describes an action that is done to the job if the set template is applied.
JOBCFG[test.min] QOS=high
JOBCFG[test.set] ACTION=CANCEL
JOBMATCHCFG[test] JMIN=test.min JSET=test.set
   
ALLOCSIZE
<ALLOCSIZE>[,<DEALLOCSIZE>]
JMIN JMAX JDEF JSET
    Yes Yes
Number of application tasks to allocate/deallocate at each allocation adjustment.
JOBCFG[webdb] ALLOCSIZE=4
   
ALLOCDELAY
[[[DD]:HH]:MM]:SS
JMIN JMAX JDEF JSET
    Yes Yes
The amount of time to wait before trying to allocate a new resource. When you have a dynamic service job—ones that grow and shrink—ALLOCDELAY is the minimum amount of time Moab waits before allowing a change to the size of the service job. The size of the job should not change too quickly, so ALLOCDELAY specifies an amount of time that must elapse before another size change can occur.
JOBCFG[webdb] ALLOCDELAY=1:00
   
ALLOCSYNCTIME
[[[DD]:HH]:MM]:SS
JMIN JMAX JDEF JSET
    Yes Yes
Time indicating maximum duration Moab waits before forcing allocation decisions via provisioning or other steps.

Note By default, when deallocating resources, Moab does not reassign resources from one service to another until the service/job initially assigned the resources reports successful de-allocation via the workload query response.
JOBCFG[webdb]  ALLOCSYNCTIME=00:04:00
JOBCFG[sirius] ALLOCSYNCTIME=00:00:20

Moab forces the deallocation of resources assigned to webdb if the application does not release them within four minutes of a deallocation request. For the sirius application, Moab forces deallocation if not released by the application within twenty seconds of a deallocation request.

   
CLASS
<CLASS>[,<CLASS>]...
JMIN JMAX JDEF JSET
Yes Yes Yes Yes
Class credentials associated with job. Used in job template matching.
JOBCFG[night]      FLAGS=preemptor
JOBCFG[night.min]  CLASS=night_class
JOBMATCHCFG[night] JMIN=night.min JSET=night
   
CPULIMIT
[[[DD]:HH]:MM]:SS
JMIN JMAX JDEF JSET
Yes Yes Yes Yes
Maximum amount of CPU time used by all processes in the job.
JOBCFG[job.min]  CPULIMIT=1:00:00:00
JOBCFG[job.max]  CPULIMIT=2:00:00:00
   
DESCRIPTION
<STRING>
JMIN JMAX JDEF JSET
    Yes Yes
Description of the job.
JOBCFG[webdb] DESCRIPTION="Template job"
   
DPROCS
<INTEGER>
JMIN JMAX JDEF JSET
Yes Yes   Yes
Number of processors dedicated per task. Default is 1.
JOBCFG[job.min]  DPROCS=2
JOBCFG[job.max]  DPROCS=4
   
EUSER
<STRING>
JMIN JMAX JDEF JSET
    Yes Yes
In a job template, EUSER is the effective user, meaning that when a job starts it will change the user running the job to the one on the template.
JOBCFG[batch]    EUSER=render
   
EXEC
<STRING>
JMIN JMAX JDEF JSET
      Yes
Sets what the job runs, regardless of what the user sets.
JOBCFG[setup.pre]    EXEC=nfs/tools/setup.pre.sh
   
FLAGS
<JOBFLAG>[,<JOBFLAG>]...
JMIN JMAX JDEF JSET
Yes Yes Yes Yes
One or more legal job flag values.
JOBCFG[webdb] FLAGS=NORMSTART
   
GNAME
<STRING>
JMIN JMAX JDEF JSET
      Yes
Group credential associated with job.
JOBCFG[webserv] GNAME=service

Note For matching the group, see the GROUP attribute.

   
GRES
<generic resource>[:<COUNT>]
JMIN JMAX JDEF JSET
    Yes Yes
Consumable generic attributes associated with individual nodes or the special pseudo-node global, which provides shared cluster (floating) consumable resources. Use the NODECFG parameter to configure such resources.
JOBCFG[gres.set] GRES=abaqus:2

In this example, the gres.set template applies two Abaqus licenses per task to a matched job.

   
GROUP
<GROUP>[,<GROUP>]...
JMIN JMAX JDEF JSET
Yes Yes Yes Yes
Group credentials associated with job. Used in job template matching.
JOBCFG[webserv] GROUP=service

Note For setting the group, see the GNAME attribute.

   
MEM
<INTEGER>
JMIN JMAX JDEF JSET
Yes Yes Yes Yes
Maximum amount of physical memory per task used by the job. See Requesting Resources for more information.
JOBCFG[smalljobs] MEM=25
   
NODEACCESSPOLICY
One of the following: SHARED, SHAREDONLY, SINGLEJOB, SINGLETASK , SINGLEUSER, or UNIQUEUSER
JMIN JMAX JDEF JSET
    Yes Yes
Specifies how node resources will be shared by a job. See the Node Access Overview for more information.
JOBCFG[serverapp] NODEACCESSPOLICY=SINGLEJOB
   
NODERANGE
<MIN>[,<MAX>]
JMIN JMAX JDEF JSET
    Yes Yes
Minimum and maximum nodes allowed to be allocated to job.
JOBCFG[vizserver] NODERANGE=1,16
   
NODES
<INTEGER>
JMIN JMAX JDEF JSET
Yes Yes   Yes
Number of nodes required by job. Default is 1. See Node Definition for more information.
JOBCFG[job.min]  NODES=2
JOBCFG[job.max]  NODES=4
   
PARTITION
<PARTITION>[:<PARTITION>]...
JMIN JMAX JDEF JSET
Yes   Yes Yes
Specifies the partition (or partitions) in which a job must run.
JOBCFG[meis] PARTITION=math:geology
   
PREF
<STRING>
JMIN JMAX JDEF JSET
    Yes Yes
Specifies which node features are preferred by the job and should be allocated if available. See PREF for more information.
JOBCFG[meis] PREF=bigmem
   
PRIORITY
<INTEGER>
JMIN JMAX JDEF JSET
    Yes Yes
Relative job priority.
JOBCFG[meis] PRIORITY=25000
   
PROCRANGE
<MIN>[,<MAX>]
JMIN JMAX JDEF JSET
    Yes Yes
Minimum and maximum processors allowed to be allocated to job.
JOBCFG[meis] PROCRANGE=2,64
   
QOS
<QOS>[,<QOS>]...
JMIN JMAX JDEF JSET
Yes Yes Yes Yes
QoS credentials associated with job. Used in job template matching.
JOBCFG[admin]      RFEATURES=bigmem
JOBCFG[admin.min]  QOS=admin_qos
JOBMATCHCFG[admin] JMIN=admin.min JSET=admin
   
RARCH
<STRING>
JMIN JMAX JDEF JSET
      Yes
Architecture required by job.
JOBCFG[servapp] RARCH=i386
   
RFEATURES
<FEATURE>[,<FEATURE>]...
JMIN JMAX JDEF JSET
Yes Yes Yes Yes
List of features required by job.
JOBCFG[servapp] RFEATURES=fast,bigmem
   
RM
<STRING>
JMIN JMAX JDEF JSET
    Yes Yes
Destination resource manager to be associated with job.
JOBCFG[webdb] RM=slurm
   
ROPSYS
<STRING>
JMIN JMAX JDEF JSET
    Yes Yes
Operating system required by job.
JOBCFG[test.set] ROPSYS=windows
   
SELECT
<BOOLEAN> : TRUE | FALSE
JMIN JMAX JDEF JSET
       
Job template can be directly requested by job at submission.
JOBCFG[servapp] SELECT=TRUE
   
SOFTWARE
<RESTYPE>[{+|:}<COUNT>][@<TIMEFRAME>]
JMIN JMAX JDEF JSET
    Yes Yes
Indicates generic resources required by the job. See SOFTWARE for more information.
JOBCFG[servapp] SOFTWARE=matlab:2
   
SYSTEMJOBTYPE
 
JMIN JMAX JDEF JSET
Yes      
System job type (ex. vmcreate).
JOBCFG[vmcreate.min] SYSTEMJOBTYPE=vmcreate
JOBCFG[vmcreate.set] TRIGGER=atype=reserve,action="00:05:00",etype=end
JOBMATCHCFG[vmcreate] JMIN=vmcreate.min JSET=vmcreate.set
   
TARGETBACKLOG
[<MIN>,]<MAX>
JMIN JMAX JDEF JSET
    Yes Yes
Minimum and maximum backlog for application within job. In the case of dynamic jobs, Moab allocates/deallocates resources as needed to keep the job within the target range.
JOBCFG[pdb] TARGETBACKLOG=0.5,2.0
   
TARGETLOAD
[<MIN>,]<MAX>
JMIN JMAX JDEF JSET
    Yes Yes
Minimum and maximum load for application within job. In the case of dynamic jobs, Moab allocates/deallocates resources as needed to keep the job within the target range.
JOBCFG[pdb] TARGETLOAD=0.5,2.0
   
TARGETRESPONSETIME
[<MIN>,]<MAX>
JMIN JMAX JDEF JSET
    Yes Yes
Minimum and maximum response time in seconds for application within job. In the case of dynamic jobs, Moab allocates/deallocates resources as needed to keep the job within the target range.
JOBCFG[pdb] TARGETRESPONSETIME=0.5,2.0
   
TARGETTHROUGHPUT
[<MIN>,]<MAX>
JMIN JMAX JDEF JSET
    Yes Yes
Minimum and maximum throughput for application within job. In the case of dynamic jobs, Moab allocates/deallocates resources as needed to keep the job within the target range.
JOBCFG[pdb] TARGETTHROUGHPUT=0.5,2.0
   
TASKS
<INTEGER>
JMIN JMAX JDEF JSET
Yes Yes   Yes
Number of tasks required by job. Default is 1. See Task Definition for more information.
JOBCFG[job.min]  TASKS=4
JOBCFG[job.max]  TASKS=8
   
TASKPERNODE
<INTEGER>
JMIN JMAX JDEF JSET
Yes Yes   Yes
Exact number of tasks required per node. Default is 0.
JOBCFG[job.min]  TASKPERNODE=2
JOBCFG[job.max]  TASKPERNODE=4
   
TEMPLATEDEPEND
<TYPE>:<TEMPLATE_NAME>
JMIN JMAX JDEF JSET
       
Create another job from the TEMPLATE_NAME job template, on which any jobs using this template will depend. This is used for dynamically creating workflows. See Job Dependencies for more information.
JOBCFG[engineering] TEMPLATEDEPEND=AFTER:setup.pre
JOBCFG[setup.pre]   SELECT=TRUE EXEC=/tools/setup.pre.sh
   
UNAME
<STRING>
JMIN JMAX JDEF JSET
      Yes
User credential associated with job.
JOBCFG[webserv] UNAME=service

Note For matching the user, see the USER attribute.

   
USER
<USER>[,<USER>]...
JMIN JMAX JDEF JSET
Yes Yes Yes Yes
User credentials associated with job.
JOBCFG[webserv] USER=service

Note For setting the user, see the UNAME attribute.

   
VARIABLE
<NAME>[:<VAL>]
JMIN JMAX JDEF JSET
Yes Yes   Yes
Variables attached to the job template.
JOBCFG[this] VARIABLE=var1:1 VARIABLE=var2:1

Note To specify multiple variables, set VARIABLE separately for each one.

   
WCLIMIT
[[HH:]MM:]SS
JMIN JMAX JDEF JSET
Yes Yes Yes Yes
Walltime required by job. Default is 864000 (100 hours).
JOBCFG[job.min]  WCLIMIT=2:00:00
JOBCFG[job.max]  WCLIMIT=12:00:00
   
WORK
<DOUBLE>
JMIN JMAX JDEF JSET
    Yes Yes
Unitless measure of work accomplished per task.
JOBCFG[webserv] WORK=10.5
   

11.10.4 Resource Manager Templates

Job templates can also be applied to resource managers modifying attributes of jobs submitted to, migrated to, or routed through specified resource manager interfaces. In particular the RMCFG attributes MAX.JOB, MIN.JOB, SET.JOB, and DEFAULT.JOB can be used. However, the meanings of resource manager job templates are slightly different than their JOBMATCHCFG counterparts as described in the following table.

Attribute Description
A potential job is not allowed to access the resource manager if it has matching attributes set or has resource requests that exceed those specified in this template.
A potential job is not allowed to access the resource manager if it does not have matching attributes set or has resource requests that do not meet or exceed those specified in this template.
A job associated with this resource manager has the specified attributes set as defaults but all values can be overridden by the user if the matching attribute is explicitly set at job submission time.
A job associated with this resource manager has the specified attributes forced to these values and these values override any values specified by the submitter at job submission time.

11.10.5 Job Template Examples

Job templates can be used for a wide range of purposes including enabling automated learning, setting up custom application environments, imposing special account constraints, and applying group default settings. The following examples highlight some of these uses:

11.10.5.1 Example 1: Setting Up Application-Specific Environments

JOBCFG[xxx] EXEC=*app* JOBPROLOG=/usr/local/appprolog.x

11.10.5.2 Example 2: Applying Job Preferences and Defaults

JOBCFG[xxx] CLASS=appq EXEC=*app* PREF=clearspeed

NODEALLOCATIONPOLICY PRIORITY
NODECFG[DEFAULT] PRIOF=5.0*PREF

11.10.5.3 Example 3: Applying Resource Constraints to Fuzzy Collections

In the following example, a job template match is set up. Using the JOBMATCHCFG parameter, Moab is configured to apply all attributes of the inter.set job template to all jobs that match the constraints of the inter.min job template. In this example, all interactive jobs are assigned the ignpolicies flag that allows them to ignore active, idle, system, and partition level policies. Interactive jobs are also locked into the test standing reservation and thus only allowed to run on the associated nodes.

# limit all users to a total of two non-interactive jobs

USERCFG[DEFAULT]  MAXJOB=2

SRCFG[test] DESCRIPTION="compute pool for interactive and short duration jobs"
SRCFG[test] JOBATTRLIST=INTERACTIVE
SRCFG[test] MAXTIME=1:00:00
SRCFG[test] HOSTLIST=R:atl[16-63]

JOBCFG[inter.min] FLAGS=interactive
JOBCFG[inter.set] FLAGS=ignpolicies

JOBMATCHCFG[interactive] JMIN=inter.min JSET=inter.set

11.10.5.4 Example 4: Resource Manager Templates

In the following example, interactive jobs are not allowed to enter through this resource manager and any job that does route in from this resource manager interface has the preemptee flag set.

JOBCFG[no_inter]    FLAGS=interactive
JOBCFG[preempt_job] FLAGS=preemptee

RMCFG[gridA.in] MAX.JOB=no_inter SET.JOB=preempt_job

11.10.6 Managing Job Templates

11.10.6.1 Dynamically Creating Job Templates

Job templates can be dynamically created while Moab is running using the mschedctl -m command.

Note Dynamically created job templates will only survive a Moab restart if the --flags=pers[istent] flag is used.

> mschedctl -m --flags=pers "JOBCFG[preempt] FLAGS=PREEMPTOR"
> mschedctl -m --flags=pers "JOBCFG[preempt] SELECT=TRUE" 
> msub -l template=preempt mysjob.sh

11.10.6.2 Removing Job Templates

Job templates cannot be dynamically removed. You can only remove job templates by commenting out (or removing) the template definition (lines) in the moab.cfg file; then you must restart Moab.

11.10.6.3 Dynamically Modifying Job Templates

Job templates can be dynamically modified by using the mschedctl -m command.

Note Dynamic changes do not persist after a shutdown of the Moab server unless the --flags=pers[istent] flag is used.

> mschedctl -m "JOBCFG[single] NODEACCESSPOLICY=SINGLEJOB"

11.10.6.4 Viewing Job Templates

Job templates can be viewed by specifying "template:" before the template name in checkjob and also by using the command mdiag -j as in the following example:

> mdiag -j --flags=policy

> checkjob -v template:match.min

See Also