### Navigation

- index
- next |
- previous |
- reclass »

# reclass concepts

reclass assumes a node-centric perspective into your inventory. This is obvious when you query reclass for node-specific information, but it might not be clear when you ask reclass to provide you with a list of groups. In that case, reclass loops over all nodes it can find in its database, reads all information it can find about the nodes, and finally reorders the result to provide a list of groups with the nodes they contain.

Since the term “groups” is somewhat ambiguous, it helps to start off with a short glossary of reclass-specific terminology:

Concept | Description
--- | ---
node | A node, usually a computer in your infrastructure
class | A category, tag, feature, or role that applies to a node Classes may be nested, i.e. there can be a class hierarchy
application | A specific set of behaviour to apply
parameter | Node-specific variables, with inheritance throughout the class hierarchy.

A class consists of zero or more parent classes, zero or more applications, and any number of parameters.

A class name must not contain spaces.

A node is almost equivalent to a class, except that it usually does not (but can) specify applications.

When reclass parses a node (or class) definition and encounters a parent class, it recurses to this parent class first before reading any data of the node (or class). When reclass returns from the recursive, depth first walk, it then merges all information of the current node (or class) into the information it obtained during the recursion.

Furthermore, a node (or class) may define a list of classes it derives from, in which case classes defined further down the list will be able to override classes further up the list.

Information in this context is essentially one of a list of applications or a list of parameters.

The interaction between the depth-first walk and the delayed merging of data means that the node (and any class) may override any of the data defined by any of the parent classes (ancestors). This is in line with the assumption that more specific definitions (“this specific host”) should have a higher precedence than more general definitions (“all webservers”, which includes all webservers in Munich, which includes “this specific host”, for example).

Here’s a quick example, showing how parameters accumulate and can get replaced.

> All “unixnodes” (i.e. nodes who have the `unixnode` class in their ancestry) have `/etc/motd` centrally-managed (through the `motd` application), and the unixnode class definition provides a generic message-of-the-day to be put into this file.

> All descendants of the class `debiannode`, a descendant of `unixnode`, should include the Debian codename in this message, so the message-of-the-day is overwritten in the `debiannodes` class.

> The node `quantum.example.org` (a debiannode) will have a scheduled downtime this weekend, so until Monday, an appropriate message-of-the-day is added to the node definition.

> When the `motd` application runs, it receives the appropriate message-of-the-day (from `quantum.example.org` when run on that node) and writes it into `/etc/motd`.

At this point it should be noted that parameters whose values are lists or key-value pairs don’t get overwritten by children classes or node definitions, but the information gets merged (recursively) instead.

Similarly to parameters, applications also accumulate during the recursive walk through the class ancestry. It is possible for a node or child class to remove an application added by a parent class, by prefixing the application with ~.

Finally, reclass happily lets you use multiple inheritance, and ensures that the resolution of parameters is still well-defined. Here’s another example building upon the one about `/etc/motd` above:

> `quantum.example.org` (which is back up and therefore its node definition no longer contains a message-of-the-day) is at a site in Munich. Therefore, it is a child of the class `hosted@munich`. This class is independent of the `unixnode` hierarchy, `quantum.example.org` derives from both.

> In this example infrastructure, `hosted@munich` is more specific than `debiannode` because there are plenty of Debian nodes at other sites (and some non-Debian nodes in Munich). Therefore, `quantum.example.org` derives from `hosted@munich` _after_ `debiannodes`.

> When an electricity outage is expected over the weekend in Munich, the admin can change the message-of-the-day in the `hosted@munich` class, and it will apply to all hosts in Munich.

> However, not all hosts in Munich have `/etc/motd`, because some of them are of class `windowsnode`. Since the `windowsnode` ancestry does not specify the `motd` application, those hosts have access to the message-of-the-day in the node variables, but the message won’t get used…

> … unless, of course, `windowsnode` specified a Windows-specific application to bring such notices to the attention of the user.

It’s also trivial to ensure a certain order of class evaluation. Here’s another example:

> The `ssh.server` class defines the `permit_root_login` parameter to `no`.

> The `backuppc.client` class defines the parameter to `without-password`, because the BackupPC server might need to log in to the host as root.

> Now, what happens if the admin accidentally provides the following two classes?

> - `backuppc.client`
> - `ssh.server`

> Theoretically, this would mean `permit_root_login` gets set to `no`.

> However, since all `backuppc.client` nodes need `ssh.server` (at least in most setups), the class `backuppc.client` itself derives from `ssh.server`, ensuring that it gets parsed before `backuppc.client`.

> When reclass returns to the node and encounters the `ssh.server` class defined there, it simply skips it, as it’s already been processed.

Now read about reclass operations!

### Navigation

- index
- next |
- previous |
- reclass »