Appendices > Appendix S: Scalable Systems Software Specification > Node Object Specification

Conventions

Scalable Systems Software Node Object Specification

SSS Node Object Specification
Release Version 3.1.0
26 April 2011

Scott Jackson, PNNL
David Jackson, Ames Lab
Brett Bode, Ames Lab

Status of This Memo

This is a specification of the node object to be used by Scalable Systems Software compliant components. It is envisioned for this specification to be used in conjunction with the SSSRMAP protocol with the node object passed in the Data field of Requests and Responses. Queries can be issued to a node-cognizant component in the form of modified XPATH expressions to the Get field to extract specific information from the node object as described in the SSSRMAP protocol.

Abstract

This document describes the syntax and structure of the SSS node object. This node model takes into account various node property categories such as whether it represents a configured, available or utilized property.

Table of Contents

1.0 Introduction

This specification proposes a standard XML representation for a node object for use by the various components in the SSS Resource Management System. This object will be used in multiple contexts and by multiple components. It is anticipated that this object will be passed via the Data Element of SSSRMAP Requests and Responses.

1.1 Goals

There are several goals motivating the design of this representation.

It needs to be inherently flexible. We recognize we will not be able to exhaustively include the ever-changing node properties and capabilities that constantly arise.

The same node object should be used at all stages of its lifecycle. This object needs to distinguish between configured, available and utilized properties of a node.

Its design takes into account the properties and structure required to function in a meta environment. It should eventually include the capability of resolving name space and locality issues, though the earliest versions will ignore this requirement.

One should not have to make multiple queries to obtain a single piece of information — i.e. there should not be two mutually exclusive ways to represent a node resource.

Needs to support resource metric as well as unit specifications.

1.2 Examples

Simple Example

This example shows a simple expression of the Node object.

<Node>
  <Id>Node64</Id>
  <Configured>
    <Processors>2</Processors>
    <Memory>512</Memory>
  </Configured>
</Node>

Elaborate Example

This example shows a more elaborate Node object.

<Node>
  <Id>64</Id>
  <Name>Netpipe2</Name>
  <Feature>BigMem</Feature>
  <Feature>NetOC12</Feature>
  <Opsys>AIX</Opsys>
  <Arch>Power4</Arch>
  <Configured>
    <Processors>16</Processors>
    <Memory units=”MB”>512</Memory>
    <Swap>512</Swap>
  </Configured>
  <Available>
    <Processors>7</Processors>
    <Memory metric=”Instantaneous”>143</Memory>
  </Available>
  <Utilized>
    <Processors wallDuration=”3576”>8</Processors>
    <Memory metric=”Average” wallDuration=”3576”>400</Memory>
  </Utilized>
</Node>

2.0 Conventions Used in This Document

2.1 Keywords

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC2119.

2.2 Table Column Interpretations

In the property tables, the columns are interpreted to have the following meanings:

Property Description
Element Name Name of the XML element (xsd:element)
Type Data type defined by xsd (XML Schema Definition) as:
  • String — xsd:string(a finite length sequence of printable characters)
  • Integer — xsd:integer(a signed finite length sequence of decimal digits)
  • Float — xsd:float (single-precision 32-bit floating point)
  • Boolean — xsd:boolean (consists of the literals “true” or “false”)
  • DateTime — xsd:dateTime (discreet time values are represented in ISO 8601 extended format CCYY-MM-DDThh:mm:ss where CC represents the century, YY the year, MM the month and DD the day. The letter T is the date/time separator and hh, mm, ss represent hour, minute and second respectively. This representation may be immediately followed by a Z to indicate Coordinated Universal Time (UTC) or, to indicate the time zone, i.e. the difference between the local time and Coordinated Universal Time, immediately followed by a sign, + or -, followed by the difference from UTC.)
  • Duration — xsd:duration (a duration of time is represented in ISO 8601 extended format PnYnMnDTnHnMnS, where nY represents the number of years, nM the number of months, nD the number of days, T is the date/time separator, nH the number of hours, nM the number of minutes and nS the number of seconds. The number of seconds can include decimal digits to arbitrary precision.)
Description Brief description of the meaning of the property
Appearance This column indicates whether the given property has to appear within the parent element. It assumes the following meanings:
  • MUST — This property is REQUIRED when the parent is specified.
  • SHOULD — A compliant implementation SHOULD support this property.
  • MAY — A compliant implementation MAY support this property.
Compliance The column indicates whether a compliant implementation has to support the given property.
  • MUST — A compliant implementation MUST support this property.
  • SHOULD — A compliant implementation SHOULD support this property.
  • MAY — A compliant implementation MAY support this property.
