xCAT/xcat-core
2
0
Fork 0
mirror of https://github.com/xcat2/xcat-core.git synced 2025-05-22 03:32:04 +00:00
Code Issues Releases Wiki Activity

fix Error/Warning message from "make html" output

Browse Source
This commit is contained in:
Casandra Qiu 2015-09-22 17:36:32 -04:00
parent ae94af56a2
commit c83c5a1569
13 changed files with 148 additions and 454 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
docs/source/advanced/kit/addkit.rst
View File

@ -6,9 +6,9 @@ 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>
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.)
@ -18,11 +18,11 @@ Kits are added to the kit table in the xCAT database keyed by a combination of k
Listing a kit
^^^^^^^^^^^^^
The xCAT kit object definition may be listed using the xCAT lsdef command.
::
lsdef -t kit -l <kit name>
The xCAT kit object definition may be listed using the xCAT lsdef command. ::
The contents of the kit may be listed by using the lskit command.
::
lskit <kit name>
lsdef -t kit -l <kit name>
The contents of the kit may be listed by using the lskit command. ::
lskit <kit name>

28
docs/source/advanced/kit/addkitcomp.rst
View File

@ -10,24 +10,24 @@ Some kitcomponents have dependencies on other kitcomponents. For example, a kit
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:
::
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.
::
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.
::
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.
::
The contents of the kit component may be listed by using the lskitcomponent command. ::
lskitcomp <kit component name>
@ -40,8 +40,8 @@ Currently, it is not possible to install multiple versions of a product into an
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:
::
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
@ -54,12 +54,12 @@ When building a diskless image for the first time, or when deploying a diskfull
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:
::
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:
::
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

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

@ -1,324 +0,0 @@
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

8
docs/source/advanced/kit/buildkit/buildkit-rpm.rst
View File

@ -1,7 +1,7 @@
Install the xCAT-buildkit RPM
-----------------------------
check to see if xCAT-buildkit RPM is installed in the build server
::
check to see if xCAT-buildkit RPM is installed in the build server ::
rpm -qa | grep xCAT-buildkit
@ -10,8 +10,8 @@ The xCAT-buildkit RPM is required to build a kit. It will be installed automati
#. 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
::
Once the repositories are setup, use yum to install xCAT-buildkit and all its dependencies ::
yum clean metadata
yum install xCAT-buildkit

47
docs/source/advanced/kit/buildkit/createkit.rst
View File

@ -1,16 +1,15 @@
Create a New Kit
================
Use the **buildkit** command to create a kit template directory structure
::
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:
::
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.
@ -37,8 +36,8 @@ 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** --- 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
@ -49,8 +48,8 @@ The sample buildkit.conf file contains a description of all the supported attrib
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** --- 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
@ -63,8 +62,8 @@ The sample buildkit.conf file contains a description of all the supported attrib
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** --- 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
@ -94,45 +93,47 @@ The sample buildkit.conf file contains a description of all the supported attrib
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
**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.
#. 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:
kitpackage:
filename=pperte-*.x86_64.rpm
kitrepoid=rhels6_x86_64,sles11_x86_64
kitpackage:
kitpackage:
filename=pperteman-*.x86_64.rpm
kitrepoid=rhels6_x86_64,sles11_x86_64
kitpackage:
kitpackage:
filename=ppertesamples-*.x86_64.rpm
kitrepoid=rhels6_x86_64,sles11_x86_64
kitpackage:
kitpackage:
filename=ppe_rte_*.x86_64.rpm
kitrepoid=rhels6_x86_64,sles11_x86_64
kitpackage:
kitpackage:
filename=ppe_rte_man-*.x86_64.rpm
kitrepoid=rhels6_x86_64,sles11_x86_64
kitpackage:
kitpackage:
filename=ppe_rte_samples-*.x86_64.rpm
kitrepoid=rhels6_x86_64,sles11_x86_64
kitpackage:
kitpackage:
filename=src-*.i386.rpm
kitrepoid=rhels6_x86_64,sles11_x86_64
# License rpm gets placed in all repos
kitpackage:
#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.
::
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

1
docs/source/advanced/kit/buildkit/index.rst
View File

@ -9,6 +9,5 @@ Building Kits
validatekit.rst
kitrepo.rst
kittarfile.rst
kitconfile.rst

13
docs/source/advanced/kit/buildkit/kitrepo.rst
View File

@ -5,21 +5,22 @@ After the buildkit configuration file is validated, run the "buildrepo" subcomma
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:
::
To list the repos defined in the buildkit.conf: ::
buildkit listrepo
To build the repositories, specifiy a particular reporitory:
::
To build the repositories, specifiy a particular reporitory: ::
buildkit buildrepo <kit repo name>
or build all the repositories for this kit:
::
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

23
docs/source/advanced/kit/buildkit/kittarfile.rst
View File

@ -1,16 +1,16 @@
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.
::
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:
::
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:
::
A partial kit will have "NEED_PRODUCT_PKGS" string in its name: ::
ex: kitname-1.0.0-x86_64.NEED_PRODUCT_PKGS.tar.bz2
@ -20,8 +20,8 @@ If the product packages are for a newer version or release than what specified i
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.
::
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>
@ -31,11 +31,14 @@ For example, if the partial kit was created for a product version of 1.3.0.2 but
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
::
#. 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

4
docs/source/advanced/kit/buildkit/validatekit.rst
View File

@ -1,7 +1,7 @@
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.
::
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.

92
docs/source/advanced/kit/hpckit.rst
View File

@ -9,44 +9,55 @@ 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
::
* 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
::
* 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
::
* 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
::
* 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
::
* 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
::
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
::
* 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
::
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
::
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
::
* 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]
@ -61,8 +72,8 @@ PPE requires the 32-bit version of libibverbs, but the default mlnxofed_ib_insta
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
::
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
@ -71,12 +82,12 @@ Normally only have one version of a kitcomponent present in the xCAT osimage. Wh
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:
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
::
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
@ -90,8 +101,8 @@ The PNSD daemon is started from xinetd on compute nodes. This daemon should star
**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.
::
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 ....
@ -119,8 +130,8 @@ For older Linux releases on System P, and for AIX, use the xCAT HPC Integration
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
::
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
@ -134,8 +145,8 @@ For older Linux releases on System P, and for AIX, use the xCAT HPC Integration
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
::
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
@ -149,13 +160,15 @@ For Linux GPFS 3.5.0.6 and older releases on System x and for AIX or Linux on Sy
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.
* 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
::
* 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
@ -164,11 +177,12 @@ 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 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
For older Linux releases on System P, and for AIX, use the xCAT HPC Integration Support
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

4
docs/source/advanced/kit/introduction.rst
View File

@ -56,8 +56,8 @@ In order for a kit command to process a kit properly it must be compatible with
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.
::
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

28
docs/source/advanced/kit/removekit.rst
View File

@ -3,20 +3,20 @@ 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:
::
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:
::
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:
::
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:
::
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.
@ -24,15 +24,15 @@ The next time when run genimage for the diskless image, or updatenode to the ful
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:
::
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:
::
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:
::
If no osimages have been assigned any of the kitcomponents from this kit, can safely remove the kit by running: ::
rmkit <kitname>

12
docs/source/advanced/kit/updatekit.rst
View File

@ -4,8 +4,8 @@ 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:
::
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.
@ -13,8 +13,8 @@ Once the osimage has been updated you may follow the normal xCAT procedures for
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:
::
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
@ -22,8 +22,8 @@ For new stateful deployments, the kitcomponent will be installed during the othe
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:
::
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>