xCAT/xcat-core
2
0
Fork 0
mirror of https://github.com/xcat2/xcat-core.git synced 2025-05-29 09:13:08 +00:00
Code Issues Releases Wiki Activity

Add documentation to Software Kits

Browse Source
This commit is contained in:
Casandra Qiu 2015-09-22 16:00:38 -04:00
parent 79e4df3c6b
commit 71420cc747
16 changed files with 1012 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/source/advanced/index.rst
View File

@ -11,7 +11,7 @@ Advanced Topics
change_mn_ip.rst
change_node_ip.rst
xcat_security.rst
kit.rst
kit/index.rst
ib.rst
confluent/index.rst
docker/index.rst

2
docs/source/advanced/kit.rst
View File

@ -1,2 +0,0 @@
Using Software KITs
===================

28
docs/source/advanced/kit/addkit.rst Normal file
View File

@ -0,0 +1,28 @@
Add a Kit to xCAT
-----------------
Adding a complete Kit to xCAT
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
A complete kit must be added to the xCAT management node and defined in the xCAT database before its kit components can be added to xCAT osimages or used to update diskful cluster nodes.
To add a kit run the following command:
::
addkit <complete kit tarfile>
The addkit command will expand the kit tarfile. The default location will be <site.installdir>/kits directory but an alternate location may be specified. (Where site.installdir is the value of the installdir attribute in the xCAT site definition.)
It will also add the kit to the xCAT database by creating xCAT object definitions for the kit as well as any kitrepo or kitcomponent definitions included in the kit.
Kits are added to the kit table in the xCAT database keyed by a combination of kit basename and version values. Therefore, user can add multiple kit definitions for the same product. For example, user could have one definition for release 1.2.0.0 and one for 1.3.0.0 of the product. This means that user will be able to add different versions of the kit components to different osimage definitions if desired.
Listing a kit
^^^^^^^^^^^^^
The xCAT kit object definition may be listed using the xCAT lsdef command.
::
lsdef -t kit -l <kit name>
The contents of the kit may be listed by using the lskit command.
::
lskit <kit name>

66
docs/source/advanced/kit/addkitcomp.rst Normal file
View File

@ -0,0 +1,66 @@
Adding Kit Components
---------------------
Adding Kit Components to an OS Image Definition
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
In order to add a kitcomponent to an OS image definition, the kitcomponent must support the OS distro, version, architecture, serverrole for that OS image.
Some kitcomponents have dependencies on other kitcomponents. For example, a kit component may have a dependency on the product kit license component. Any kit components they may be required must also be defined in the xCAT database.
Note: A kit component in the latest product kit may have a dependency on a license kit component from an earlier kit version.
To check if a kitcomponent is valid for an existing OS image definition run the chkkitcomp command:
::
chkkitcomp -i <osimage> <kitcompname>
If the kit component is compatible then add the kitcomponent to the OS image defintion using the addkitcomp command.
::
addkitcomp -a -i <osimage> <kitcompname>
When a kitcomponent is added to an OS image definition, the addkitcomp command will update several attributes in the xCAT database.
Listing kit components
^^^^^^^^^^^^^^^^^^^^^^
The xCAT kitcomponent object definition may be listed using the xCAT lsdef command.
::
lsdef -t kitcomponent -l <kit component name>
The contents of the kit component may be listed by using the lskitcomponent command.
::
lskitcomp <kit component name>
Adding Multiple Versions of the Same Kit Component to an OS Image Definition
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
xCAT allows to have multiple versions/releases of a product software kit available in the cluster. Typically, different OS image definitions corresponding to the different versions/releases of a product software stack. However, in some instances, may need mulitple versions/releases of the same product available within a single OS image. This is only feasible if the software product supports the install of multiple versions or releases of its product within an OS image.
Currently, it is not possible to install multiple versions of a product into an OS image using xCAT commands. xCAT uses yum on Redhat and zypper on SLES to install product rpms. These package managers do not provide an interface to install different versions of the same package, and will always force an upgrade of the package. We are investigating different ways to accomplish this function for future xCAT releases.
Some software products have designed their packaging to leave previous versions of the software installed in an OS image even when the product is upgraded. This is done by using different package names for each version/release, so that the package manager does not see the new version as an upgrade, but rather as a new package install. In this case, it is possible to use xCAT to install multiple versions of the product into the same image.
By default, when a newer version/release of a kitcomponent is added to an existing OS image definition, addkitcomp will automatically upgrade the kitcomponent by removing the old version first and then adding the new one. However, user can force both versions of the kitcomponent to be included in the OS image definition by specifying the full kitcomponent name and using the addkitcomp -n (--noupgrade) flag with two separate command calls. For example, to include both myprod_compute.1-0.1 and myprod_compute.1-0.2 into an the compute osimage, you would run in this order:
::
addkitcomp -i compute myprod_compute.1-0.1
addkitcomp -i compute -n myprod_compute.1-0.2
lsdef -t osimage -o compute -i kitcomponents
Object name: compute
kitcomponents=myprod_compute.1-0.1,myprod_compute.1-0.2
When building a diskless image for the first time, or when deploying a diskfull node, xCAT will first install version 1-0.1 of myprod, and then in a separate yum or zypper call, xCAT will install version 1-0.2. The second install will either upgrade the product rpms or install the new versions of the rpms depending on how the product named the packages.
Modifying Kit Deployment Parameters for an OS Image Definition
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Some product software kits include kit deployment parameter files to set environment variables when the product packages are being installed in order to control some aspects of the install process. To determine if a kit includes such a file:
::
lsdef -t kit -o <kitname> -i kitdeployparams
If the kit does contain a deployment parameter file, the contents of the file will be included in the OS image definition when user add one of the kitcomponents to the image. User can view or change these values if need to change the install processing that they control for the software product:
::
addkitcomp -i <image> <kitcomponent name>
vi /install/osimages/<image>/kits/KIT_DEPLOY_PARAMS.otherpkgs.pkglist
NOTE: Please be sure to know how changing any kit deployment parameters will impact the install of the product into the OS image. Many parameters include settings for automatic license acceptance and other controls to ensure proper unattended installs into a diskless image or remote installs into a diskfull node. Changing these values will cause problems with genimage, updatenode, and other xCAT deployment commands.

324
docs/source/advanced/kit/building.rst Normal file
View File