Categories Some properties may be categorized into one of several categories. Letters in this column indicate that the given property can be classified in the following property categories.
  • C — This property can be encompassed in a Configured element.
  • A — This property can be encompassed in an Available element.
  • U — This property can be encompassed in a Utilized element.

2.3 Element Syntax Cardinality

The cardinality of elements in the element syntax sections may make use of regular expression wildcards with the following meanings:

Wildcard Description
* Zero or more occurrences
+ One or more occurrences
? Zero or one occurrences

The absence of one of these symbols implies one and only one occurrence.

3.0 The Node Model

The primary element within the node model is a node. One can speak of some node properties as being a configured, available or utilized property of the node.

4.0 Node Element

The Node element is the root element of a node object and is used to encapsulate a node.

4.1 Uncategorized Node Properties

Uncategorized Node Properties are properties that apply to the node as a whole and do not need to be distinguished between being configured, available or utilized. These include the node id and other optional node properties.

Simple Node Properties

Simple (unstructured) node properties are enumerated in the table below.

Table 25-7: Simple Node Properties

Element Name Type Description Appearance Compliance
Id String Node identifier MUST MUST

Name

String Node name or pattern MAY MAY
OpSys String Operating System MAY SHOULD
Arch String Architecture MAY SHOULD
Description String Description of the node MAY MAY
State String State of the node. Valid states may include Offline, Configured, Unknown, Idle, and Busy. SHOULD MUST
Features String Arbitrary named features of the node (comma-delimited string) MAY SHOULD

Extension Element

The Extension element provides a means to pass extensible properties with the node object. Some applications may find it easier to deal with a named extension property than discover and handle elements for which they do not understand or anticipate by name.

The following is an example of an Extension element:

<Extension type=”Chemistry” name=”Software”>NWChem</Extension>

4.2 Property Categories

Certain node properties (particularly consumable resources) need to be classified as being in a particular category. This is done when it is necessary to distinguish between a property that is configured versus a property that is available or utilized. For example, a node might be configured with 16 processors. At a particular time, 8 might be utilized, 7 might be available and 1 disabled. When a node property must be categorized to be understood properly, the property MUST be enveloped within the appropriate Property Category Element.

Configured Element

A configured node property reflects resources pertaining to the node that could in principle be used though they may not be available at this time. This information could be used to determine if a job could ever conceivably run on a given node.

The following is an example of using Configured Properties:

<Configured>
  <Processors>16</Processors>
  <Memory units=”MB”>512</Memory>
</Configured>

Available Element

An available node property refers to a resource that is currently available for use.

The following is an example of specifying available properties:

<Available>
  <Processors>7</Processors>
  <Memory units=”MB”>256</Memory>
</Available>

Utilized Element

A utilized node property reflects resources that are currently utilized.

The following is an example of specifying utilized properties:

<Utilized>
  <Processors>8</Processors>
  <Memory metric=”Average”>207</Memory>
</Utilized>

4.3 Categorized Node Properties

Consumable Resources

Consumable Resources are a special group of node properties that can have additional attributes and can be used in multiple categories. In general a consumable resource is a resource that can be consumed in a measurable quantity.

A list of simple consumable resources is listed in the table below.

Table 25-8: Consumable Resource Node Properties

Element Name Type Description Appearance Compliance Categories
Processors Integer Number of processors MAY MUST CAU
Memory Float Amount of memory MAY SHOULD CAU
Disk Float Amount of disk MAY SHOULD CAU
Swap Float Amount of virtual memory MAY MAY CAU
Network Float Amount of network MAY MAY CAU

The following are two examples for specifying a consumable resource:

<Memory metric=”Max” units=”GB”>483</Memory>
<Processors wallDuration=”1234” consumptionRate=”0.63”>4</Processors>

Resource Element

In addition to the consumable resources enumerated in the above table, an extensible consumable resource is defined by the Resource element.

The following are two examples for specifying a Resource element:

<Resource name=”License” type=”MATLAB”>1</Resource>
<Resource name=”Telescope” type=”Zoom2000” wallDuration=”750” metric=”KX”>10</Resource>

4.4 Node Reference

When a simple reference to a predefined node is needed in an encapsulating element, a Node element is used with the text content being the node id:

<Node>node1</Node>

The following is another example of a Node element:

<Node aggregation=”Pattern”>node[1-5]</Node>

Appendix A

Units of Measure Abbreviations

Abbreviation Definition Quantity
B byte 1 byte
KB Kilobyte 2^10 bytes
MB Megabyte 2^20 bytes
GB Gigabyte 2^30 bytes
TB Terabyte 2^40 bytes
PB Petabyte 2^50 bytes
EB Exabyte 2^60 bytes
ZB Aettabyte 2^70 bytes
YB Yottabyte 2^80 bytes
NB Nonabyte 2^90 bytes
DB Doggabyte 2^100 bytes