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.

IMPS uses an image recipe to install collections of software (RPMs) into an image root. The image root is used to create a boot image. Image recipes tie together collections of software defined in the package collections and the repositories that contain the software. IMPS creates an image root from an image recipe and resolves all RPM dependencies. When building an image root from a image recipe, IMPS builds any subrecipes and then gathers all specified packages and package collections and software repositories in the image recipe before generating the call to the package manager (rpm). After the package manager has created the image root, it may be further modified by non-RPM-based content if there are post-build directives in the recipe.
Figure: Create Bootable Images Using Recipes

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_copy and postbuild_chroot directives.

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

These IMPS commands are available for working with recipes, repositories, package collections, and 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.

For each command, use the list subcommand to display the existing items. Use the -h option to display the available subcommands and arguments. For more information, see the man pages on the SMW.

Cray-provided Image Recipes

Cray provides read-only image recipes that system administrators can build into bootable images for these node types: service, compute, admin (for boot and SDB nodes), login, Direct Attached Lustre (DAL), and eLogin. In addition, administrators can create custom recipes that are based on the read-only recipes.
Important: Do not directly modify a Cray-provided image recipe.

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

System administrators can use IMPS commands to create custom image recipes that are based on the Cray-provided recipes.There are two ways to customize an image recipe:
  • 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.

An image recipe has the following basic format:
"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."
             ...
         ]
    }
}
The following example shows the format of a custom image recipe for service nodes that includes a workload manager (WLM). It includes the Cray-provided recipe as a subrecipe, then specifies post-build actions to copy WLM files and run the necessary scripts.
"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_NAME
  • IMPS_VERSION
  • IMPS_IMAGE_RECIPE_NAME
  • IMPS_POSTBUILD_FILES