@ -0,0 +1,324 @@
Building a Kit
==============
Install the xCAT-buildkit RPM
-----------------------------
check to see if xCAT-buildkit RPM is installed in the build server
::
rpm -qa | grep xCAT-buildkit
The xCAT-buildkit RPM is required to build a kit. It will be installed automatically as part of installing base xCAT. If the build server is not an xCAT management node, it can be
#. Download the xCAT tar file and install the xCAT-buildkit RPM from the local repositroy
#. Install the RPM directly from the internet-hosted repository
Once the repositories are setup, use yum to install xCAT-buildkit and all its dependencies
::
yum clean metadata
yum install xCAT-buildkit
For sles, use zypper install and for Ubuntu, use apt-get to install xCAT-buildkit
Create a Kit directory Structure
--------------------------------
Use the **buildkit** command to create a kit template directory structure
::
buildkit create <kit_basename> [-l|--kitloc <kit location>]
The Kit directory location will be automatically populated with additional subdirecotries and samples:
::
**buildkit.conf** - The sample Kit build configuration file.
**source_packages** - This directory stores the source packages for Kit Packages and Non-Native Packages.
The **buildkit** command will search these directories for source packages when building packages.
This directory stores:
* RPM spec and tarballs. (A sample spec file is provided.)
* Source RPMs.
* Pre-built RPMs (contained in a subdirectory of source_packages)
* Non-Native Packages
**scripts** - This directory stores the Kit Deployment Scripts. Samples are provided for each type of script.
**plugins** - This directory stores the Kit Plugins. Samples are provided for each type of plugin.
**docs** - This directory stores the Kit documentation files.
**other_files**
* **kitdeployparams.lst**: Kit Deployment parameters file
* **exclude.lst**: File containing files/dirs to exclude in stateless image.
**build** - This directory stores files when the Kit is built.
**build/kit_repodir** - This directory stores the fully built Kit Package Repositories
**build/<kitbasename>** - This directory stores the contents of the Kit tarfile before it is tar'red up.
**<kit directory location>/<kitname>** - The kit tar file, partial kit name or complete kit tar file name (ex. kitname.tar.bz2)
The Kit Configuration File
---------------------------------
The sample buildkit.conf file contains a description of all the supported attributes and an indication of whether or not they are required or optional. The user need to modify this file for the product kit he/she is building. The file contains stanza format.
**kit** --- This stanza defines general information for the Kit. There must be exactly one kit stanza in a kit build file.
**kitrepo** --- This stanza defines a Kit Package Repository. There must be at least one kitrepo stanza in a kit build file. If this kit need to support multiple OSes, user should create a separate repository for each OS. Also, no two repositories can be defined with the same OS name, major/minor version, and arch.
**kitcomponent** --- This stanza defines one Kit Component. A kitcomponent definition is a way of specifying a subset of the product Kit that may be installed into an xCAT osimage. A kitcomponent may or may not be dependent on other kitcomponents.If user want to build a component which supports multiple OSes, need to create one kitcomponent stanza for each OS.
**kitpackage** --- This stanza defines Kit Package (ie. RPM). There can be zero or more kitpackage stanzas. For multiple package supports, need to
1. Define one kitpackage section per supported OS. or
2. Define one kitpacakge stanza which contains multiple kitrepoid lines. For the RPM packages, users need to responsible for createing an RPM spec file that can run on multiple OSes.
Sample of buildkit.conf file
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
**Note**: The sample buildkit.conf file may change over time. To get the latest version of the file look for it in the /opt/xcat/share/xcat/kits/kit_template directory.
::
# Kit Build File
#
# A unique version of this file is automatically generated for a new Kit
# when you run the **buildkit** command to create a new Kit. The basic template
# for this file is contained in the /opt/xcat/share/xcat/kits/kit_template
# directory. Once the initial version of this file is generated you will
# have to modify it by adding the details needed to build your new Kit.
#
# Refer to the buildkit manpage for further details.
#
# kit: This stanza defines general information for the Kit.
# There must be exactly one kit stanza in a buildkit.conf file.
#
# kit attributes:
# basename (mandatory) Kit base name. (ex. "myproduct")
#
# description (optional) Kit description.
#
# version (mandatory) Kit version. ( template default "1.0")
#
# release (optional) Kit release. (template default "1")
#
# ostype (mandatory) Kit OS type. (template default "Linux")
# (AIX is currently not supported.)
#
# vendor (optional) The vendor tag is used to define the name of
# the entity that is responsible for packaging
# the software.
#
# packager (optional) The packager tag is used to hold the name and
# contact information for the person or persons
# who built the package.
#
# url (optional) The url tag is used to provide a location to
# obtain additional information about the
# packaged software.
#
# osbasename (optional) OS distro base name. (ex. "rhels")
#
# osmajorversion (optional) OS major version. (ex. "6")
#
# osminorversion (optional) OS minor version.
#
# osarch (optional) OS architecture. (ex. "x86_64")
#
# isinternal (optional) PCM use only.
# Indicate if Kit is for internal use.
# Use 1 for yes, 0 for no. Default: 0
#
# kitdeployparams (optional) Filename containing a list of kit deployment
# parameters. The name should be the full path name of
# the file relative to <Kit Build Directory>/other_files
#
# kitlicense (mandatory) Kit license string to be built into all
# kitcomponent packages. (template default "EPL")
#
# kittarfilename (optional) Filename.tar.bz2 to be used for the generated
# kit. (ex. "myproduct-1.4.0.6-0-x86_64.tar.bz2")
# The default format is:
# <basename>-<version>-<opt-release>-<opt-osbasename>-<opt-osmajorversion>-<opt-osminorversion>-<opt-osarch>.tar.bz2
#
kit:
basename=<<<INSERT_kitbasename_HERE>>>
description=description for <<<INSERT_kitbasename_HERE>>>
version=1.0
release=1
ostype=Linux
kitlicense=EPL
# vendor=
# packager=
# url=
# osbasename=
# osmajorversion=
# osminorversion=
# osarch=
# isinternal=
# kitdeployparams=sample/kitdeployparams.lst
# kittarfilename=
#
# kitrepo: This stanza defines a Kit Package Repository.
# There must be at least one kitrepo stanza in a kit build file.
# If you want to support multiple OSes, you should create a separate
# repo for each OS. Also, no two repos can be defined with the same
# OS name, major/minor version and arch. For example, you cannot have
# two repos for RHEL 6.2 x86_64 in the same kit.
#
# kitrepo attributes:
# kitrepoid (mandatory) Kit package repository ID. Must be unique within
# this file. A typical name may be something like:
# "<osbasename><osmajorversion>.<osminorversion>_<osarch>".
# (ex. "rhels6.4_x86_64")
#
# osbasename (mandatory) OS distro base name. (ex. "rhels")
#
# osmajorversion (mandatory) OS major version. (ex. "6")
#
# osminorversion (optional) OS minor version. (ex. "4")
#
# osarch (mandatory) OS architecture. (ex. "x86_64")
#
# compat_osbasenames (optional) Comma-separated list of compatible
# OS distribution base names. (ex. "centos")
kitrepo:
kitrepoid=<<<INSERT_kitrepoid_HERE>>>
osbasename=<<<INSERT_osbasename_HERE>>>
osmajorversion=<<<INSERT_osmajorversion_HERE>>>
osminorversion=<<<INSERT_osminorversion_HERE>>>
osarch=<<<INSERT_osarch_HERE>>>
# compat_osbasenames=
#
# kitcomponent: This stanza defines one Kit Component.
# There can be zero or more kitcomponent stanzas.
# If you want to build a component which supports multiple OSes,
# you should create one kitcomponent section for each OS.
# You can define multiple kit components with the same base name
# only if each kit component using this base name meets these
# requirements:
# - Each kit component must be defined with the same version
# and release number
# - Each kit component must be defined with a unique kitrepoid
#
# kitcomponent attributes:
# basename (mandatory) Kit component base name (ex. "myproduct_compute")
#
# description (optional) Kit component description
#
# version (optional) Kit component version. The default is the kit version.
#
# release (optional) Kit component release. The default is the kit release.
#
# serverroles (mandatory) Comma-separated list of node types that this
# component could be installed on. (Valid values:
# mgtnode,servicenode,compute,login,storage,utility)
# (template default: "compute")
#
# kitrepoid (mandatory) The ID of the kit package repository this
# component belongs to.
#
# kitcompdeps (optional) Comma-separated list of kit component
# dependencies. These kit components can be included in
# this kit or in other kits.
#
# ospkgdeps (optional) Comma-separated list of OS RPM dependency basenames.
# These packages must be shipped with the OS distro.
#
# kitpkgdeps (mandatory IF product RPMs will be included in this Kit)
# Comma-separated list of RPM basenames. Each RPM must
# be defined in a separate kitpackage stanza. Each RPM
# package must be in the same kitrepo as this kit component.
#
# non_native_pkgs (optional)
# Comma-separated list of non-native package
# paths that will be included as files in this kit
# component. All filenames are relative to
# <Kit Build Directory>/source_packages and may contain
# wildcards. If a filename is prefixed by 'EXTERNALPKGS:'
# the file will not be built into the kit tarfile, but
# will need to be added later with a 'buildkit addpkgs'
# command.
# Files will be placed in
# /opt/xcat/kits/<kitbasename>/<kitcomponent_name>
# when the kitcomponent package is deployed to an
# OS image.
# Kit component deployment scripts must be specified
# to manage these files.
#
# driverpacks (optional) Comma-separated list of driver package filenames
# Each driverpack must be defined in a separate kitpackage
# section.
#
# exlist (optional) Exclude list file for stateless image, relative
# to <Kit Build Directory>/other_files
#
# Kit component deployment scripts (optional) Each attribute specifies
# script path relative to <Kit Build Directory>/scripts
# Script attributes:
# preinstall, postinstall, preuninstall, postuninstall,
# preupgrade, postupgrade, postbootscripts,
# genimage_postinstall
kitcomponent:
basename=<<<INSERT_kitcomponent_basename_HERE>>>
description=description for component <<<INSERT_kitcomponent_basename_HERE>>>
serverroles=compute
kitrepoid=<<<INSERT_kitrepoid_HERE>>>
kitpkgdeps=pkg1basename,pkg2basename
# kitcompdeps=myproduct_license
# ospkgdeps=dep1,dep2
# non_native_pkgs=a_kitcomponent.file
# non_native_pkgs=EXTERNALPKGS:a_kitcomponent.file
# driverpacks=
# exlist=sample/exclude.lst
# preinstall=sample/pre.sh
# postinstall=sample/post.sh
# preuninstall=sample/preun.sh
# postuninstall=sample/postun.sh
# preupgrade=sample/preup.sh
# postupgrade=sample/postup.sh
# postbootscripts=sample/postboot.sh
# genimage_postinstall=sample/genimage_post.sh
#
# kitpackage: This stanza defines one Kit Package.
# There can be zero or more kitpackage stanzas.
#
# If you want to build a package which can run on multiple OSes,
# you have two options:
# 1. Build a separate package for each OS you want to support.
# For this option, you need to define one kitpackage stanza
# per supported OS.
# 2. Build one package that can run on multiple OSes.
# If you are building an RPM package, you are responsible for
# creating an RPM spec file that can run on multiple OSes.
# For this option, you need to define one kitpackage stanza
# which contains multiple kitrepoid lines.
#
#
# kitpackage attributes:
# filename (mandatory) Package filename. The filename may contain wildcards to avoid needing to
# specify an explicit package version-release filename.
#
# kitrepoid (mandatory) A comma-separated list of kit repo names this package
# belongs to. If multiple repos are defined, the package will
# be built for the first repo only. For the other repos,
# a symlink is created to the package built for the first repo.
#
# isexternalpkg (mandatory) Indicates if the package will be included in this kit or added later.
# 'no' or '0' means the package is included.
# 'yes' or '1' means the packages will be added later.
# The default if not set is 'no'.
#
# rpm_prebuiltdir (mandatory IF isexternalpkg=no) Path to the directory containing the pre-built RPMs relative to
# <Kit Build Directory>/source_packages directory.
# For example, if the file is "<Kit Build Directory>/source_packages/foobar/foo.rpm"
# then set "rpm_prebuiltdir=foobar".
kitpackage:
filename=pkg1-*.noarch.rpm
kitrepoid=<<<INSERT_kitrepoid_HERE>>>
isexternalpkg=no
rpm_prebuiltdir=<path>
Copy Files into the Kit Directory Structure
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
After editing the buildkit configuration file (buildkit.conf), the user needs to copy files into the kit directory if defined in the buildkit.conf.
The type of files may need to copy are:
**Source Packages** -- If kitpackage attribute isexternalpkt define "no", all the required pre-built RPMS need to copy to rpm_prebuildtdir
**Deployment Scripts** --- These files should be copied to <Kit directory location>/scripts
**Plugins** --- For IBM HPC Products in this first release, no plugins will be developed. However, future support may be considered by the product packaging developers. For example, GPFS may choose to implement a nodemgmt.pm plugin that would add a new node to the GPFS cluster. - These files should be copied to: <Kit directory location>/plugins
**Doc Files** --- These files should be copied to <Kit directory location>/docs

