About the Image Management and Provisioning System (IMPS)
Overview of IMPs, bootable images, and IMPS objects: image recipes, image roots, boot images, repositories, package collections, and post-boot actions.
The Image Management and Provisioning System (IMPS) allows the system administrator to manage software content in images. IMPS leverages and extends industry-standard tools such as zypper and yum.

The Node Image Mapping Service (NIMS) is responsible for keeping track of which images get booted on which nodes, what additional kernel parameters to pass to nodes at boot time, and which load file to use within a boot image. The NIMS map is created during installation and changed when other images are created or when nodes are added, removed, or change function. The administrator can use NIMS to assign a boot image to any node or group of nodes. For more information, see About the Node Image Mapping Service (NIMS).
IMPS objects include:
- Image recipe
- Defines the image name and image contents (software). The recipe can include one or more packages (RPMs), package collections (logical groupings of RPMs), repositories, and other recipes (called subrecipes or nested recipes). A recipe can also specify post-boot actions such as copying files or executing commands using the
postbuild_copyandpostbuild_chrootdirectives.Custom image recipes can reference remote repositories that are hosted on an external repository server. For more information, see Install Third-Party Software with a Custom Image Recipe.
Location on the SMW: /etc/opt/cray/imps/image_recipes.d/
- Image root
- Directory on the SMW that contains the installed software. IMPS creates an image root from an image recipe. System administrators can chroot into the image root directory to examine its contents and the packages (RPMs) that were included to resolve build dependencies.
Location on the SMW: /var/opt/cray/imps/image_roots/
- Boot image
- IMPS creates a boot image (a .cpio file) from an image root by packaging the image root into a format suitable for booting on a Cray node or eLogin node. Note that a boot image is essentially unconfigured; the node configuration comes from the config set.
A boot image is the root file system for a node or group of nodes.The Cray XC™ Series root file system for nodes can either reside in RAM (tmpfs) or be mounted from a network source (netroot), depending on the type of node. The boot and SDB nodes, all other service nodes (except login nodes), and all DAL (direct-attached Lustre) nodes must use tmpfs. Compute nodes and login nodes may use either tmpfs or netroot. For more information, see Where to Place the Root File System: tmpfs versus netroot.
Location on the SMW: /var/opt/cray/imps/boot_images/
- Package collection
- Logical grouping of RPM packages. A package collection can contain versioned and unversioned package names, and can include other package collections. (Note that the package collections installed for CLE are read-only.) Only the top-level packages should be included in a package collection. The IMPS image creation process takes care of determining package dependencies and installing them from the defined repositories.
Cray recommends using a package collection because the RPMs can be used in multiple image types (such as compute and service node images).
Location on the SMW: /etc/opt/cray/imps/package_collections.d/
- Repository
- Logical grouping of RPMs based on operating system distribution. The content of SLES repositories and CentOS repositories should never be mixed. The installation process creates and populates the required repositories. System administrators can create their own repositories for third-party software.
Most operating system and Cray repositories come in pairs (base and updates). The updates repository is for future patches and security updates.
Location on the SMW: /var/opt/cray/repos/
IMPS Commands for Working with Images
- recipe
- Creates and manages image recipes.
- repo
- Creates and manages repositories.
- pkgcoll
- Creates and manages package collections.
- image
- Creates and manages image roots and boot images.
- imgbuilder
- Calls several IMPS commands so that multiple images can be built as a set with a single command. This command can also call the NIMS command cnode to assign boot images to nodes and adjust the netroot kernel parameter for nodes.
The imgbuilder command uses image group configuration information to build boot images. Image groups are defined in the global config set in /var/opt/cray/imps/config/sets/global/config/cray_image_groups.yaml.
Cray-provided Image Recipes
The Cray-provided image recipes have names like compute_cle_7.0.up02_sles_15_ari. The name includes the node function (such as compute), Cray product and version (cle_7.0.up02), OS type and version (sles_15), and network type (ari for the XC system Aries network).
Custom Image Recipes
- Create a new recipe (with
recipe create) and add the existing recipe as a subrecipe. Cray recommends this approach for most images because the recipe will receive updates from patches. - Clone the Cray-provided recipe (with
recipe create --clone) and change the contents. However, the recipe will not receive modifications from patches. For that reason, Cray does not recommend cloning an image recipe except for testing purposes.
Local image recipes are stored in the image recipe directory (/etc/opt/cray/imps/image_recipes.d/) in the file image_recipes.local.json.
For the procedure to create a custom image, see Install Third-Party Software with a Custom Image Recipe and Use a Custom Image Recipe to Change a File on a Compute Node. For information on using a custom recipe to remove an undesired RPM, see Remove an Undesired RPM After Building From a Cray Recipe.
Format of an Image Recipe
An image recipe is in a JSON file. Note that a single JSON file can contain multiple image recipes. Each image recipe starts with a name and description (a comment describing the intended use for the image). The remaining elements in a recipe specify the package collections, packages (RPMs), repositories, and other recipes (subrecipes). Each item has a rationale (a comment explaining why the item is included in the image). A recipe can also include post-build actions to copy files and execute commands or scripts in a chroot environment.
"image_recipe_name": {
"description": "Example recipe",
"dist": "SLES12",
"default-arch": "x86_64",
"valid-arch": [
"x86_64",
"aarch64"
],
"packages": [ ... ],
"package_collections": [ ... ],
”recipes": [ ... ],
"repositories": [ ... ],
"postbuild_chroot": [ ... ],
"postbuild_copyfiles": [ ... ],
"version": "2.0.0",
"metadata": {
"created": "2018-07-03T13:24:14"
"history": [
"2018-07-03T13:26:01: Extended recipes attribute with 1 Recipe."
...
]
}
}
"wlm_service": {
"description": "WLM service node image",
"dist": "SLES12",
"default-arch": "x86_64",
"valid-arch": [
"x86_64",
"aarch64"
],
"packages": [],
"package_collections": [],
”recipes": [
{
"name": "service_cle_7.0.up02_sles_15_ari",
"rationale": "Start from standard service node recipe"
}
],
"repositories": [],
"postbuild_chroot": [
"rpm -ivh /wlm.rpm",
"/wlm.installer /wlm.config"
],
"postbuild_copyfiles": [
"/home/crayadm/wlm_install/wlm.rpm",
"/home/crayadm/wlm_install/wlm.installer",
"/home/crayadm/wlm_install/wlm.config"
],
"version": "2.0.0",
"metadata": {
"created": "2018-07-03T13:24:14"
"history": [
"2018-07-03T13:26:01: Extended recipes attribute with 1 Recipe."
...
]
}
}
When using post-build actions, use postbuild_copy to copy files and directories from a location on the SMW. Use postbuild_chroot to execute post-build commands or scripts, which run in the chroot environment of the image root (on the SMW). Use the following environment variables for post-build scripts:
IMPS_IMAGE_NAMEIMPS_VERSIONIMPS_IMAGE_RECIPE_NAMEIMPS_POSTBUILD_FILES