Fields: Standing Reservations

The unique ID of the standing reservation.

If set to ReservationAccess.SHARED, allows a standing reservation to use resources already allocated to other non-job reservations. Otherwise, these other reservations block resource access.

Specifies that jobs with the associated accounts may use the resources contained within this reservation.

The set of access control rules associated with this standing reservation.

Specifies the account to which Moab will charge all idle cycles within the reservation (via the allocation manager).

Specifies the user to which Moab will charge all idle cycles within the reservation (via the allocation manager).
Must be used in conjunction with chargeAccount

Specifies that jobs with the associated classes/queues may use the resources contained within this reservation.

Specifies that jobs originating within the listed clusters may use the resources contained within this reservation.

Specifies a descriptive message associated with the standing reservation and all child reservations

Specifies which days of the week the standing reservation is active.
Valid values are Mon, Tue, Wed, Thu, Fri, Sat, Sun, or [ALL].

Specifies the depth of standing reservations to be created, starting at depth 0 (one per period).

Specifies if the standing reservation should no longer spawn child reservations.

The ending offset, in seconds, from the beginning of the current period (DAY or WEEK), for this standing reservation. See examples at startOffset.

Specifies special reservation attributes.

Specifies the groups allowed access to this standing reservation.

Specifies the set of hosts that the scheduler can search for resources to satisfy the reservation. If specified using the class:X format, Moab only selects hosts that support the specified class. If TASKCOUNT is also specified, only TASKCOUNT tasks are reserved. Otherwise, all matching hosts are reserved.

Specifies job attributes that grant a job access to the reservation.
Values can be specified with a != assignment to only allow jobs NOT requesting a certain feature inside the reservation.

Specifies the maximum number of jobs that can run in the reservation.

Specifies the maximum time for jobs allowable. Can be used with affinity to attract jobs with same maxTime.

Messages associated with the reservation.

Specifies the required node features for nodes that are part of the standing reservation.

Specifies the operating system that should be in place during the reservation. Moab provisions this OS at reservation start and restores the original OS at reservation completion.

Specifies the owner of the reservation. Setting ownership for a reservation grants the user management privileges, including the power to release it.
Setting a user as the owner of a reservation gives that user privileges to query and release the reservation.
For sandbox reservations, sandboxes are applied to a specific peer only if owner is set to CLUSTER:<PEERNAME>

Specifies the partition in which to create the standing reservation. Defaults to ALL.

Period of the Standing reservation. Defaults to TimeWindow.DAY.

Specifies the processor limit for jobs requesting access to this standing reservation.

Specifies the processor-second limit for jobs requesting access to this standing reservation.

Specifies that jobs with the listed QoS names can access the reserved resources.

A list of reservations to which the specified reservation has access.

The group of the reservation.

Specifies what resources constitute a single standing reservation task. (Each task must be able to obtain all of its resources as an atomic unit on a single node.)
Supported resources currently include the following:

• PROCS (number of processors)
• MEM (real memory in MB)
• DISK (local disk in MB)
• SWAP (virtual memory in MB)

Specifies the minimum time in the future at which the reservation may start. This offset is rolling meaning the start time of the reservation will continuously roll back into the future to maintain this offset. Rollback offsets are a good way of providing guaranteed resource access to users under the conditions that they must commit their resources in the future or lose dedicated access. See QoS Credential in the Moab Workload Manager documentation for more information on quality of service and service level agreements.

The starting offset, in seconds, from the beginning of the current period (DAY or WEEK), for this standing reservation. If period is DAY, the offset is from midnight (00:00) of the current day. If period is WEEK, the offset is from midnight Sunday of the current week.

Example 1: For a standing reservation that begins at 9:00 and ends at 17:00 every day, period is DAY, startOffset is 32400 (9*60*60), and endOffset is 61200 (17*60*60).

Example 2: For a standing reservation that begins at 9:00 Monday and ends at 17:00 Friday every week, period is WEEK, startOffset is 118800 ((24+9)*60*60), and endOffset is 493200 (((5*24)+17)*60*60).

Specifies how many tasks should be reserved for the reservation
Default is 0 (unlimited tasks).

Specifies the minimum number of tasks per node that must be available on eligible nodes.
Default is 0 (no TPN constraint)