18
docs/source/advanced/kit/buildkit/buildkit-rpm.rst Normal file
View File

@ -0,0 +1,18 @@
Install the xCAT-buildkit RPM
-----------------------------
check to see if xCAT-buildkit RPM is installed in the build server
::
rpm -qa | grep xCAT-buildkit
The xCAT-buildkit RPM is required to build a kit. It will be installed automatically as part of installing base xCAT. If the build server is not an xCAT management node, it can be
#. Download the xCAT tar file and install the xCAT-buildkit RPM from the local repositroy
#. Install the RPM directly from the internet-hosted repository
Once the repositories are setup, use yum to install xCAT-buildkit and all its dependencies
::
yum clean metadata
yum install xCAT-buildkit
For sles, use zypper install and for Ubuntu, use apt-get to install xCAT-buildkit

149
docs/source/advanced/kit/buildkit/createkit.rst Normal file
View File

@ -0,0 +1,149 @@
Create a New Kit
================
Use the **buildkit** command to create a kit template directory structure
::
buildkit create <kit_basename> [-l|--kitloc <kit location>]
The Kit Directory
^^^^^^^^^^^^^^^^^
The Kit directory location will be automatically populated with additional subdirecotries and samples:
::
**buildkit.conf** - The sample Kit build configuration file.
**source_packages** - This directory stores the source packages for Kit Packages and Non-Native Packages.
The **buildkit** command will search these directories for source packages when building packages.
This directory stores:
* RPM spec and tarballs. (A sample spec file is provided.)
* Source RPMs.
* Pre-built RPMs (contained in a subdirectory of source_packages)
* Non-Native Packages
**scripts** - This directory stores the Kit Deployment Scripts. Samples are provided for each type of script.
**plugins** - This directory stores the Kit Plugins. Samples are provided for each type of plugin.
**docs** - This directory stores the Kit documentation files.
**other_files**
* **kitdeployparams.lst**: Kit Deployment parameters file
* **exclude.lst**: File containing files/dirs to exclude in stateless image.
**build** - This directory stores files when the Kit is built.
**build/kit_repodir** - This directory stores the fully built Kit Package Repositories
**build/<kitbasename>** - This directory stores the contents of the Kit tarfile before it is tar'red up.
**<kit directory location>/<kitname>** - The kit tar file, partial kit name or complete kit tar file name (ex. kitname.tar.bz2)
The Kit Configuration File
^^^^^^^^^^^^^^^^^^^^^^^^^^
The sample buildkit.conf file contains a description of all the supported attributes and an indication of whether or not they are required or optional. The user need to modify this file for the product kit he/she is building. The file contains stanza format.
**kit** --- This stanza defines general information for the Kit. There must be exactly one kit stanza in a kit build file.
::
kit:
basename=pperte
description=Parallel Environment Runtime Edition
version=1.3.0.6
release=0
ostype=Linux
osarch=x86_64
kitlicense=ILAN <== the default kit license string is "EPL"
kitdeployparams=pe.env <== pe.env has to define in the other_files dir.
**kitrepo** --- This stanza defines a Kit Package Repository. There must be at least one kitrepo stanza in a kit build file. If this kit need to support multiple OSes, user should create a separate repository for each OS. Also, no two repositories can be defined with the same OS name, major/minor version, and arch.
::
kitrepo:
kitrepoid=rhels6_x86_64
osbasename=rhels
osmajorversion=6
osarch=x86_64
kitrepo:
kitrepoid=sles11_x86_64
osbasename=sles
osmajorversion=11
osarch=x86_64
**kitcomponent** --- This stanza defines one Kit Component. A kitcomponent definition is a way of specifying a subset of the product Kit that may be installed into an xCAT osimage. A kitcomponent may or may not be dependent on other kitcomponents.If user want to build a component which supports multiple OSes, need to create one kitcomponent stanza for each OS.
::
kitcomponent:
basename=pperte_license
description=PE RTE for compute nodes
serverroles=compute
# These packages must be shipped with the OS distro
ospkgdeps=at,rsh,rsh-server,xinetd,sudo,libibverbs(x86-32),libibverbs(x86-64),redhat-lsb
kitrepoid=rhels6_x86_64
kitpkgdeps=ppe_rte_license
kitcomponent:
basename=pperte_compute
description=PE RTE for compute nodes
serverroles=compute
kitrepoid=rhels6_x86_64
kitcompdeps=pperte_license
kitpkgdeps=pperte,pperteman,ppertesamples,src
exlist=pe.exlist <=== the file needs to define in the other_files dir
# All those post script need to define in the scripts dir
postinstall=pperte_postinstall
postupgrade=pperte_postinstall
postbootscripts=pperte_postboot
kitcomponent:
basename=pperte_license
description=PE RTE for compute nodes
serverroles=compute
ospkgdeps=at,rsh-server,xinetd,sudo,libibverbs-32bit,libibverbs,insserv
kitrepoid=sles11_x86_64
kitpkgdeps=ppe_rte_license
**kitpackage** --- This stanza defines Kit Package (ie. RPM). There can be zero or more kitpackage stanzas. For multiple package supports, need to
#. Define one kitpackage section per supported OS. or
#. Define one kitpacakge stanza which contains multiple kitrepoid lines. For the RPM packages, users need to responsible for createing an RPM spec file that can run on multiple OSes.
::
kitpackage:
filename=pperte-*.x86_64.rpm
kitrepoid=rhels6_x86_64,sles11_x86_64
kitpackage:
filename=pperteman-*.x86_64.rpm
kitrepoid=rhels6_x86_64,sles11_x86_64
kitpackage:
filename=ppertesamples-*.x86_64.rpm
kitrepoid=rhels6_x86_64,sles11_x86_64
kitpackage:
filename=ppe_rte_*.x86_64.rpm
kitrepoid=rhels6_x86_64,sles11_x86_64
kitpackage:
filename=ppe_rte_man-*.x86_64.rpm
kitrepoid=rhels6_x86_64,sles11_x86_64
kitpackage:
filename=ppe_rte_samples-*.x86_64.rpm
kitrepoid=rhels6_x86_64,sles11_x86_64
kitpackage:
filename=src-*.i386.rpm
kitrepoid=rhels6_x86_64,sles11_x86_64
# License rpm gets placed in all repos
kitpackage:
filename=ppe_rte_license-*.x86_64.rpm
kitrepoid=rhels6_x86_64,sles11_x86_64
**Note**: The latest version of the buildkit.conf file is located in the /opt/xcat/share/xcat/kits/kit_template directory.
Partial vs. Complete Kits
^^^^^^^^^^^^^^^^^^^^^^^^^
A **Complete** software kit includes all the product software. A **Partial** kit is one that does not include the product packages. the "isexternalpkg=yes" needs to set in the "kitpackage" stanzas in the buildkit.conf file if user wants a parital kit.
::
kitpackage:
filename=foobar_runtime-*.x86_64.rpm
kitrepoid=rhels6_x86_64
isexternalpkg=yes
In this case, the user has to download both the kit tarfiles and the product packages in order to complete the kit before use it in an xCAT cluster.

