A Plan for the ROCKS Graph

ROCKS Graphs

ROCKS uses the Redhat Anaconda installer to do installs. Using the Anaconda installer provides many advantages:

• It is well tested and stable, in use for 10+ years by Redhat
• Open-source
• Handles many hardware issues automatically, allows abstraction of hardware types
  • more robust that an imaging installer
  • easier to manage than an imaging installer
• Extensible in Python
• Integrated with RHEL...

Automated Anaconda installs are driven by a script called the kickstart script. This script uses a syntax specific to Anaconda that is fairly simple but rich enough to handle any install cases, though kickstart scripts can get messy and hard to maintain. A kickstart script has the following parts:

• A main section that describes global config items such as partitioning, hostname, timezone, etc.
• A list of all the RPMs to install, Anaconda automatically installs dependencies (or the listed RPMS) as needed.
• Sections named "pre" and "post" that allow inclusion of arbitrary scripts (sh, python, perl) that will be run in the at the beginning and end of the installation process

As many other clustering toolkits do, ROCKS provides a mechanism for automatically generating kickstart files. However, instead of using a typical template framework, ROCKS provides an object-oriented (OO) framework. The "Object" here is a unit of configuration represented by a fragment of kickstart code. The kickstart code can have sections of the three types listed above.

<main>
  Some Kickstart tags for global config here
</main>

<package>name-an-rpm</package>

<pre>
  Some shell commands to run at start
</pre>

<post>
  Some shell commands to run at end
</post>

This is an Object: it encapsulates data and methods to perform install task. Of course, the kickstart language is not OO, so this is not a particularly rich OO framework (simple is good though).

In ROCKS these objects are called "nodes", a.k.a. vertexes, not to be confused with a computer node. The install of any computer in ROCKS is based on a set of vertexes that form a directed tree. Overlaying the trees for all the different defined installs yields a directed graph.

You define the vertexes, the edges (connections) between the vertexes, and additionally an ordering of vertexes (needed to get pre and post script right). A kickstart file is the sum of the code from all the vertexes.

So, setup the vertexes to define how to install various things. Setup a tree (graph) to define what gets installed for different computers.

Computer Nodes, Appliances, Distributions

The ROCKS database defines what gets installed on a computer in the following way.

The node table has membership. Here node means a computer.

The membership table has appliance and distribution

The appliance table has the name of the starting node (vertex) in the graph. Since the appliance points to the starting node, this defines most of the config.

The distribution table defines the local ROCKS distribution to use. ROCKS rebuilds the distribution (this unifies all the rolls and local config with the OS). You can have multiple distributions if needed.

Rolls, local config

The graph is mainly seen as a way of defining rolls, which are software packages that can be installed on ROCKS clusters. We aren't developing a roll (though at some point we might want to share aspects of our config with other sites as a roll). (We could turn our config into a roll, that would be a couple more steps in doing a release of the config.)

However, I think that our local config is complex enough and has enough different but overlapping configs to justify exploiting ROCKS OO framework.

A Plan

Vertexes need to do two things. Need target for appliance. Define install objects. Serve as Vertexes form collections of nodes. Keep functions separate.

Make nodes named "appliance-root" or similar that only exist to serve and the root of the install tree. Only config they do is putting the appliance string in /etc/motd.

Make nodes for the various install "objects". Try to keep them well defined and independent. ssh-client, ssh-server, nfs-client, nfs-server.

Will want some nodes that serve as collectors.

Bound to run into problems with overlap between some nodes. Make enough, but not to many nodes.

Big Wins

Config of a computer can be visualized from graph.

Nodes can be reused.

Management of installer easier, where some program is configured should be well defined.

Modularity especially useful when multiple people are working on the install (though still have to be careful).

-- TomRockwell - 06 Dec 2007