Using Kickstart

The Node Images and Boot Configurations section discusses the creation and modification of compute node images and how to add locally installed nodes to the system. To facilitate the installation of these locally installed compute nodes, ClusterWare provides mechanisms for ISO upload and node kickstart.

Uploading ISO Images

ISO images of the installation DVDs for RHEL or CentOS systems can be downloaded from their respective websites and imported into ClusterWare as repos using the scyld-clusterctl repos command. For example:

scyld-clusterctl repos create name=CentOS iso=@CentOS-7-x86_64-DVD-1908.iso

Once the upload completes, the ISO will be automatically forwarded to all head nodes and will be locally mounted on each. Below are the repository details immediately after the upload completes:

[cwadmin@virthead]$ scyld-clusterctl repos -i CentOS ls -l
Repos
  CentOS
    iso
      chksum: 6b71f450513c92e2ab6ea663a69989f8f3680f01
      mtime: 2020-03-05 17:19:41 UTC (0:01:39 ago)
      size: 4.3 GiB (4664066048 bytes)
    isolabel: CentOS 7 x86_64
    keys: []
    name: CentOS
    urls
      <BASE_URL>/repo/CentOS/repo/

ClusterWare will display URLs for the repositories identified on the ISO. For example, there is a repository in the root of the uploaded CentOS ISO. This RPM repository can be accessed at <BASE_URL>/repo/CentOS/repo/. The <BASE_URL> tag is used as a placeholder to signify that any head node can provide access. Replace the tag with the base_url for a head node before using this URL:

[cwadmin@virthead]$ curl http://localhost/api/v1/repo/CentOS/repo/EULA
CentOS Linux 7 EULA

CentOS Linux 7 comes with no guarantees or warranties of any sorts,
either written or implied.

The Distribution is released as GPLv2. Individual packages in the
distribution come with their own licenses.

The mounted contents of the ISO are accessible through each head node's webserver at <BASE_URL>/repo/<REPONAME>/content/, and the ISO itself is located at <BASE_URL>/repo/<REPONAME>/iso. The ISO can also be downloaded using the scyld-clusterctl command:

scyld-clusterctl repos -iCentOS download iso

Just like URL defined repos, repos created using ISOs can be referenced in distros. See Creating PXEboot Images in Node Images and Boot Configurations in this guide for details about using repos and distros to create compute node images.

Kickstarting Installations

In addition to providing content for distros, repos based on CentOS or RHEL ISO images can also be used to kickstart locally installed compute nodes. To prepare a kickstart configuration, create a boot configuration that references the repo directly:

scyld-bootctl create name=CentOS_iso repo=CentOS

The resulting boot configuration will automatically locate the kernel and initramfs on the ISO and default to using no image:

[cwadmin@virthead]$ scyld-bootctl -i CentOS_iso ls -l
Boot Configurations
  CentOS_iso
    image: none
    initramfs: repo:images/pxeboot/initrd.img
    kernel: repo:images/pxeboot/vmlinuz
    last_modified: 2020-03-05 17:40:32 UTC (0:00:34 ago)
    name: CentOS_iso
    repo: CentOS

Initially this boot configuration can be used to boot a disked node with the live boot style assigned either by the boot configuration boot_style field or a _boot_style node attribute. When live booting a node, the cluster administrator will need to access the node's console to proceed through the operating system installation steps. To use the serial-over-lan BMC feature, the administrator may need to provide an appropriate console= cmdline:

scyld-bootctl -i CentOS_iso update cmdline=console=ttyS0,115200

The specific details of the console and other command line arguments depend on the target hardware and are beyond the scope of this document. Once the installation process is complete, the compute node should use a next boot style in order to skip the PXE boot process and instead boot from the next boot device. Cluster administrators are encouraged to configure the BIOS of locally installed compute nodes to attempt PXE boot first and then boot from the local disk so that the next boot style works as intended.

Once the freshly installed node has booted, there will be a /root/anaconda-ks.cfg file that can be used as a starting point for creating a more generalized kickstart file. If the cluster administrator would like to reinstall the node the exact same way, the simplest thing to do is copy that anaconda-ks.cfg file to the head node's kickstart directory and assign it to be used in the boot configuration:

cp anaconda-ks.cfg /opt/scyld/clusterware/kickstarts
scyld-bootctl -i CentOS_iso update kickstart=anaconda-ks.cfg

After that file is in place, any compute node booted from that boot configuration without the next or live boot style will boot using the kernel and initramfs from the ISO, and a URL to the kickstart file will be added to the kernel command line. Keep in mind that once a node starts the kickstart process, it is a good idea to change its boot style to next so that it does not reboot at the end of the install process and immediately reinstall. Configuring the kickstart process to end with a shutdown command (see your operating system documentation) is the current best practice.

If a cluster administrator wants to use a different kernel and/or initramfs for kickstarting instead of the ones found on the ISO, those can be replaced just like in any other boot configuration through the update action. Updating them with an empty string will reset them back to the detected paths:

scyld-bootctl -i CentOS update kernel= initramfs=

Kickstart Files

Kickstart configuration files are stored on the head node inside the /opt/scyld/clusterware/kickstarts/ folder. In a multihead configuration this folder must currently be manually synced between head nodes. These kickstart files can also contain a limited set of variables that will be substituted at download time. For example, the ClusterWare package includes an example called basic.ks that starts with the following contents:

install
text

url --url <repo_url()>
lang <head[lang]>
keyboard <head[keymap]>
timezone <head[timezone]>

# Node fields, attributes, status, and hardware are also available in
#   dictionaries referenced by name or initial.
#
# <node[ip]>
# <a[_boot_config]>
# <hardware[mac]>

Two different types of tags are supported, and both provide simple text substitution. The first, exemplified by the <repo_url()> tag, is a function call that accepts as an optional argument the name of a ClusterWare repo. That tag will be replaced by an appropriate URL for the named repo. Similarly, certain values are represented as more of a dictionary-like reference, e.g. <head[timezone]>. These tags provide a simple variable lookup for information such as the head node timezone. The snippet above shows all the currently supported tags except for the <include(partial.ks)> tag. The include tag allows a cluster administrator to break the kickstart files into manageable hunks that can then be included into a top-level kickstart file, much like a C or C++ #include.

The post-substitution contents of the kickstart file depend on the specific node and can be downloaded using the scyld-bootctl tool with the node name appended:

scyld-bootctl -i CentOS_iso download kickstart.n1

Additional variables and functions are planned, and the development team is open to suggestions of substitutions that would be useful to cluster administrators.