14
docs/source/advanced/kit/buildkit/index.rst Normal file
View File

@ -0,0 +1,14 @@
Building Kits
===================
.. toctree::
:maxdepth: 2
buildkit-rpm.rst
createkit.rst
validatekit.rst
kitrepo.rst
kittarfile.rst
kitconfile.rst

27
docs/source/advanced/kit/buildkit/kitrepo.rst Normal file
View File

@ -0,0 +1,27 @@
Build the Kit Package Repositories
==================================
After the buildkit configuration file is validated, run the "buildrepo" subcommand to build the Kit Package Repositories. The build server has to have same OS distributions, versions, or architectures with build kit repositories. User can copy the kit template directory to an appropriate server to build the repository then copy the results back the current system.
IBM HPC Products are using pre-built rpms. There are no OS/arch specific in the kitcomponent meta-package rpm and should be able to build all repositories on the same server.
To list the repos defined in the buildkit.conf:
::
buildkit listrepo
To build the repositories, specifiy a particular reporitory:
::
buildkit buildrepo <kit repo name>
or build all the repositories for this kit:
::
buildkit buildrep all
The repository would be built in <Kit directory location>/build/kit_repodir/ subdirectory.
If the Kit Package Repository is already fully built, then this command performs no operation.
If the Kit Package Repository is not fully built, the command builds it as follows:
#. Create the Kit Package Repository directory .<Kit directory location>/build/kit_repodir/<Kit Pkg Repo> .
#. Build the Component Meta-Packages associated with this Kit Package Repository. Create the packages under the Kit Package Repository directory
#. Build the Kit Packages associated with this Kit Package Repository. Create the packages under the Kit Package Repository directory
#. Build the repository meta-data for the Kit Package Repository. The repository meta-data is based on the OS native package format. For example, for RHEL, we build the YUM repository meta-data with the createrepo command.