Specifies the maximum allowed overlap between the standing reservation and a job requesting resource access.
Default is null (-1 in moab)

Triggers associated with the reservation.

The type of the reservation.

Specifies which users have access to the resources reserved by this reservation.

Reservation ACLs allow or deny access to reserved resources but they may also be configured to affect a job's affinity for a particular reservation. By default, jobs gravitate toward reservations through a mechanism known as positive affinity. This mechanism allows jobs to run on the most constrained resources leaving other, unreserved resources free for use by other jobs that may not be able to access the reserved resources. Normally this is a desired behavior. However, sometimes, it is desirable to reserve resources for use only as a last resort-using the reserved resources only when there are no other resources available. This last resort behavior is known as negative affinity.

Defaults to AclAffinity.POSITIVE.

The type of comparison to make against the ACL object.

Defaults to ComparisonOperator.EQUAL.

The type of the object that is being granted (or denied) access.

The name of the object that is being granted (or denied) access.

One of:

• <
• <=
• ==
• >=
• >

The unique ID of the reservation.

Accountable Account.

Accountable Group.

Accountable QOS.

Accountable User.

The set of access control rules associated with this reservation.

The number of allocated nodes for this reservation.

The nodes allocated to the reservation.

The number of allocated processors.

The number of allocated tasks.

Reservation's comments or description.

Creation date. Automatically set by Moab when a user creates the reservation.

The duration of the reservation (in seconds).

The end date of the reservation. This is especially useful for one-time reservations, which have an exact time for when a reservation ends.

The list of jobs to exclude. Client must also set the IGNJOBRSV reservation flag. Otherwise, results are undefined. Used only during reservation creation.

The date/time when the reservation expires and vacates.

The flags associated with the reservation.

Global reservation ID.

The list of nodes a user can select to reserve. This may or may not be the nodes that are currently allocated to this reservation. Note: Either hostListExpression or taskCount must be set to create a reservation.

The user-specified prefix for this reservation. If provided, Moab combines the idPrefix with an integer, and the combination is the unique identifier for this reservation.

State whether or not this reservation is currently active.

States whether reservation resource usage is tracked.

When a label is assigned to a reservation, the reservation can then be referenced by that label as well as by the reservation name.

The maximum number of tasks for this reservation.

Messages for the reservation.

The owner of the reservation

The ID of the partition this reservation is for.

The profile that this reservation is using. A profile is a specification of attributes that all reservations share. Used only during reservation creation.

The reservation's requirements.

The reservation group to which the reservation belongs.

The reservation's resources. This field is a map, where the key is PROCS, MEM DISK, SWAP, or one or more user-defined keys.

The start time for the reservation. This is especially useful for one-time reservations, which have an exact time for when a reservation starts.

The reservation's statistical information.

The reservation sub-type.

The number of tasks that must be allocated to satisfy the reservation request. Note: Either hostListExpression or taskCount must be set to create a reservation.

Trigger for reservation. Used only during reservation creation.

The IDs of the triggers attached to this reservation.

The globally-unique reservation index.

The set of variables for this reservation.

The id of the object.

The author of the message.

The time the message was created in epoch time.

The time the message will be deleted in epoch time.

The index of the message relative to other messages in Moab's memory.

The comment information itself.

The number of times this message has been displayed.

An optional priority that can be attached to the comment.

Required architecture.

The list of features required for this reservation.

Required feature mode.

Required node memory, in MB.

Required number of nodes.

The list of node IDs required for this reservation.

Required Operating System.

Required task count.

The current active processor-seconds in the last reported iteration.

The current idle processor-seconds in the last reported iteration.

The total active processor-seconds over the life of the reservation.

The total idle processor-seconds over the life of the reservation.

Trigger id - internal ID used by moab to track triggers

For exec atype triggers, signifies executable and arguments. For jobpreempt atype triggers, signifies PREEMPTPOLICY to apply to jobs that are running on allocated resources. For changeparam atype triggers, specifies the parameter to change and its new value (using the same syntax and behavior as the changeparam command).

Time (in seconds) Moab will suspend normal operation to wait for trigger execution to finish. Use caution as Moab will completely stop normal operation until BlockTime expires.

