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

Update the documentation pages to be consistent

Browse Source 
and spell diskful instead of diskfull
s
This commit is contained in:
Victor Hu 2015-10-24 20:48:13 -04:00
parent 1c0bd13686
commit 3924e742b1
14 changed files with 32 additions and 32 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/source/advanced/hierarchy/appendix_b_diagnostics.rst
View File

@ -12,7 +12,7 @@ Appendix B: Diagnostics
xCAT rpms in :ref:`setup_service_node_stateful_label`. If rpms
missing check your install setup as outlined in Build the Service Node
Stateless Image for diskless or :ref:`setup_service_node_stateful_label` for
diskfull installs.
diskful installs.
* **otherpkgs(including xCAT rpms) installation failed on the SN** --The OS
repository is not created on the SN. When the "yum" command is processing
the dependency, the rpm packages (including expect, nmap, and httpd, etc)

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

@ -49,7 +49,7 @@ By default, when a newer version/release of a kitcomponent is added to an existi
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.
When building a diskless image for the first time, or when deploying a diskful 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
```````````````````````````````````````````````````````````````
@ -63,4 +63,4 @@ If the kit does contain a deployment parameter file, the contents of the file wi
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.
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 diskful node. Changing these values will cause problems with genimage, updatenode, and other xCAT deployment commands.

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

@ -75,7 +75,7 @@ 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 diskful 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
@ -89,14 +89,14 @@ 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 diskful 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.
In this example, when building a diskless image for the first time, or when deploying a diskful 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**
@ -133,7 +133,7 @@ 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 diskful 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
@ -148,7 +148,7 @@ 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 diskful 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

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

@ -93,7 +93,7 @@ Install and Configure the Golden Client
The Golden Client acts as a regular node for xCAT, just have some extra rpms to support clone. When you deploy golden client with xCAT, you just need to add a few additional definitions to the image which will be used to deploy golden client.
For information of how to install a regular node, please refer to section :ref:`Diskful Installation <diskfull_installation>`
For information of how to install a regular node, please refer to section :ref:`Diskful Installation <diskful_installation>`
For support clone, add 'otherpkglist' and 'otherpkgdir' attributes to the image definition which will be used to deploy golden client, then deploy golden client as normal. then the golden client will have extra rpms to support clone. If you have deployed your golden client already, using 'updatenode' command to push these extra rpms to golden client. CentOS share the same pkglist file with RHEL. For example:

2
docs/source/guides/admin-guides/basic_concepts/network_planning/xcat_net_planning.rst
View File

@ -38,7 +38,7 @@ Everyone wants their cluster to be as reliable and available as possible, but th
This approach is most often used with stateless nodes because that environment is more dynamic. It can possibly be used with stateful nodes (with a little more effort), but that type of node doesn't netboot nearly as often so a more manual operation (snmove) is needed in that case move a node to different SNs.
It is best to have the SNs be as robust as possible, for example, if they are diskfull, configure them with at least 2 disks that are RAID'ed together.
It is best to have the SNs be as robust as possible, for example, if they are diskful, configure them with at least 2 disks that are RAID'ed together.
In smaller clusters, the management node (MN) can be part of the SN pool with one other SN.

2
docs/source/guides/admin-guides/basic_concepts/xcat_object/node.rst
View File

@ -45,7 +45,7 @@ Key Attrubutes
+-------------------------------------------------+-----------------------------------+
* postscripts:
Comma separated list of scripts, that should be run on this node after diskfull installation or diskless boot, finish some system configuration and maintenance work. For installation of RedHat, CentOS, Fedora, the scripts will be run before the reboot. For installation of SLES, the scripts will be run after the reboot but before the init.d process.
Comma separated list of scripts, that should be run on this node after diskful installation or diskless boot, finish some system configuration and maintenance work. For installation of RedHat, CentOS, Fedora, the scripts will be run before the reboot. For installation of SLES, the scripts will be run after the reboot but before the init.d process.
* postbootscripts:
Comma separated list of scripts, that should be run on this node as a SysV init job on the 1st reboot after installation or diskless boot, finish some system configuration and maintenance work.

8
docs/source/guides/admin-guides/manage_clusters/common/deployment/driver_update_disk.rst
View File

@ -62,7 +62,7 @@ If 'osupdatename' is specified, the kernel shipped with the 'osupdatename' will
.. END_locate_driver_for_RPM
.. BEGIN_inject_into_initrd__for_diskfull_for_DUD
.. BEGIN_inject_into_initrd__for_diskful_for_DUD
- If specifying the driver disk location in the osimage, there are two ways to inject drivers:
@ -79,9 +79,9 @@ If 'osupdatename' is specified, the kernel shipped with the 'osupdatename' will
Running 'nodeset <nodenrage>' in anyway will load the driver disk
.. END_inject_into_initrd__for_diskfull_for_DUD
.. END_inject_into_initrd__for_diskful_for_DUD
.. BEGIN__inject_into_initrd__for_diskfull_for_RPM
.. BEGIN__inject_into_initrd__for_diskful_for_RPM
There are two ways to inject drivers:
@ -97,7 +97,7 @@ There are two ways to inject drivers:
**Note:** 'geninitrd' + 'nodeset --noupdateinitrd' is useful when you need to run nodeset frequently for diskful nodes. 'geninitrd' only needs to be run once to rebuild the initrd and 'nodeset --noupdateinitrd' will not touch the initrd and kernel in /tftpboot/xcat/osimage/<osimage name>/.
The option '--ignorekernelchk' is used to skip the kernel version checking when injecting drivers from osimage.driverupdatesrc. To use this flag, you should make sure the drivers in the driver rpms are usable for the target kernel.
.. END_inject_into_initrd__for_diskfull_for_RPM
.. END_inject_into_initrd__for_diskful_for_RPM
.. BEGIN_inject_into_initrd__for_diskless_for_DUD

8
docs/source/guides/admin-guides/manage_clusters/common/deployment/generate_img.rst
View File

@ -38,7 +38,7 @@ Note: There is a current restriction that exported 2.7 xCAT images cannot be imp
We want to create a system of making xCAT images more portable so that they can be shared and prevent people from reinventing the wheel. While every install is unique there are some things that can be shared among different sites to make images more portable. In addition, creating a method like this allows us to create snap shots of images we may find useful to revert to in different situations.
Image exporting and importing are supported for statefull (diskfull) and stateless (diskless) clusters. The following documentation will show how to use :doc:`imgexport </guides/admin-guides/references/man1/imgexport.1>` to export images and :doc:`imgimport </guides/admin-guides/references/man1/imgimport.1>` to import images.
Image exporting and importing are supported for stateful (diskful) and stateless (diskless) clusters. The following documentation will show how to use :doc:`imgexport </guides/admin-guides/references/man1/imgexport.1>` to export images and :doc:`imgimport </guides/admin-guides/references/man1/imgimport.1>` to import images.
Exporting an image
@ -70,7 +70,7 @@ Exporting an image
imgexport myimage -p node1 -e /install/postscripts/myscript1 -e /install/postscripts/myscript2
(-p and -e are optional)
A bundle file called myimage.tgz will be created under the current directory. The bundle file contains the ramdisk, boot kernel, the root image and all the configuration files for generating the image for a diskless cluster. For diskfull, it contains the kickstart/autoyast configuration file. (see appendix). The -p flag puts the names of the postscripts for node1 into the image bundle. The -e flags put additional files into the bundle. In this case two postscripts myscript1 and myscript2 are included.
A bundle file called myimage.tgz will be created under the current directory. The bundle file contains the ramdisk, boot kernel, the root image and all the configuration files for generating the image for a diskless cluster. For diskful, it contains the kickstart/autoyast configuration file. (see appendix). The -p flag puts the names of the postscripts for node1 into the image bundle. The -e flags put additional files into the bundle. In this case two postscripts myscript1 and myscript2 are included.
This image can now be used on other systems.
Importing an image
@ -106,7 +106,7 @@ Skip this section if you want to use the image as is.
* Modify .otherpkgs.pkglist to add or remove packages from other sources. Please refer to ``Using_Updatenode`` for details
* For diskfull, modify the .tmpl file to change the kickstart/autoyast configuration
* For diskful, modify the .tmpl file to change the kickstart/autoyast configuration
* Modify .synclist file to change the files that are going to be synchronized to the nodes
@ -187,7 +187,7 @@ Exported files
The following files will be exported, assuming x is the profile name:
For diskfull: ::
For diskful: ::
x.pkglist
x.otherpkgs.pkglist

4
docs/source/guides/admin-guides/manage_clusters/common/deployment/prepostscripts/post_script.rst
View File

@ -12,7 +12,7 @@ There are two types of scripts in the postscripts table ( postscripts and postbo
``man postscripts``
* **postscripts attribute** - List of scripts that should be run on this node after diskfull installation or diskless boot.
* **postscripts attribute** - List of scripts that should be run on this node after diskful installation or diskless boot.
* **[RHEL]**
@ -22,7 +22,7 @@ There are two types of scripts in the postscripts table ( postscripts and postbo
Postscripts will be run after the reboot but before the init.d process. For Linux diskless deployment, the postscripts will be run at the init.d time, and xCAT will automatically add the list of postscripts from the postbootscripts attribute to run after postscripts list.
* **postbootscripts attribute** - list of postbootscripts that should be run on this Linux node at the init.d time after diskfull installation reboot or diskless boot
* **postbootscripts attribute** - list of postbootscripts that should be run on this Linux node at the init.d time after diskful installation reboot or diskless boot
* **xCAT**, by default, for diskful installs only runs the postbootscripts on the install and not on reboot. In xCAT a site table attribute runbootscripts is available to change this default behavior. If set to yes, then the postbootscripts will be run on install and on reboot.
**xCAT automatically adds the postscripts from the xcatdefaults.postscripts attribute of the table to run first on the nodes after install or diskless boot.**

8
docs/source/guides/admin-guides/manage_clusters/common/deployment/syncfile/syncfile_install.rst
View File

@ -19,8 +19,8 @@ If using Service nodes to manage you nodes, you should make sure that the servic
``updatenode compute -f``
Diskfull installation
~~~~~~~~~~~~~~~~~~~~~
Diskful installation
~~~~~~~~~~~~~~~~~~~~
@ -39,9 +39,9 @@ Make sure your postscripts table has the syncfiles postscript listed
Diskless Installation
~~~~~~~~~~~~~~~~~~~~~
The diskless boot is similar with the diskfull installation for the synchronizing files operation, except that the packimage commands will sync files to the root directories of image during the creating image process.
The diskless boot is similar with the diskful installation for the synchronizing files operation, except that the packimage commands will sync files to the root directories of image during the creating image process.
Creating the synclist file as the steps in Diskfull installation section, then the synced files will be synced to the os image during the packimage and mkdsklsnode commands running.
Creating the synclist file as the steps in Diskful installation section, then the synced files will be synced to the os image during the packimage and mkdsklsnode commands running.
Also the files will always be re-synced during the booting up of the diskless node.

2
docs/source/guides/admin-guides/manage_clusters/common/deployment/syncfile/syncfile_synclist_file.rst
View File

@ -207,7 +207,7 @@ If the provisioning method for the node is install,or netboot then the path to t
<profile>,<os>and <arch> are what you set for the node
For example:
The location of synclist file for the diskfull installation of <os> with 'compute' as the profile ::
The location of synclist file for the diskful installation of <os> with 'compute' as the profile ::
/install/custom/<inst_type>/<distro>/<profile>.<os>.synclist

2
docs/source/guides/admin-guides/manage_clusters/common/deployment/syncfile/syncfile_updatenode.rst
View File

@ -3,7 +3,7 @@ Run the Syncing File action in the updatenode process
If run ``updatenode`` command with -F option, it syncs files which configured in the synclist to the nodes. ``updatenode`` does not sync images, use ``xdcp -i -F`` option to sync images.
``updatenode`` can be used to sync files to to diskfull or diskless nodes. ``updatenode`` cannot be used to sync files to statelite nodes.
``updatenode`` can be used to sync files to to diskful or diskless nodes. ``updatenode`` cannot be used to sync files to statelite nodes.
Steps to make the Syncing File working in the ``updatenode -F`` command:

8
docs/source/guides/admin-guides/manage_clusters/ppc64le/diskful/customize_image/driver_update_disk.rst
View File

@ -31,15 +31,15 @@ For Driver Update Disk
``````````````````````
.. include:: ../../../common/deployment/driver_update_disk.rst
:start-after: BEGIN_inject_into_initrd__for_diskfull_for_DUD
:end-before: END_inject_into_initrd__for_diskfull_for_DUD
:start-after: BEGIN_inject_into_initrd__for_diskful_for_DUD
:end-before: END_inject_into_initrd__for_diskful_for_DUD
For Driver RPM Packages
```````````````````````
.. include:: ../../../common/deployment/driver_update_disk.rst
:start-after: BEGIN__inject_into_initrd__for_diskfull_for_RPM
:end-before: END_inject_into_initrd__for_diskfull_for_RPM
:start-after: BEGIN__inject_into_initrd__for_diskful_for_RPM
:end-before: END_inject_into_initrd__for_diskful_for_RPM
Notes
-----

2
docs/source/guides/admin-guides/manage_clusters/ppc64le/diskful/index.rst
View File

@ -1,4 +1,4 @@
.. _diskfull_installation:
.. _diskful_installation:
Diskful Installation
====================