44
docs/source/advanced/kit/buildkit/kittarfile.rst Normal file
View File

@ -0,0 +1,44 @@
Build the Kit Tarfile
=====================
After the Kit package repositories are built, run the "buildtar" subcommand in the Kit directory to build the final kit tarfile.
::
buildkit buildtar
The tar file will be built in the kit directory location. A complete kit will be named:
::
ex: kitname-1.0.0-x86_64.tar.bz2
A partial kit will have "NEED_PRODUCT_PKGS" string in its name:
::
ex: kitname-1.0.0-x86_64.NEED_PRODUCT_PKGS.tar.bz2
Using Partial Kits with newer Software Versions
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
If the product packages are for a newer version or release than what specified in the partial kit tar file name, user may still be able to build a complete kit with the packages, assuming that the partial kit is compatible with those packages.
Note: Basically, the latest partial kit available online will work until there is a newer version available.
To build a complete kit with the new software, user can provide the new version and/or release of the software on the buildkit command line.
::
buildkit addpkgs <kitname.NEED_PRODUCT_PKGS.tar.bz2> --pkgdir <product package directories> \
--kitversion <new version> --kitrelease <new release>
For example, if the partial kit was created for a product version of 1.3.0.2 but wish to complete a new kit for product version 1.3.0.4 then can add "-k 1.3.0.4" to the buildkit command line.
Completing a partial kit
^^^^^^^^^^^^^^^^^^^^^^^^
Follow these steps to complete the kit build process for a partial kit.
#. copy the partial kit to a working directory
#. copy the product software packages to a convenient location or locations
#. cd to the working directory
#. Build the complete kit tarfile
::
buildkit addpkgs <kit.NEED_PRODUCT_PKGS.tar.bz2> --pkgdir <product package directories>
The Complete kit tar file will be created in the working directory

9
docs/source/advanced/kit/buildkit/validatekit.rst Normal file
View File

@ -0,0 +1,9 @@
Validate the Kit Configuration
==============================
After modify the buildkit.conf file and copy all necessary files to the kit directories, use the 'chkconfig" subcommand to validate the build configuration file.
::
buildkit chkconfig
This command will verify all required fields defined in the buildkit.conf, included all internally referenced attributes and all referenced files.
Fix any errors then rerun this command until all the fields are validated.

183
docs/source/advanced/kit/hpckit.rst Normal file
View File