Time at which trigger should be terminated if it has not already been activated.

Specifies the time (in seconds) that the threshold condition must exist before the trigger fires.

When used in conjunction with MultiFire and RearmTime trigger will fire at regular intervals. Can be used with TriggerEventType.EPOCH to create a Standing Trigger.
Defaults to false

Specifies the number of times Action will be attempted before the trigger is designated a failure.

Specifies whether this trigger can fire multiple times. Defaults to false.

Trigger name - can be auto assigned by moab or requested. Alphanumeric up to 16 characters in length

The ID of the object which this is attached to.

The type of object which this is attached to. Possible values:

• vm - Virtual Machine

Relative time offset from event when trigger can fire.

Can be used in conjunction with Offset to have a trigger fire at the beginning of the specified period. Can be used with EType epoch to create a standing trigger.

Time between MultiFire triggers; rearm time is enforced from the trigger event time.

Variables this trigger requires to be set or not set before it will fire. Preceding the string with an exclamation mark (!) indicates this variable must NOT be set. Used in conjunction with Sets to create trigger dependencies.

Variable values this trigger sets upon success or failure. Preceding the string with an exclamation mark (!) indicates this variable is set upon trigger failure. Preceding the string with a caret (^) indicates this variable is to be exported to the parent object when the current object is destroyed through a completion event. Used in conjunction with Requires to create trigger dependencies.

Reservation usage threshold - When reservation usage drops below Threshold, trigger will fire.
Threshold usage support is only enabled for reservations and applies to percent processor utilization. gmetric thresholds are supported with job, node, credential, and reservation triggers. See Threshold Triggers in the Moab Workload Manager documentation for more information.

Time allotted to this trigger before it is marked as unsuccessful and its process (if any) killed.

Variable this trigger destroys upon success or failure.

NOTE: A timed-out trigger will only receive one kill signal. This means that if you specify this flag, a timed-out trigger will only receive the SIGTERM signal, and never the SIGKILL signal.

Trigger id - internal ID used by moab to track triggers

For exec atype triggers, signifies executable and arguments. For jobpreempt atype triggers, signifies PREEMPTPOLICY to apply to jobs that are running on allocated resources. For changeparam atype triggers, specifies the parameter to change and its new value (using the same syntax and behavior as the changeparam command).

Time (in seconds) Moab will suspend normal operation to wait for trigger execution to finish. Use caution as Moab will completely stop normal operation until BlockTime expires.

Time at which trigger should be terminated if it has not already been activated.

Specifies the time (in seconds) that the threshold condition must exist before the trigger fires.

When used in conjunction with MultiFire and RearmTime trigger will fire at regular intervals. Can be used with TriggerEventType.EPOCH to create a Standing Trigger.
Defaults to false

Specifies the number of times Action will be attempted before the trigger is designated a failure.

Specifies whether this trigger can fire multiple times. Defaults to false.

Trigger name - can be auto assigned by moab or requested. Alphanumeric up to 16 characters in length

The ID of the object which this is attached to.

The type of object which this is attached to. Possible values:

• vm - Virtual Machine

Relative time offset from event when trigger can fire.

Can be used in conjunction with Offset to have a trigger fire at the beginning of the specified period. Can be used with EType epoch to create a standing trigger.

Time between MultiFire triggers; rearm time is enforced from the trigger event time.

Variables this trigger requires to be set or not set before it will fire. Preceding the string with an exclamation mark (!) indicates this variable must NOT be set. Used in conjunction with Sets to create trigger dependencies.

Variable values this trigger sets upon success or failure. Preceding the string with an exclamation mark (!) indicates this variable is set upon trigger failure. Preceding the string with a caret (^) indicates this variable is to be exported to the parent object when the current object is destroyed through a completion event. Used in conjunction with Requires to create trigger dependencies.

Reservation usage threshold - When reservation usage drops below Threshold, trigger will fire.
Threshold usage support is only enabled for reservations and applies to percent processor utilization. gmetric thresholds are supported with job, node, credential, and reservation triggers. See Threshold Triggers in the Moab Workload Manager documentation for more information.

Time allotted to this trigger before it is marked as unsuccessful and its process (if any) killed.

Variable this trigger destroys upon success or failure.

