GRIS: Implementation/Adding New Providers

Note: This document is in rough draft form

The MDS 2.1 resource information models the physical and logical components of a compute resource as a hierarchy of elements. There are only a small number of elemental types, corresponding to LDAP structural objectclasses and representing little more than their names:

class MdsVo
contains attr Mds-Vo-name

class MdsHost
contains attr Mds-Host-hn

class MdsDevice
contains attr Mds-Device-name

class MdsDeviceGroup
contains attr Mds-Device-Group-name

...

A complementary set of "auxiliary" types adds information about the particular elemental instances. The LDAP auxiliary types are special in that they can be added to a structurally typed object to extend it with more information. The MDS 2.1 information model uses this feature to merge information "upward" in the object tree---while a leaf node may contain information about a single resource instance, a parent node may contain the merged information about several instances:

    dn: Mds-Device-Group-name=memory, ...
    objectclass: MdsMemoryRamTotal
    objectclass: MdsMemoryVmTotal
    objectclass: MdsDeviceGroup
    Mds-Device-Group-name: memory
    Mds-validfrom: 200110030128.12Z
    Mds-validto: 200110030128.12Z
    Mds-keepto: 200110030128.12Z
    Mds-Memory-Ram-Total-sizeMB: 751
    Mds-Memory-Ram-Total-freeMB: 642
    Mds-Memory-Vm-Total-sizeMB: 1600
    Mds-Memory-Vm-Total-freeMB: 1592
    Mds-Memory-Ram-sizeMB: 751
    Mds-Memory-Ram-freeMB: 642
    Mds-Memory-Vm-sizeMB: 1600
    Mds-Memory-Vm-freeMB: 1592

dn: Mds-Device-name=physical memory, Mds-Device-Group-name=memory, ...

    objectclass: Mds
    objectclass: MdsDevice
    objectclass: MdsMemoryRam
    Mds-Device-name: physical memory
    Mds-Memory-Ram-sizeMB: 751
    Mds-Memory-Ram-freeMB: 642
    Mds-validfrom: 200110030128.12Z
    Mds-validto: 200110030128.12Z
    Mds-keepto: 200110030128.12Z

dn: Mds-Device-name=virtual memory, Mds-Device-Group-name=memory, ...

    objectclass: Mds
  objectclass: MdsDevice
    objectclass: MdsMemoryVm
    Mds-Device-name: virtual memory
    Mds-Memory-Vm-sizeMB: 1600
    Mds-Memory-Vm-freeMB: 1592
    Mds-validfrom: 200110030128.12Z
    Mds-validto: 200110030128.12Z
    Mds-keepto: 200110030128.12Z

This ability to merge multiple types allows the parent object to reflect the different types of each children, and therefore contain data from both of them.

The GRIS service provides a hierarchy of such objects for an SMP compute resource, merging data upward to the "host object" which contains all information about the host. This merged object is convenient for search filters expressing constraints on multiple data, but it loses some information due to the LDAP data model's inability to distinguish instances of a particular attribute value. For example, if a large SMP had 2 CPUs with speed X, and one CPU with speed Y, the host object would only represent that there is at least one CPU of each speed. One would have to visit the underlying CPU device objects to determine how many (or which) CPUs have a particular speed value.

The default MDS 2.1 GRIS providers create a hierarchy with the following structure:

/ | | \ \

processors memory filesystems networks OS

/ \ / \ / \ / \

cpu 0 ... RAM VM /dev0 ... iface ...

Where the well-known MdsDeviceGroup object names "processors", "memory", "filesystems", and "networks" act as collection points for the instances of devices in those categories. The well-known MdsSoftwareDeployment name "operating system" references information about the booted operating system software on the resource.

The schema design includes support for clusters of SMPs, i.e. typical distributed memory processors, via other compute elements such as MdsHostNetnode and MdsHostNode to represent networked (or hidden) elements of a cluster, each of which may be an SMP resource. However, the default providers with MDS 2.1 do not include the platform-specific probes necessary to efficiently extract information from such systems.

An index of schema definitions and descriptions of object classes and attribute types can be found in MDS Schemas.

Creating Platform-specific Core GRIS Providers

There could be a mechanism-specific variant for each:

grid-info-cpu-<method>
grid-info-mem-<method>
grid-info-net-<method>
grid-info-fs-<method>

For a totally esoteric platform which doesn't even have uptime and uname functionality, we might have to introduce variants

grid-info-platform-<method>
grid-info-cpufast-<method>

<method> should uniquely refer to how the information is acquired. In all the existing cases, we have methods named either after a common mechanism or the platform for which they've been completely tailored:

linux
irix
solaris
uname
posix
netstat
uptime

The *-common scripts contain the generic code that is used by all platforms. They would NEVER be modified for a new platform. They correspond to the structure of the schema. Each mechanism-variant probe script basically does some mechanism-specific activity which initializes a shell variable environment in which the generic code can be executed to output the actual LDAP objects. The common code defines the particular variables that may be set by a probe to pass information for the standardized LDAP values. For example, the cpu common script looks for these variables:

### variables used to store probed data
# _cpu_N_vendor=name
# _cpu_N_model=name
# _cpu_N_version=name
# _cpu_N_features=name
# _cpu_N_speed_mhertz=number
# _cpu_N_l2cache_kbytes=number
# _cpu_free1X100=number
# _cpu_free5X100=number
# _cpu_free15X100=number
# _cpu_count=0

When a probe detects CPUs, it sets the _cpu_count value to the number, e.g. "2" on crater. Then it sets the cpu_N_* values for each CPU individually, e.g. on crater:
_cpu_0_speed=1700
_cpu_1_speed=1700

This allows the individual probed devices to have distinct probed properties.

This is not well documented so anyone trying to work on these should definitely correspond over an appropriate MDS developers mailing list.

Creating Custom GRIS Providers

You can create your own information providers by following the procedures described in MDS GRIS Specification Document: Creating New Information Providers (PDF).