@ -0,0 +1,183 @@
IBM HPC Product Software Kits
-----------------------------
Obtaining the Kits
^^^^^^^^^^^^^^^^^^
Complete kits for some product software is shipped on the product distribution media. For other software, only partial kits may be available. The partial product kits are available from the FixCentral download site. For the IBM XLF and XLC Compilers, xCAT ships Ubuntu partial Kits on Sourceforge. the current redhat7.2 partial Kits, it ships on GitHub:
General Instructions for all HPC Kits
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is a quick overview of the commands will use to add kits to the xCAT cluster and use them in the Linux OS images.
* Obtain the IBM HPC product kits
* If kits are partial kits, needs to build complete kits by combining the partial kit with the product packages
::
buildkit addpkgs <kit.NEED_PRODUCT_PKGS.tar.bz2> --pkgdir <product package directory>
* Add each kit to the xCAT database
::
addkit <product_kit_tarfile>
This will automatically unpack the tarfile, copy its contents to the correct locations for xCAT, and create the corresponding kit, kitcomponent, and kitrepo objects in the xCAT database.
* List the product kitcomponents that are available for the OS image
::
lsdef -t kitcomponent | grep <product>
* Kit components are typically named based on server role, product version, OS version, and optionally if it is for a minimal image (minimal images exclude documentation, includes, and other optional files to reduce the diskless image size). To list the details of a particular kit component
::
lsdef -t kitcomponent -o <kitcomponent name> -l
* The OS image must be defined with a supported serverrole in order to add a kit component to the image. To query the role assigned to an image
::
lsdef -t osimage -o <image> -i serverrole
And to change the serverrole of an image
::
chdef -t osimage -o <image> serverrole=<role>
* To add or update a kitcomponent in an osimage, first check if the kitcomponent is compatible with the image
::
chkkitcomp -i <image> <kitcomponent name>
If compatible, add the component to that image
::
addkitcomp -i <image> <kitcomponent name>
This will add various files for otherpkgs, postinstall, and postbootscripts to the OS image definition. To view some of these
::
lsdef -t osimage -l <image>
* If this is a diskless stateless or statelite OS image, rebuild, pack, and deploy the image
::
#genimage <image>
#packimage <image> OR #liteimg <image>
#nodeset <noderange> osimage=<image>
#rpower <noderange>
* If this is a stateful OS image, the new HPC kitcomponent software may be installed either when do a new node deployment or by using the updatenode command.
Parallel Environment Runtime Edition (PE RTE)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PE RTE software kits are available for Linux PE RTE 1.3 and newer releases on System x.
For Linux PE RTE 1.2 and older releases on System x, and for PE RTE on AIX or on System p, use the xCAT HPC Integration Support: [IBM_HPC_Stack_in_an_xCAT_Cluster]
No special procedures are required for using the PE RTE kit. If received an incomplete kit, simply follow the previously documented process for adding the product packages and building the complete kit.
**Handle the conflict between PE RTE kit and Mellanox OFED driver install script**
PPE requires the 32-bit version of libibverbs, but the default mlnxofed_ib_install which provides by xCAT to install Mellanox OFED IB driver will remove all the old ib related packages at first including the 32-bit version of libibverbs. In this case, you need to set the environment variable mlnxofed_options=--force when running the mlnxofed_ib_install. For more details, please check Managing_the_Mellanox_Infiniband_Network#Script_to_Install_the_IB_Drivers_Only_required_for_both_RHEL_and_SLES
**Installing multiple versions of PE RTE**
Starting with PE RTE 1.2.0.10, the PE RTE packages are designed so that when user upgrade the product to a newer version or release, the files from the previous version remain in the osimage along with the new version of the product.
Normally only have one version of a kitcomponent present in the xCAT osimage. When run addkitcomp to add a newer version of the kitcomponent, xCAT will first remove the old version of the kitcomponent before adding the new one. If updating a previously built diskless image or an existing diskfull node with a newer version of PE RTE, run addkitcomp to add the new PE RTE kitcomponent, xCAT will replace the previous kitcomponent with the new one. For example, if current compute osimage has PE RTE 1.3.0.1 and want to upgrade to PE RTE 1.3.0.2
::
lsdef -t osimage -o compute -i kitcomponents
kitcomponents = pperte_compute-1.3.0.1-0-rhels-6-x86_64
addkitcomp -i compute pperte_compute-1.3.0.2-0-rhels-6-x86_64
lsdef -t osimage -o compute -i kitcomponents
kitcomponents = pperte_compute-1.3.0.2-0-rhels-6-x86_64
And, running a new genimage for the previously built compute diskless image will upgrade the pperte-1.3.0.1 rpm to pperte-1.3.0.2, and will install the new ppe_rte_1302 rpm without removing the previous ppe_rte_1301 rpm.
To remove the previous version of the PE RTE product files from the osimage, need to manaully remove the rpms. In the example above, this would be something like:
chroot /install/netboot/rhels6/x86_64/compute/rootimg rpm -e ppe_rte_1302
If building a new diskless image or installing a diskfull node, and need multiple versions of PE RTE present in the image as part of the initial install, need to have multiple versions of the corresponding kitcomponent defined in the xCAT osimage definition. To add multiple versions of PE RTE kitcomponents to an xCAT osimage, add the kitcomponent using the full name with separate addkitcomp commands and specifying the -n (--noupgrade) flag. For example, to add PE RTE 1.3.0.1 and PE RTE 1.3.0.2 to your compute osimage definition
::
addkitcomp -i compute pperte_compute-1.3.0.1-0-rhels-6-x86_64
addkitcomp -i compute -n pperte_compute-1.3.0.2-0-rhels-6-x86_64
lsdef -t osimage -o compute -i kitcomponents
kitcomponents = pperte_compute-1.3.0.1-0-rhels-6-x86_64,pperte_compute-1.3.0.2-0-rhels-6-x86_64
In this example, when building a diskless image for the first time, or when deploying a diskfull node, xCAT will first install PE RTE 1.3.0.1, and then in a separate yum or zypper call, xCAT will install PE RTE 1.3.0.2. The second install will upgrade the pperte-1.3.0.1 rpm to pperte-1.3.0.2, and will install the new ppe_rte_1302 rpm without removing the previous ppe_rte_1301 rpm.
**Starting PE on cluster nodes**
The PNSD daemon is started from xinetd on compute nodes. This daemon should start automatically at node boot time. Verify that xinetd is running on nodes and PNSD daemon is active.
**POE hostlist files**
If using POE to start a parallel job, xCAT can help create the host list file. Simply run the nodels command against the desired noderange and redirect the output to a file.
::
nodels compute &gt; /tmp/hostlist
poe -hostfile /tmp/hostlist ....
**Known problems with PE RTE**
For PE RTE 1.3.0.1 to 1.3.0.6 on both System X and System P architectures, there is a known issue that when uninstall or upgrade ppe_rte_man in a diskless image, "genimage <osimage> will fail and stop at the error". To workaround this problem, will need to rerun "genimage <osimage>" to finish the remaining work.
For PE RTE 1.3.0.7 on both System X and System P architectures, there is a known issue that when uninstall or upgrade ppe_rte_man in a diskless image, "genimage <osimage>" will output errors. However, the new packages are actually upgraded, so no workaround is required and the error can be ignored with risks.
Starting with PE RTE 1.3.0.7, the src rpm is no longer required. It is not recommended build a complete kit for PE RTE 1.3.0.7 or newer using a partial PE RTE 1.3.0.6 or older kit which still require the src rpm. User should download the latest partial kit for PE RTE 1.3.0.7 or newer to build the corresponding PE RTE complete kit.
Parallel Environment Developer Edition (PE DE)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PE DE software kits are available for Linux PE DE 1.2.0.1 and newer releases on System X. Also PE DE software kits are available for Linux PE DE 1.2.0.3 and newer releases on System P.
For older Linux releases on System x and System P, and for AIX, use the xCAT HPC Integration Support: [IBM_HPC_Stack_in_an_xCAT_Cluster]
No special procedures are required for using the PE DE kit. If you received an incomplete kit, simply follow the previously documented process for adding the product packages and building the complete kit
Engineering and Scientific Subroutine Library (ESSL)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ESSL software kits are available for Linux ESSL 5.2.0.1 and newer releases on System P.
For older Linux releases on System P, and for AIX, use the xCAT HPC Integration Support: IBM_HPC_Stack_in_an_xCAT_Cluster
No special procedures are required for building the complete PESSL kit. If received an incomplete kit, simply follow the previously documented process for adding the product packages and building the complete kit
When building a diskless image or installing a diskfull node, and want ESSL installed with compiler XLC/XLF kits, there is one change when add a ESSL kitcomponent to an xCAT osimage. To add ESSL kitcomponent to an xCAT osimage, add the kitcomponent using separate addkitcomp command and specifying the -n(--noupgrade) flag. For example, to add ESSL 5.2.0.1 kitcomponent to compute osimage definition
::
addkitcomp -i compute essl_compute-5.2.0.1-rhels-6-ppc64
lsdef -t osimage -o compute -i kitcomponents
kitcomponents = essl_compute-5.2.0.1-rhels-6-ppc64
Parallel Engineering and Scientific Subroutine Library (PESSL)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PESSL software kits are available for Linux PESSL 4.2.0.0 and newer releases on System P.
For older Linux releases on System P, and for AIX, use the xCAT HPC Integration Support: IBM_HPC_Stack_in_an_xCAT_Cluster
No special procedures are required for building the PESSL complete kit. If received an incomplete kit, simply follow the previously documented process for adding the product packages and building the complete kit
When building a diskless image or installing a diskfull node, and want PESSL installed with ESSL kits, there is one change when add a PESSL kitcomponent to an xCAT osimage. To add PESSL kitcomponent to an xCAT osimage, add the kitcomponent using separate addkitcomp command and specifying the -n(--noupgrade) flag. For example, to add PESSL 4.2.0.0 kitcomponent to compute osimage definition
::
addkitcomp -i compute pessl_compute-4.2.0.0-rhels-6-ppc64
lsdef -t osimage -o compute -i kitcomponents
kitcomponents = essl_compute-4.2.0.0-rhels-6-ppc64
General Parallel File System (GPFS)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
GPFS software kits are available for Linux GPFS 3.5.0.7 and newer releases on System x.
For Linux GPFS 3.5.0.6 and older releases on System x and for AIX or Linux on System p, use the xCAT HPC Integration Support: IBM_HPC_Stack_in_an_xCAT_Cluster
The GPFS kit requires the addition of the GPFS portability layer package to be added to it. This rpm must be built on a server that matches the architecture and kernel version of all OS images that will be using this kit.
Follow this procedure before using the GPFS kit
* On a server that has the correct architecture and kernel version, manually install the GPFS rpms and build the portability layer according to the instructions documented by GPFS: General Parallel File System . After installing the GPFS rpms, check /usr/lpp/mmfs/src/README
NOTE: Building the portability layer requires that the kernel source rpms are installed on server. For example, for SLES11, make sure the kernel-source and kernel-ppc64-devel rpms are installed. For rhels6, make sure the cpp.ppc64,gcc.ppc64,gcc-c++.ppc64,kernel-devel.ppc64 and rpm-build.ppc64 are installed.
* Copy the gpfs.gplbin rpm that have successfully created to the server that are using to complete the build of GPFS kit, placing it in the same directory as other GPFS rpms.
* Complete the kit build
::
buildkit addpkgs <gpfs-kit-NEED_PRODUCT_PKGS-tarfile> -p <gpfs-rpm-directory>
At this point follow the general instructions for working with kits to add the kit to the xCAT database and add the GPFS kitcomponents to the OS images.
IBM Compilers
^^^^^^^^^^^^^
XLC and XLF software kits are available for Linux XLC 12.1.0.3 and XLF 14.1.0.3, and newer releases on System P.
For XLC 13.1.1.0 and XLF 15.1.1.0, xCAT ships partial software kits for Ubuntu on sourceforge:
https://sourceforge.net/projects/xcat/files/kits/hpckits/2.9/Ubuntu/ppc64_Little_Endian/
For XLC 13.1.2.0 and XLF 15.1.2.0, xCAT ships partial software kits for rhels7.2 on github:
For older Linux releases on System P, and for AIX, use the xCAT HPC Integration Support:
IBM_HPC_Software_Kits#Completing_the_kit_build_for_a_partial_kit
No special procedures are required for using the XLC/XLF kit. If received an incomplete kit, simply follow the previously documented process for adding the product packages and building the complete kit
Toolkit for Event Analysis and Logging (TEAL)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Teal software kits are available for Linux Teal 1.2.0.1 and newer releases on System X.
For older Linux releases on System x, and for AIX or System P, use the xCAT HPC Integration Support: [IBM_HPC_Stack_in_an_xCAT_Cluster]
No special procedures are required for using the Teal kit. If you received an incomplete kit, simply follow the previously documented process for adding the product packages and building the complete kit

