Moab Viewpoint
Home Up Previous Next
Filtering Results

Filtering Results

Results Filter

Near the top of certain pages such as Job Management, Reservation Management and Node Management pages is a text area, a Submit Filter button, a Remove Filter button, and a Help button. This functionality allows you to filter the results on these pages to your liking. Filters are of the format, name:value. Multiple filters are allowed and are delimited by a space, such as, account:astrophysics user:mike. All entered name-value pairs are used to obtain the filter results. These are the components of the filter mechanism:

  • Filter Text Area - The text area accepts any text input. If the beginning of one of the valid filter keywords is being typed, an auto-complete dropdown appears. Clicking, or selecting and pressing [Enter], on a desired keyword completes the word and adds the required colon at the end.
  • Submit Filter Button searchbuttonp.gif - Clicking this button applies the filter that is currently in the text area.
  • Remove Filter Button removefiltersbutton.gif - Clicking this button removes all filters and displays the page with no filters applied.
  • Help Button helpbutton.gif - Clicking this button displays help and tips related to filtering.

For any field configured in the management framework, you can specify a filter sub-element like so:

<fieldX>      
    <title>Data</title>      
    <filter text="data" enabled="true">          
        <suggestions>data1, data2, data3<suggestions>      
    </filter>  
</fieldX>

This will configure the <fieldX> field to have a column title of "Data", be filterable by using a "data:" operator, and give "data1", "data2", and "data3" as suggestions.

Note You can only filter on columns that have been configured in the table.

Filter Keywords

There are different, valid keywords for each page that supports filtering.

Keywords for Job Management Filtering

  • account - The account that this job is to run under for billing purposes.
  • drmjid - The destination resource manager job ID.
  • expected-state - The expected state of the job based on scheduler action.
  • flags - Allows filtering based on flags applied to a job. For more information on specific flags, see Job Attributes/Flags Overview.
  • holds - The types of holds that are currently on the job.
  • group - The group the job is run under.
  • id - The unique ID of the job.
  • name - The user specified name of the job.
  • memory-requested - The amount of memory in MB requested by the job.
  • proc-count - The number of processors the job requires.
  • qos - The QoS the job is actually running under.
  • run-priority - The priority to start running the job.
  • start-priority - The effective job priority level.
  • user - The user running the job.
  • wallclock-requested - The wallclock the job requested in seconds.

Keywords for Node Management Filtering

Numeric Filters

  • disk-available - This filters nodes based on their available disk.
  • disk-total - This filters nodes based on total or configured disk.
  • disk-utilized - This filters nodes based on their currently utilized disk.
  • load - This filters nodes based on their current load.
  • memory-available - This filters nodes based on their available memory.
  • memory-total - This filters nodes based on their total memory.
  • memory-utilized - This filters nodes based on their currently utilized memory.
  • processors-available - This filters nodes based on available processors.
  • processors-total - This filters nodes based on configured processors.
  • processors-utilized - This filters nodes based on their currently utilized processors.

These filters match anytime the specified filter value is contained in the reported value. Here are some examples:

  • The filter value 6 matches values of 6, 16, 61, and 123456789.
  • The filter value 0 does not match a value of 12.

String Filters

  • access-policy - This filters nodes based on their node access policy.
  • alias - The alias of the node as reported by Moab.
  • architecture - This filters nodes based on their architecture value reported by Moab.
  • features - This filters nodes based on their feature list. The filter value must exactly match at least one feature in a node's feature list to match.
  • hypervisor-type - This filters nodes based on their hypervisor type.
  • id - This filters nodes based on their names.
  • ip-address - This filters nodes based on their current IP address.
  • os - This filters nodes based on their operating system.
  • power - This filters nodes based on their power status.
  • power-policy - This filters nodes based on their power policy.
  • priority - This filters nodes based on their numeric priority value.
  • state - This filters nodes based on their current state.
  • substate - This filters nodes based on the substate of a node.
  • vlans - This filters nodes based on their VLAN list. The filter value must exactly match at least one VLAN in a node's VLAN list to match.

These filters match anytime the filter value is equal to, or if the reported value contains, the filter value. The filter is case insensitive. Here are some examples:

  • The filter value n1 matches N1, n10, n123, fan1, and FAN12.
  • The filter value n1 does not match n21.

Keywords for Pending Actions Filtering

  • id - The ID of the pending action that you wish to view.
  • type - The type of pending actions you wish to view.
  • status - The state of the pending actions you wish to view.
  • starttime - A period of time that has a start and an end. The format for a valid value for this keyword is described here.
  • requester - The user who performed this action.
  • nodeid - The ID given to the node the action is being performed upon.
  • targetos - The operating system that is related to the Pending Action.
  • vmid - The ID given to the Virtual Machine to which the Pending Action is related.
  • migrationsource - The source node of the Virtual Machine being migrated.
  • migrationdestination - The destination node of the Virtual Machine being migrated.
  • substatus - The sub-status of the Pending Action you wish to view.

Syntax for Time Period Keywords

Date

The syntax for a date is mm/dd/yyyy or mm/dd. An example of March 31, 2010 is 5/31/2010.

  • day (dd or d) - An integer from 1 through 31.
  • month (mm or m) - An integer from 1 through 12.
  • year (yy or yyyy) - An integer.

Time

The syntax for time is hh:mm, hh:mm:ss, kk:mm, or kk:mm:ss. In all cases where hh, or h, is used for the hour element, the last element in the sequence must be an am | pm element. An example of a valid time input is 11:30:00am.

  • hour (hh, h, or kk) - The hh, or h, value is an integer from 1 through 12. The kk value is a an integer from 00 through 23. When h, or hh, is used, the time statement must be followed by "am" or "pm" (see below).
  • minutes (mm) - An integer from 00 through 60.
  • seconds (ss) - An integer from 00 through 60.
  • am | pm ("am" or "pm") - This is used only when h, or hh, is used for the hour value.

Full Date and Time

  • date@time - When only a date is provided, the time is set for the earliest time of that day. When only time is provided, the date is set for the current day.

Hyphen

The hyphen is interpreted as a wildcard.

  • date@time- - Everything from the given date@time to infinity is filtered. 5/31/2010@11:30am- filters everything from 11:30am on March 31st, 2010, to infinity.
  • date@time-date@time - Everything between the specified date@time pairs is filtered.
  • -date@time - Everything from now to the specified date and time is filtered.
Examples
  • 12/12/10-12/12/2011 - This indicates from December 12th, 2010 to December 12th, 2011.
  • 12/12/2010@7:00am-12/12/2011@9:00pm - This indicates from December 12th, 2010 at 7:00 AM to December 12th, 2011 at 9:00 PM.
  • 12/12/2010@7:00-12/12/2011@21:00 - This indicates from December 12th, 2010 at 7:00 AM to December 12th, 2011 at 9:00 PM.
  • 12/02/2010- - This indicates from December 2nd, 2010 at 12:00 AM to infinity.
  • -12/2/10 - This indicates from now to December 2nd, 2010.

Home Up Previous Next