Rethinking Node Classification

This feature spawned from discussion on the mailing list, but it's moved on since then.

Introduction

The current parsing process should be split into three stand-alone processes: Collecting information from the client, determining which classes the client is a member of, and compiling those classes.

Client Information

Inputs:	Name/value data pairs and a node name.
Outputs:	An API and CLI tools for retrieving that information.

The client is actually responsible for passing in everything it knows about itself, still using Facter. The only real difference here is that the information would be cached; the caching should be abstracted so it can have multiple back-ends, but the initial back-end would likely just be flat files using YAML.

This feature would need a separate interface, so people could interact with this client information -- at the least, retrieving all facts for a given client from the command line, and probably listing all clients, and maybe the last update time for the client.

Node Classification

Inputs:	Client information (using the above API).
Outputs:	Client class membership and any new client variables, using an API or CLI tools. Also, should be able to list which hosts are a member of a given class.

A naming thread was spawned discussing this specific tool; for now, we will code-name it kinial.

This tool would have a small, simple boolean language for determining class membership and capable of setting variables.

Because many classes have variables associated with them, this tool needs to be able to output variables in addition to the class memberships.

Note that this tool, also, caches this information, again preferably using an abstract API, so that the parser can retrieve it but also so other tools can get to it.

Kinial's Language

There are some critical features that the language should have, in order to best model the problem of node classification:

• Enabling and disabling boolean classes
• Using, setting and clearing of attributes by class
• Equality and regular expression matching against attributes to determine class membership
• Testing whether a given class is set
• Specification of class enumerations, such as all possible data centers, operating systems, or SLA levels, along with the ability to specify that a given enumeration is required for all nodes (e.g., all nodes must have an operating system class set). This could possibly be done with inheritance -- define a base class, define subclasses, and require that all nodes be a member of one of the subclasses. This should most likely define an attribute, named for the base class, with the value being the enabled subclass.
• Special-casing of an 'environment' class (naming can change), such that all nodes are always required to have one

Parsing Changes

The parsing should be broken up. The 'Master' handler should be changed to call three tools in succession: The client information storage tool, then the node classification tool, then the parser. No data will be passed directly from these tools; instead, each will know how to make the right API calls to get the data it needs.

Conclusion

None of these steps is particularly difficult, possibly apart from the new language for the node classification tool, but it should provide significant new functionality, including making it easy for other tools to take advantage of the centralized Fact and classification storage.