The unique ID of the standing reservation.

If set to ReservationAccess.SHARED, allows a standing reservation to use resources already allocated to other non-job reservations. Otherwise, these other reservations block resource access.

Specifies that jobs with the associated accounts may use the resources contained within this reservation.

The set of access control rules associated with this standing reservation.

Specifies the account to which Moab will charge all idle cycles within the reservation (via the allocation manager).

Specifies the user to which Moab will charge all idle cycles within the reservation (via the allocation manager).
Must be used in conjunction with chargeAccount

Specifies that jobs with the associated classes/queues may use the resources contained within this reservation.

Specifies that jobs originating within the listed clusters may use the resources contained within this reservation.

Specifies a descriptive message associated with the standing reservation and all child reservations

Specifies which days of the week the standing reservation is active.
Valid values are Mon, Tue, Wed, Thu, Fri, Sat, Sun, or [ALL].

Specifies the depth of standing reservations to be created, starting at depth 0 (one per period).

Specifies if the standing reservation should no longer spawn child reservations.

The ending offset, in seconds, from the beginning of the current period (DAY or WEEK), for this standing reservation. See examples at startOffset.

Specifies special reservation attributes.

Specifies the groups allowed access to this standing reservation.

Specifies the set of hosts that the scheduler can search for resources to satisfy the reservation. If specified using the class:X format, Moab only selects hosts that support the specified class. If TASKCOUNT is also specified, only TASKCOUNT tasks are reserved. Otherwise, all matching hosts are reserved.

Specifies job attributes that grant a job access to the reservation.
Values can be specified with a != assignment to only allow jobs NOT requesting a certain feature inside the reservation.

Specifies the maximum number of jobs that can run in the reservation.

Specifies the maximum time for jobs allowable. Can be used with affinity to attract jobs with same maxTime.

Messages associated with the reservation.

Specifies the required node features for nodes that are part of the standing reservation.

Specifies the operating system that should be in place during the reservation. Moab provisions this OS at reservation start and restores the original OS at reservation completion.

Specifies the owner of the reservation. Setting ownership for a reservation grants the user management privileges, including the power to release it.
Setting a user as the owner of a reservation gives that user privileges to query and release the reservation.
For sandbox reservations, sandboxes are applied to a specific peer only if owner is set to CLUSTER:<PEERNAME>

Specifies the partition in which to create the standing reservation. Defaults to ALL.

Period of the Standing reservation. Defaults to TimeWindow.DAY.

Specifies the processor limit for jobs requesting access to this standing reservation.

Specifies the processor-second limit for jobs requesting access to this standing reservation.

Specifies that jobs with the listed QoS names can access the reserved resources.

A list of reservations to which the specified reservation has access.

The group of the reservation.

Specifies what resources constitute a single standing reservation task. (Each task must be able to obtain all of its resources as an atomic unit on a single node.)
Supported resources currently include the following:

• PROCS (number of processors)
• MEM (real memory in MB)
• DISK (local disk in MB)
• SWAP (virtual memory in MB)

Specifies the minimum time in the future at which the reservation may start. This offset is rolling meaning the start time of the reservation will continuously roll back into the future to maintain this offset. Rollback offsets are a good way of providing guaranteed resource access to users under the conditions that they must commit their resources in the future or lose dedicated access. See QoS Credential in the Moab Workload Manager documentation for more information on quality of service and service level agreements.

The starting offset, in seconds, from the beginning of the current period (DAY or WEEK), for this standing reservation. If period is DAY, the offset is from midnight (00:00) of the current day. If period is WEEK, the offset is from midnight Sunday of the current week.

Example 1: For a standing reservation that begins at 9:00 and ends at 17:00 every day, period is DAY, startOffset is 32400 (9*60*60), and endOffset is 61200 (17*60*60).

Example 2: For a standing reservation that begins at 9:00 Monday and ends at 17:00 Friday every week, period is WEEK, startOffset is 118800 ((24+9)*60*60), and endOffset is 493200 (((5*24)+17)*60*60).

Specifies how many tasks should be reserved for the reservation
Default is 0 (unlimited tasks).

Specifies the minimum number of tasks per node that must be available on eligible nodes.
Default is 0 (no TPN constraint)

