Overview

Kits provide a means to install software on your cluster with minimal effort. A kit includes three kinds of packages:

• kit package
• component packages
• software packages (if any)

The kit package often contains the kitinfo file with some metadata about the kit, plugins for Kusu tools, or kit-specific documentation, and should only need to be installed on the Kusu master node.

Components make installing packages on various nodes simple. Consider a distributed file system kit, which contains the software needed for the file system head node as well as the storage nodes. Installing the "head node" component on one machine and the "storage node" component on other machines automatically pulls in the software packages required for each type of node from the packages shipped in the kit. You don't have to manually figure out where each package has to be installed.

Adding Kits

Adding a kit and installing its software on the nodes in a cluster has 4 main steps.

1. Add Kit to Kusu Database

First we need to import the kit information into the Kusu database and copy the files to disk. The kitops tool is used for this purpose:


We invoke kitops with two parameters:

• -a/--add indicates the addition of a new kit
• -m /path/to/my_kit-1.0.iso points to the ISO containing the kit files

Once kitops completes, the kit and its components will be registered in the Kusu database and the kit's contents are copied to /depot/kits/my_kit/1.0/x86_64/ on the Kusu master node.

2. Add Kit to Repository

The kit needs to be added to a repository before it becomes available for installation. The repoman tool is used to accomplish this:

repoman is invoked three times with these parameters:

• -l/--list lists the repositories currently in the system
• -r/--reponame selects a repository by name, indicating which repository to operate on
• -a/--add tells repoman to add to the repository
• -k/--kit points to the kit to add; this could also be my_kit-1.0-x86_64 to be more specific
• -u/--update rebuilds the repository metadata with the new packages included

First determine which repository to operate on, then add the new kit to this repository and refresh it. Note that after adding multiple kits to the same repository, the update need only be executed once.

3. Associate Kit Components with Nodegroups

Once the kit packages are included in a repository, its components become available for association with nodegroups which use that repository. The ngedit tool provides control over this.

Two of its many screens are of interest in this case, the Repository and Components screens. At the Repository screen, ensure the nodegroup is using the repository containing the new kit. At the Components screen, select the component all nodes in this nodegroup need to have installed.

4. Update the Nodes in Affected Nodegroups

Any new nodes provisioned after saving the changes made with ngedit will automatically install the kit packages during provisioning. Nodes which are already up at the time changes are saved can either be rebooted, forcing a reinstall or the new packages can be pushed to the nodes via cluster file management (cfm). The last screen in ngedit offers to run cfm for you; if you decide to skip this step, the cfm command to run manually later is presented.

Removing Kits


Removing a kit is the exact reverse process of adding it:

1. run ngedit to remove any associations between nodegroups and kit components
2. run repoman -r <repo_name> -d -k <kit_name> to remove the kit from any repositories
3. don't forget to run repoman -r <repo_name> -u to refresh the repository metadata
4. run kitops -e -k <kit_name> to remove the kit from the Kusu database and the kit files from /depot/kits

Checking Which Kits are Installed

kitops also provides the -l command line option which displays the kits currently installed:
References

• kitops usage guide

Further Reading/For Developers

• kitops high-level overview
• kitinfo file (blog post)
• buildkit by example (blog post)