| Moab Workload Manager® |
19.1 Trigger Creation
- 19.1.1 Object Trigger Overview
- 19.1.2 Trigger Creation Syntax
- 19.1.3 Creating Triggers
- 19.1.4 Naming Triggers
- 19.1.5 Associating the JOBTRIGGER Attribute with a Class
19.1.1 Object Trigger Overview
Moab can launch events or triggers based on certain events. For example, an administrator may want to send an email to the owner of a particular reservation when the usage drops below a specific threshold. Or a user may want to launch an evaluation script five minutes before a job is scheduled for completion. Triggers can be associated with jobs, nodes, reservations, or the core scheduler and enable actions to be taken when the specified event, offset, and threshold criteria are satisfied.
When defining a trigger, several formats & methods exist.
19.1.2 Trigger Creation Syntax
Two formats may be used when creating triggers:
<ATTR>=<VALUE>[[{&,}<ATTR>=<VALUE>]...]
or the more restrictive:
<EType>[+<Offset>][@<Threshold>];<AType>[@<Action>][[,<TRIGGER2>]...]
19.1.3 Creating Triggers
Triggers can be created from both the configuration file and the command line. Triggers can be associated with an object such as a standing reservation, node, resource manager, or the scheduler when the object is instantiated. To do this, use the TRIGGER attribute with the associated object parameter, such as SRCFG (see Managing Reservations for more details), NODECFG, RMCFG, or SCHEDCFG.
To dynamically add a trigger to an existing object, use the mschedctl command. To add a trigger to an administrative reservation, use the mrsvctl command. Triggers may be added to jobs by specifying the trig resource manager extension when submitting the job through msub, as in the following example:
Example
Triggers can also be created on system jobs using the msub command, as shown in the following example. The benefit of system job triggers is that system jobs do not have to require any system resources. System jobs exist until manually cancelled or completed, a process that can be handled by scripts or trigger actions. This provides one means for creating standing triggers that fire at a specified time or when certain external dependencies are fulfilled.
Example
For security reasons, only QoS with the trigger flag can have jobs with attached triggers. This can be set up by creating an appropriate QoS in the moab.cfg file.
Example
In this example, a QoS named triggerok is created with the trigger flag. The user user1 is then added to this QoS. This user will then be able to attach triggers to jobs.
Please note that when creating job triggers via msub, "&" must be used to delimit the fields. All job triggers are removed when the associated job is cancelled.
19.1.4 Naming Triggers
By default, triggers are assigned a numeric ID by Moab. However, in many cases, managing triggers can become quite complicated if relying only on this ID. Therefore, users may assign an alphanumeric name up to 16 characters in length for each trigger. The Moab-assigned ID number is then appended to the end of the user-supplied name. The trigger name is specified at creation or modification using the Name trigger attribute.
Example
In this case, the new trigger attached to my.job will be named myTrigger.<TRIGID>, where <TRIGID> is the ID assigned automatically by Moab. This name will appear in the output of the mdiag -T command. Carefully chosen trigger names can greatly improve the readability of this output.
19.1.5 Associating the JOBTRIGGER Attribute with a Class
Job triggers can be directly associated with jobs submitted into a class using the JOBTRIGGER attribute. Job triggers are described using the standard trigger description language specified in the Trigger overview section. In the example that follows, users submitting jobs to the class debug will be notified with a descriptive message any time their job is preempted.
See Also