Specifies the maximum allowed overlap between the standing reservation and a job requesting resource access.
Default is null (-1 in moab)

Triggers associated with the reservation.

The type of the reservation.

Specifies which users have access to the resources reserved by this reservation.

Reservation ACLs allow or deny access to reserved resources but they may also be configured to affect a job's affinity for a particular reservation. By default, jobs gravitate toward reservations through a mechanism known as positive affinity. This mechanism allows jobs to run on the most constrained resources leaving other, unreserved resources free for use by other jobs that may not be able to access the reserved resources. Normally this is a desired behavior. However, sometimes, it is desirable to reserve resources for use only as a last resort-using the reserved resources only when there are no other resources available. This last resort behavior is known as negative affinity.

Defaults to AclAffinity.POSITIVE.

The type of comparison to make against the ACL object.

Defaults to ComparisonOperator.EQUAL.

The type of the object that is being granted (or denied) access.

The name of the object that is being granted (or denied) access.

One of:

• <
• <=
• ==
• >=
• >

The unique ID of the reservation.

Accountable Account.

Accountable Group.

Accountable QOS.

Accountable User.

The set of access control rules associated with this reservation.

The number of allocated nodes for this reservation.

The nodes allocated to the reservation.

The number of allocated processors.

The number of allocated tasks.

Reservation's comments or description.

Creation date. Automatically set by Moab when a user creates the reservation.

The duration of the reservation (in seconds).

The end date of the reservation. This is especially useful for one-time reservations, which have an exact time for when a reservation ends.

The list of jobs to exclude. Client must also set the IGNJOBRSV reservation flag. Otherwise, results are undefined. Used only during reservation creation.

The date/time when the reservation expires and vacates.

The flags associated with the reservation.

Global reservation ID.

The list of nodes a user can select to reserve. This may or may not be the nodes that are currently allocated to this reservation. Note: Either hostListExpression or taskCount must be set to create a reservation.

The user-specified prefix for this reservation. If provided, Moab combines the idPrefix with an integer, and the combination is the unique identifier for this reservation.

State whether or not this reservation is currently active.

States whether reservation resource usage is tracked.

When a label is assigned to a reservation, the reservation can then be referenced by that label as well as by the reservation name.

The maximum number of tasks for this reservation.

Messages for the reservation.

The owner of the reservation

The ID of the partition this reservation is for.

The profile that this reservation is using. A profile is a specification of attributes that all reservations share. Used only during reservation creation.

The reservation's requirements.

The reservation group to which the reservation belongs.

The reservation's resources. This field is a map, where the key is PROCS, MEM DISK, SWAP, or one or more user-defined keys.

The start time for the reservation. This is especially useful for one-time reservations, which have an exact time for when a reservation starts.

The reservation's statistical information.

The reservation sub-type.

The number of tasks that must be allocated to satisfy the reservation request. Note: Either hostListExpression or taskCount must be set to create a reservation.

Trigger for reservation. Used only during reservation creation.

The IDs of the triggers attached to this reservation.

The globally-unique reservation index.

The set of variables for this reservation.

The id of the object.

The author of the message.

The time the message was created in epoch time.

The time the message will be deleted in epoch time.

The index of the message relative to other messages in Moab's memory.

The comment information itself.

The number of times this message has been displayed.

An optional priority that can be attached to the comment.

Required architecture.

The list of features required for this reservation.

Required feature mode.

Required node memory, in MB.

Required number of nodes.

The list of node IDs required for this reservation.

Required Operating System.

Required task count.

The current active processor-seconds in the last reported iteration.

The current idle processor-seconds in the last reported iteration.

The total active processor-seconds over the life of the reservation.

The total idle processor-seconds over the life of the reservation.

Trigger id - internal ID used by moab to track triggers

For exec atype triggers, signifies executable and arguments. For jobpreempt atype triggers, signifies PREEMPTPOLICY to apply to jobs that are running on allocated resources. For changeparam atype triggers, specifies the parameter to change and its new value (using the same syntax and behavior as the changeparam command).

Time (in seconds) Moab will suspend normal operation to wait for trigger execution to finish. Use caution as Moab will completely stop normal operation until BlockTime expires.