15
docs/source/advanced/kit/index.rst Normal file
View File

@ -0,0 +1,15 @@
Software Kits
===================
.. toctree::
:maxdepth: 2
introduction.rst
buildkit/index.rst
addkit.rst
addkitcomp.rst
updatekit.rst
removekit.rst
hpckit.rst

67
docs/source/advanced/kit/introduction.rst Normal file
View File

@ -0,0 +1,67 @@
Introduction
============
Overview
--------
xCAT supports a unique software bundling concept called kits. A software kit combines all of the required product packages with configuration information, scripts, and other files to easily install a software product onto an xCAT node or in an xCAT OS image based on the role that node performs in the cluster. A software kit is made up of a collection of kit components, each of which is tailored to one specific environment for that particular version of the product.
A software kit is available as a tar file that is downloaded and added to your xCAT management node. The kit components resident in that kit can then be added to an existing xCAT OS image definition and then either be installed on a statefull node during node deployment, added to an active statefull node with the updatenode command, or built into a diskless OS image with the genimage command.
Typically, a software kit will contain all of the product package files. However, in some instances, software kits may be delivered as partial or incomplete kits, and not be bundled with all of the product rpms. You will then need to obtain your product packages through your reqular distribution channels, download them to a server along with the partial kit, and run the buildkit addpkgs command to build a complete kit that can be used by xCAT.
Contents of a software Kit
--------------------------
A software kit is a tar file that contains the following
**Kit Configuration File** --- A file describing the contents of this kit. This file contains following information
* Kit name, version, description, supported OS distributions, license information, and deployment parameters
* Kit repository information including name, supported OS distributions, and supported architectures
* Kit component information including name, version, description, server roles, scripts, and other data
**Kit Repositories** --- A directory for each operating system version this kit is supported in. Each directory contains all of the product software packages required for that environment along with repository metadata.
**Kit Components** --- A product "meta package" built to require all of the product software dependencies and to automatically run installation and configuration scripts.
**Kit and Kit Component Files** --- Scripts, deployment parameters, exclusion lists, and other files used to install and configure the kit components and product packages.
**Docs** (for use with PCM only) --- Product documentation shipped as HTML files that can be displayed through the PCM GUI
**Plugins** (for use with PCM only) --- xCAT plugins that can be used for additional product configuration and customization during PCM image management and node management
Kit Component in a osimage
--------------------------
Software Kits are deployed to xCAT nodes through the standard xCAT OS image deployment mechanisms. Various pieces of a kit component are inserted into the attributes of a Linux OS image definition. Some of the attributes that are modified are:
* kitcomponents - A list of the kitcomponents assigned to the OS image
* serverrole - The role of this OS image that must match one of the supported serverroles of a kitcomponent
* otherpkglist - Includes kitcomponent meta package names
* postinstall - Includes kitcomponent scripts to run during genimage
* postbootscripts - Includes kitcomponent scripts
* exlist - Exclude lists for diskless images
* otherpkgdir - Kit repositories are linked as subdirectories to this directory
When a kitcomponent is added to an OS image definition, these attributes are automatically updated.
User can then use the genimage command to install the kitcomponents into the diskless OS image, the standard node deployment process for statefull nodes, or the xCAT updatenode command to update the OS on an active compute node. Since the kitcomponent meta package defines the product packages as dependencies, the OS package manager (yum, zypper) automatically installs all the required product packages during the xCAT otherpkgs install process.
Kit Frameworks
--------------
Over time it is possible that the details of the Kit package contents and support may change. For example, there may be a need for additional information to be added etc. We refer to a particular instance of the kit support as its "framework". A particular framework is identified by a numerical value.
In order for a kit command to process a kit properly it must be compatible with the level of code that was used to build the kit.
Both the kit commands and the actual kits contain the current framework they support as well as any backlevel versions also supported.
View the supported framework and compatible framework values for a command can be used the "-v|--version" option.
::
addkit -v
addkit - xCAT Version 2.8.3 (built Sat Aug 31 11:11:31 EDT 2013)
kitframework = 2
compatible_frameworks = 0,1,2
When a Kit is being used to update an osimage, the Kit commands will check to see if the Kit framework value is compatible. To be compatible at least one of the Kit compatible_frameworks must match one of the compatible frameworks the command supports.
If the commands you are using are not compatible with the Kit you have, have to update xCAT to get the appropriate framework. Typically this will amount to updating xCAT to the most recent release.

