mirror of
https://github.com/xcat2/xcat-core.git
synced 2025-08-06 11:35:14 +00:00
Modify the changes from BaiYuan's notes
This commit is contained in:
Casandra Qiu
@@ -1,8 +1,8 @@
|
||||
Add a Kit to xCAT
|
||||
-----------------
|
||||
Adding 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.
|
||||
|
||||
@@ -17,7 +17,7 @@ It will also add the kit to the xCAT database by creating xCAT object definition
|
||||
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>
|
||||
|
||||
@@ -2,7 +2,7 @@ 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.
|
||||
|
||||
@@ -21,7 +21,7 @@ If the kit component is compatible then add the kitcomponent to the OS image def
|
||||
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>
|
||||
@@ -32,7 +32,7 @@ The contents of the kit component may be listed by using the lskitcomponent comm
|
||||
|
||||
|
||||
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.
|
||||
|
||||
@@ -52,7 +52,7 @@ By default, when a newer version/release of a kitcomponent is added to an existi
|
||||
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: ::
|
||||
|
||||
|
||||
@@ -1,18 +1,26 @@
|
||||
Install the xCAT-buildkit RPM
|
||||
Installing the xCAT-buildkit
|
||||
-----------------------------
|
||||
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 ::
|
||||
Once the repositories are setup, install xCAT-buildkit and all its dependencies.
|
||||
|
||||
**[RHEL]** ::
|
||||
|
||||
yum clean metadata
|
||||
yum install xCAT-buildkit
|
||||
|
||||
For sles, use zypper install and for Ubuntu, use apt-get to install xCAT-buildkit
|
||||
**[SLES]** ::
|
||||
|
||||
zypper clean
|
||||
zypper install xCAT-buildkit
|
||||
|
||||
|
||||
**[UBUNTU]** ::
|
||||
|
||||
apt-get clean
|
||||
apt-get install xCAT-buildkit
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
Create a New Kit
|
||||
================
|
||||
Creating a New Kit
|
||||
-------------------
|
||||
|
||||
Use the **buildkit** command to create a kit template directory structure ::
|
||||
|
||||
@@ -7,32 +7,40 @@ Use the **buildkit** command to create a kit template directory structure ::
|
||||
|
||||
|
||||
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.
|
||||
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)
|
||||
**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.
|
||||
|
||||
* **kit_repodir** - This directory stores the fully built Kit Package Repositories
|
||||
* **<kitbasename>** - This directory stores the contents of the Kit tarfile before it is tar'red up.
|
||||
|
||||
**<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.
|
||||
|
||||
@@ -127,11 +135,11 @@ The sample buildkit.conf file contains a description of all the supported attrib
|
||||
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.
|
||||
**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:
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
Build the Kit Package Repositories
|
||||
==================================
|
||||
Building 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.
|
||||
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.
|
||||
|
||||
@@ -17,11 +17,11 @@ or build all the repositories for this kit: ::
|
||||
|
||||
buildkit buildrep all
|
||||
|
||||
The repository would be built in <Kit directory location>/build/kit_repodir/ subdirectory.
|
||||
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> .
|
||||
#. 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.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
Build the Kit Tarfile
|
||||
=====================
|
||||
Building 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
|
||||
|
||||
@@ -15,7 +15,7 @@ A partial kit will have "NEED_PRODUCT_PKGS" string in its name: ::
|
||||
|
||||
|
||||
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.
|
||||
@@ -29,7 +29,7 @@ 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
|
||||
|
||||
@@ -1,6 +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. ::
|
||||
Validating 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
|
||||
|
||||
|
||||
@@ -2,12 +2,15 @@ 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 ::
|
||||
|
||||
@@ -47,26 +50,26 @@ This is a quick overview of the commands will use to add kits to the xCAT cluste
|
||||
|
||||
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 OS image, rebuild, pack, and deploy the image ::
|
||||
|
||||
#genimage <image>
|
||||
#packimage <image> OR #liteimg <image>
|
||||
#nodeset <noderange> osimage=<image>
|
||||
#rpower <noderange>
|
||||
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.
|
||||
* If this is a diskful 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]
|
||||
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 Documentation.
|
||||
|
||||
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
|
||||
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, need to set the environment variable ``mlnxofed_options=--force`` when running the mlnxofed_ib_install.
|
||||
|
||||
**Installing multiple versions of PE RTE**
|
||||
|
||||
@@ -86,7 +89,7 @@ To remove the previous version of the PE RTE product files from the osimage, nee
|
||||
|
||||
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
|
||||
@@ -108,61 +111,61 @@ If using POE to start a parallel job, xCAT can help create the host list file. S
|
||||
|
||||
**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.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.
|
||||
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]
|
||||
For older Linux releases on System x and System P, and for AIX, use the xCAT HPC Integration Support Documentation.
|
||||
|
||||
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
|
||||
For older Linux releases on System P, and for AIX, use the xCAT HPC Integration Support Documentation.
|
||||
|
||||
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
|
||||
|
||||
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
|
||||
For older Linux releases on System P, and for AIX, use the xCAT HPC Integration Support Documentation.
|
||||
|
||||
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
|
||||
|
||||
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
|
||||
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 Documentation.
|
||||
|
||||
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.
|
||||
* 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 ::
|
||||
|
||||
@@ -172,7 +175,7 @@ Follow this procedure before using the GPFS kit
|
||||
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.
|
||||
|
||||
@@ -187,10 +190,10 @@ For older Linux releases on System P, and for AIX, use the xCAT HPC Integration
|
||||
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]
|
||||
For older Linux releases on System x, and for AIX or System P, use the xCAT HPC Integration Support Documentation.
|
||||
|
||||
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
|
||||
|
||||
|
||||
@@ -9,7 +9,7 @@ xCAT supports a unique software bundling concept called kits. A software kit com
|
||||
|
||||
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.
|
||||
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 packages. 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
|
||||
@@ -46,17 +46,17 @@ Software Kits are deployed to xCAT nodes through the standard xCAT OS image depl
|
||||
|
||||
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.
|
||||
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, apt-get) 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.
|
||||
In order 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. ::
|
||||
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)
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
Remove Kit
|
||||
----------
|
||||
Removing 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
|
||||
@@ -22,7 +22,7 @@ Note that this ONLY removes the kitcomponent from the image definition in the xC
|
||||
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: ::
|
||||
|
||||
|
||||
@@ -1,17 +1,17 @@
|
||||
Complete the software update
|
||||
----------------------------
|
||||
Completing 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, 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
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
installing diskful 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: ::
|
||||
|
||||
@@ -19,8 +19,8 @@ For new stateful deployments, the kitcomponent will be installed during the othe
|
||||
nodeset <nodelist> osimage
|
||||
rpower <nodelist> reset
|
||||
|
||||
updating diskful (stateful) nodes
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
updating diskful 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: ::
|
||||
|
||||
|
||||
Reference in New Issue
Block a user