Node Attributes

The names and uses of the fields associated with each database object are fixed, although nodes may be augmented with attribute lists for more flexible management. These attribute lists are stored in the attributes field of a node and consist of names (ideally legal Javascript variable names) and textual values. Attribute names prefixed with an underscore such as _boot_config or _boot_style are reserved for use by the ICE ClusterWare™ platform. These attributes may be referenced or modified by administrator defined scripting, but changing their values will modify the behavior of the ClusterWare platform.

Beyond their internal use, e.g. for controlling boot details, attributes are intended for use by cluster administrators to mark nodes for specific purposes, record important hardware and networking details, record physical rack locations, or whatever else the administrator may find useful. All attributes for a given node are available and periodically updated on the node in file /opt/scyld/clusterware-node/etc/attributes.ini. This directory /opt/scyld/clusterware-node/etc/ is also symlinked to /etc/clusterware.

Attributes can also be collected together into attribute groups that are stored separately from the node database objects. Administrators can then assign nodes to these groups and thereby change the attributes for a selection of nodes all at once.

Each node has a list of groups to which it belongs, and the order of this list is important. Attribute groups appearing later in the list can override attributes provided by groups earlier in the list. For any given node there are two special groups: the global default group and the node-specific group. The global default group, which is defined during the installation process and initially named "DefaultAttribs", is always applied first, and the node-specific group contained in the node database object is always applied last. Any attribute group can be assigned to be the default group through the scyld-clusterctl command, e.g.,

scyld-clusterctl --set-group GroupNameOrUID

An example should clarify how attributes are determined for a node. Immediately after installation the "DefaultAttribs" group contains a single value:

[example@head ~]$ scyld-attribctl ls -l
Attribute Groups
  DefaultAttribs
    attributes
      _boot_config: DefaultBoot

Note that fields extraneous to this example have been trimmed from this output. Looking at two nodes on this same cluster:

[example@head ~]$ scyld-nodectl ls -l
Nodes
  n0
    attributes:
      _boot_config: DefaultBoot
    groups: []

  n1
    attributes:
      _boot_config: DefaultBoot
    groups: []

By default no attributes are defined at the node level, although all nodes inherit the _boot_config value from the "DefaultAttribs" group. If an administrator creates a new boot configuration (possibly by using the scyld-add-boot-config script mentioned earlier) and calls it "AlternateBoot", then she could assign a single node to that configuration using the scyld-nodectl tool, e.g.,

scyld-nodectl -i n0 set _boot_config=AlternateBoot

Examining the same nodes after this change would show:

[example@head ~]$ scyld-nodectl ls -l
Nodes
  n0
    attributes:
      _boot_config: AlternateBoot
    groups: []

  n1
    attributes:
      _boot_config: DefaultBoot
    groups: []

Of course, managing nodes by changing their individual attributes on a per-node basis is cumbersome in larger clusters, so a savvy administrator can create a group and assign nodes to that group:

scyld-attribctl create name=AltAttribs
scyld-attribctl -i AltAttribs set _boot_config=ThirdBoot

Assigning additional nodes to that group is done by "joining" them to the attribute group:

scyld-nodectl -i n[11-20] join AltAttribs

After the above changes, node n0 is assigned to the "AlternateBoot" configuration, n11 through n20 would boot using the "ThirdBoot" configuration, and any other nodes in the system will continue to use "DefaultBoot". This approach allows administrators to efficiently aggregate a set of nodes in anticipation of an action against the entire set, for example when testing new images, or if some nodes need specific configuration differences due to hardware differences such as containing GPU hardware.

For a more technical discussion of setting and clearing attributes as well as nodes joining and leaving groups, see Attribute Groups and Dynamic Groups, scyld-attribctl, and scyld-nodectl.