38
docs/source/advanced/kit/removekit.rst Normal file
View File

@ -0,0 +1,38 @@
Remove Kit
----------
Removing Kit Components from an OS Image Definition
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
To remove a kit component from an OS image definition, first list the existing kitcomponents to get the name to remove:
::
lsdef -t osimage -o <image> -i kitcomponents
Then, use that name to remove it from the image definition:
::
rmkitcomp -i <image> <kitcomponent name>
Or, if know the basename of the kitcomponent, simply:
::
rmkitcomp -i <image> <kitcompent basename>
Note that this ONLY removes the kitcomponent from the image definition in the xCAT database, and it will NOT remove any product packages from the actual OS image. To set up for an uninstall of the kitcomponent from the diskless image or the statefull node, specify the uninstall option:
::
rmkitcomp -u -i <image> <kitcomponent>
The next time when run genimage for the diskless image, or updatenode to the fulldisk nodes, the software product will be un-installed.
Removing a Kit from the xCAT Management Node
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
To remove a kit from xCAT, first make sure that no OS images are assigned any of the kitcomponents. To do this, run the following database queries:
::
lsdef -t kitcomponent -w 'kitname==<kitname>'
For each kitcomponent returned:
::
lsdef -t osimage -i kitcomponents -c | grep <kitcomponent>
If no osimages have been assigned any of the kitcomponents from this kit, can safely remove the kit by running:
::
rmkit <kitname>

29
docs/source/advanced/kit/updatekit.rst Normal file
View File

@ -0,0 +1,29 @@
Complete the software update
----------------------------
updating diskless images
^^^^^^^^^^^^^^^^^^^^^^^^
For diskless OS images (stateless and statelite), run the genimage command to update the image with the new software. Example:
::
genimage <osimage>
Once the osimage has been updated you may follow the normal xCAT procedures for packing and deploying the image to your diskless nodes.
installing diskful (stateful) nodes
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
For new stateful deployments, the kitcomponent will be installed during the otherpkgs processing. Follow the xCAT procedures for your hardware type. Generally, it will be something like:
::
chdef <nodelist> provmethod=<osimage>
nodeset <nodelist> osimage
rpower <nodelist> reset
updating diskful (stateful) nodes
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
For existing active nodes, use the updatenode command to update the OS on those nodes. The updatenode command will use the osimage assigned to the node to determine the software to be updated. Once the osimage has been updated, make sure the correct image is assigned to the node and then run updatenode:
::
chdef <nodelist> provmethod=<osimage>
updatenode <nodelist>