Thread: Kusu Kits

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:

Code:

$ kitops -a -m /path/to/my_kit-1.0.iso 
Added kit my_kit-1.0-x86_64

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:

Code:

 $ repoman -l
Repo name:      Repo for centos-5-x86_64
Repository:     /depot/repos/1000
Installers:     172.20.0.1
Ostype:         centos-5-x86_64
Kits:           base 0.1 noarch, centos 5 x86_64
 
$ repoman -r "Repo for centos-5-x86_64" -a --kit=my_kit
Kit: my_kit, version 1.0, architecture x86_64, has been added to repo: Repo for
centos-5-x86_64.  Remember to refresh with -u
$ repoman -r "Repo for centos-5-x86_64" -u
Refreshing repo: Repo for centos-5-x86_64. This may take a while...

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:

Code:

$ kitops -l Kit: base 
Description: Base Kit 
Version: 0.1 
Architecture: noarch 
OS Kit: No 
Removable: No 
Node Groups: installer-centos-5-x86_64, compute-centos-5-x86_64, compute-imaged-centos-5-x86_64, compute-diskless-centos-5-x86_64 
 
Kit: centos 
Description: OS kit for centos 5 x86_64 
Version: 5
Architecture: x86_64 
OS Kit: Yes
Removable: Yes
Node Groups: installer-centos-5-x86_64, compute-centos-5-x86_64, compute-imaged-centos-5-x86_64, compute-diskless-centos-5-x86_64 
 
Kit: my_kit
Description: My Kit
Version: 1.0 Architecture: x86_64
OS Kit: No
Removable: Yes
Node Groups: installer-centos-5-x86_64, compute-centos-5-x86_64

References

• kitops usage guide

Further Reading/For Developers

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

Excellent documentation. Thanks for your work on this. It is very useful.

There are kits for travellers to take on expeditions with needles and sutures for minor surgery, end even for emergency dentistry. Some people feel that it is nice to take these because they don't trust the sterility of materials in foreign hospitals. However the implements in my emergency kit are selected by me because I know how to use them. There is no point in making a kit like that available to the general public.