This section explains how to define the appropriate mshow -a command during the create VPC process. In order to get the VPC transaction, there needs to be a valid mshow -a command, which is the Moab command that Viewpoint runs to submit requests. You can configure the command according to your specific needs.

This section is evaluated when the user attempts to verify their current VPC request. When the user is finished configuring their VPC requirements with the resources they want, they verify the availability using an mshow request, which is defined in this section.

Viewpoint always uses the following arguments for any mshow:

• -a (Show Available)
• -i (Intersection)
• -o (Do not aggregate)

Additionally, the following flags are always used (using --flags):

• tid
• summary

The following are optional arguments and flags that Viewpoint supports:

• -p (Profile) - A profile is specified using the <profile> element. The value for this element can be any string decider.
• policy (Flag) - The policy flag can be enabled using the <show-policy> element. The value for this element can be any boolean decider.
• future (Flag) - The future flag can be enabled using the <show-future> element. The value for this element can be any boolean decider.
• -x (Exclusive) - This states if the individual requirements should be exclusive. The value for this element can be any boolean decider and the default value is true. This flag can be configured using the <exclusive> element.

5.1.3.2.1 Requirements

The <request> element can support any number of <requirement> child elements. In order for the mshow command to be meaningful, you should have at least one <requirement> element. This element defines one or more where clauses. These where clauses make up the majority of any mshow command and they specify the resources for each desired reservation on the VPC.

The <requirement> elements are directly related to the information stored in the <requirement-data> element in the user's request queue. Viewpoint asks Moab for the resources the user specified in their current request queue.

There are three types of <requirement> elements. Each <requirement> element must have an attribute type with one of these values:

• "static" - This requirement creates exactly one where clause to be added to the mshow request. It does not use any data from any queue item.
• "dynamic" - This requirement creates as many where clauses as the number of items in the queue. If the user has three items in their current request queue, this single <requirement> element is duplicated three times; once for each item in the queue. Any components listed as children in the value deciders first tries to find the component values from the queue data. If the component value was not stored in the queue data, it looks for the values in the components themselves.
• "single-dynamic" - This requirement creates exacty one where clause to be added to the mshow request, but before evaluating the values of components, it sums up all values in the queue. In other words, all the values are summed up before any "value deciding" is done. For example, if there are three VMs in the queue (each with 2GB of RAM), a "single-dynamic" requirement requests 6GB RAM, since it adds up all the values in the queue to get the total value. This is useful in the case of generic resources, since Moab requires that a generic resource on the GLOBAL node be requested on a separate where clause.

Currently, the "single-dynamic" and "dynamic" requirements must have an id that This corresponds to the <requirement-data> element in the queue section. Verify the "single-dynamic" and "dynamic" requirements map to the appropriate queue item data.

Also, for any requirement, value deciders can use the keyword "queue-count" to get the number of items in the queue. This is useful if, in a value decider, you need to know the amount of reservations the user is requesting.

Here is an example:

<calculate binary-operation="multiply">
 <first>
  <component id="queue-count" />
 </first>
 <second>60</second>
</calculate>

Supported Attributes

The following are supported children elements of the <requirement> element. Each element listed below maps to a request attribute for a where clause. These elements accept either a boolean decider, a date decider, a duration decider, an integer decider, or a string decider.

• <account> - This corresponds to the account attribute and accepts any string decider.
• <disk> - This corresponds to the mintasks attribute specifying the disk for the task and accepts any integer decider.
• <duration> - This corresponds to the duration attribute and accepts any duration decider.
• <generic-resource> - This corresponds to the gres attribute and requires two child elements:
  • <name> The name of the generic resource to request (a string decider).
  • <amount> The quantity of the generic resource to request (an integer decider).
• <group> - This corresponds to the group attribute and accepts any string decider.
• <memory> - This corresponds to the mintasks attribute specifying the memory for the task and accepts any integer decider.
• <min-nodes> - This corresponds to the minnodes attribute and accepts any integer decider.
• <min-procs> - This corresponds to the minprocs attribute and accepts any integer decider.
• <node-access-policy> - This corresponds to the nodeaccesspolicy attribute and accepts any string decider.
• <node-feature> - This corresponds to the nodefeature attribute and accepts any string decider.
• <os> - This corresponds to the os attribute and accepts any string value decider.
• <rsv-profile> - This corresponds to the rsvprofile attribute and accepts any string value decider.
• <start-time> - This corresponds to the starttime attribute and accepts any date decider.
• <task-count> - This corresponds to the mintasks attribute specifying the number of tasks and accepts any integer decider.
• <variables> - This corresponds to the variables attribute. This can have one or more <variable> child elements. Each child <variable> element has three parts:
  • <key> (Required) - The name of the variable and accepts any string decider.
  • <value> (Required) - The value of the variable and accepts any string decider.
  • <rule> (Optional) - Accepts any boolean decider. If this is specified, Viewpoint includes the variable only if the rule evaluates to true.