Time at which trigger should be terminated if it has not already been activated.

Specifies the time (in seconds) that the threshold condition must exist before the trigger fires.

When used in conjunction with MultiFire and RearmTime trigger will fire at regular intervals. Can be used with TriggerEventType.EPOCH to create a Standing Trigger.
Defaults to false

Specifies the number of times Action will be attempted before the trigger is designated a failure.

Specifies whether this trigger can fire multiple times. Defaults to false.

Trigger name - can be auto assigned by moab or requested. Alphanumeric up to 16 characters in length

The ID of the object which this is attached to.

The type of object which this is attached to. Possible values:

• vm - Virtual Machine

Relative time offset from event when trigger can fire.

Can be used in conjunction with Offset to have a trigger fire at the beginning of the specified period. Can be used with EType epoch to create a standing trigger.

Time between MultiFire triggers; rearm time is enforced from the trigger event time.

Variables this trigger requires to be set or not set before it will fire. Preceding the string with an exclamation mark (!) indicates this variable must NOT be set. Used in conjunction with Sets to create trigger dependencies.

Variable values this trigger sets upon success or failure. Preceding the string with an exclamation mark (!) indicates this variable is set upon trigger failure. Preceding the string with a caret (^) indicates this variable is to be exported to the parent object when the current object is destroyed through a completion event. Used in conjunction with Requires to create trigger dependencies.

Reservation usage threshold - When reservation usage drops below Threshold, trigger will fire.
Threshold usage support is only enabled for reservations and applies to percent processor utilization. gmetric thresholds are supported with job, node, credential, and reservation triggers. See Threshold Triggers in the Moab Workload Manager documentation for more information.

Time allotted to this trigger before it is marked as unsuccessful and its process (if any) killed.

Variable this trigger destroys upon success or failure.

NOTE: A timed-out trigger will only receive one kill signal. This means that if you specify this flag, a timed-out trigger will only receive the SIGTERM signal, and never the SIGKILL signal.

Trigger id - internal ID used by moab to track triggers

For exec atype triggers, signifies executable and arguments. For jobpreempt atype triggers, signifies PREEMPTPOLICY to apply to jobs that are running on allocated resources. For changeparam atype triggers, specifies the parameter to change and its new value (using the same syntax and behavior as the changeparam command).

Time (in seconds) Moab will suspend normal operation to wait for trigger execution to finish. Use caution as Moab will completely stop normal operation until BlockTime expires.

Time at which trigger should be terminated if it has not already been activated.

Specifies the time (in seconds) that the threshold condition must exist before the trigger fires.

When used in conjunction with MultiFire and RearmTime trigger will fire at regular intervals. Can be used with TriggerEventType.EPOCH to create a Standing Trigger.
Defaults to false

Specifies the number of times Action will be attempted before the trigger is designated a failure.

Specifies whether this trigger can fire multiple times. Defaults to false.

Trigger name - can be auto assigned by moab or requested. Alphanumeric up to 16 characters in length

The ID of the object which this is attached to.

The type of object which this is attached to. Possible values:

• vm - Virtual Machine

Relative time offset from event when trigger can fire.

Can be used in conjunction with Offset to have a trigger fire at the beginning of the specified period. Can be used with EType epoch to create a standing trigger.

Time between MultiFire triggers; rearm time is enforced from the trigger event time.

Variables this trigger requires to be set or not set before it will fire. Preceding the string with an exclamation mark (!) indicates this variable must NOT be set. Used in conjunction with Sets to create trigger dependencies.

Variable values this trigger sets upon success or failure. Preceding the string with an exclamation mark (!) indicates this variable is set upon trigger failure. Preceding the string with a caret (^) indicates this variable is to be exported to the parent object when the current object is destroyed through a completion event. Used in conjunction with Requires to create trigger dependencies.

Reservation usage threshold - When reservation usage drops below Threshold, trigger will fire.
Threshold usage support is only enabled for reservations and applies to percent processor utilization. gmetric thresholds are supported with job, node, credential, and reservation triggers. See Threshold Triggers in the Moab Workload Manager documentation for more information.

Time allotted to this trigger before it is marked as unsuccessful and its process (if any) killed.

Variable this trigger destroys upon success or failure.