(Click to open topic with navigation)

22.0 Workload-Driven Cloud Services > References > Cloud-specific job template attributes

Conventions

22.6 Cloud-specific job template attributes

The table below details the job template attributes that relate specifically to workload-driven cloud services.

DESTROYTEMPLATE
Format <templateName>
Template
Type		 JSET
Description When this job is canceled, Moab creates a new job and applies the specified template (must be a generic system job). The original job remains until the new job successfully completes. The job created by DESTROYTEMPLATE is the cancel action for the original job. By default, the destroy job runs after the tracking job; however, you can write the destroy job script so that it can be called regardless of whether the setup or tracking job ran.

For a destroy job to run, its dependencies must be satisfied. You can disable dependencies by setting the NOVMDESTROYDEPENDENCIES scheduler flag.
Example 
JOBCFG[VMTracking]      GENERICSYSJOB=<triggerSpecs>
JOBCFG[VMTracking]      DESTROYTEMPLATE=destroyVM
 
JOBCFG[destroyVM]       GENERICSYSJOB=EType=start,AType=exec,Action="$HOME/destroy.py $VMID",timeout=5:00

When the VMTracking job is canceled, the destroyVM job is created. When that completes, VMTracking is removed.

GENERICSYSJOB
Format <triggerSpecifications>
Template
Type		 JSET
Description

Causes the job template to create a special type of system job (a generic system job) that does the following:

  • runs for the duration of the trigger to which it is attached
  • shares an exit code with the trigger
  • must have one trigger attached to it that meets certain requirements (See Generic System Job Trigger Requirements).

See Creating a Generic System Job for more information.
Example 
JOBCFG[test]      GENERICSYSJOB=EType=start,AType=exec,Action="$HOME/setupSoftware.py $IPAddr",Time=5:00
INHERITRES
Format <BOOLEAN> : TRUE | FALSE
Template
Type		 JSET
Description This job inherits the resource definition of the job that created it (via TEMPLATEDEPEND). The job that finishes first will pass its allocation directly to the next job.
Example 
JOBCFG[test]     INHERITRES=TRUE
MIGRATETEMPLATE
Format <templateName>
Template
Type		 JSET
Description

When this job is relocated, Moab creates a new job and applies the specified template (must be a generic system job). The original job remains until the new job successfully completes. The job created by MIGRATETEMPLATE is the migrate action for the original job.
Example 
JOBCFG[VMTracking]      MIGRATETEMPLATE=migrateVM
 
JOBCFG[migrateVM]       GENERICSYSJOB=EType=start,AType=exec,Action="$HOME/migrate.py $VMID $MASTERHOST",timeout=5:00 FLAGS=NORMSTART

When the VMTracking job is moved, the migrateVM job is created. When that completes, VMTracking migrates to the desired location.
TEMPLATEDEPEND
Format <dependencyType>:<templateName>
Template
Type		 JSET
Description Specifies when the job should run based on other jobs in the workflow. See the Job Dependency Syntax table for details.
Example 
JOBCFG[test]      TEMPLATEDEPEND=AFTEROK:test2
VMUSAGE
Format <requirepm|createvm>
Template
Type		 JSET
Description Distinguishes between jobs that request an OS that might be available as both a physical machine and as a virtual machine. If HIDEVIRTUALNODES is TRANSPARENT, then Moab will assume that jobs should create VMs. Valid options include:
  • requirepm - job must run on a physical machine. This setting tells Moab that you are using a normal HPC job.
  • createvm - job must run on a hypervisor that can create a VM with the specified image.

See Scheduling Jobs When VMs Exist for details.
Example 
JOBCFG[test]      VMUSAGE=createvm

A job with the test template applied must run on a hypervisor that can supports the VM it sets up.