Merge tag '2.16.3' into lenovobuild

Version

@@ -1 +1 @@
-2.16.2
+2.16.3

docs/requirements.txt

@@ -0,0 +1 @@
+docutils==0.17

docs/source/advanced/hierarchy/databases/mysql_install.rst

@@ -37,8 +37,8 @@ Red Hat Enterprise Linux
 
 * For RHEL 8, MariaDB is shipped. Using ``dnf``, ensure that the following packages are installed on the management node: ::
 
-       mariadb-server-5.*
-       mariadb-5.*
+       mariadb-server-10.*
+       mariadb-10.*
        perl-DBD-MySQL*
        mariadb-connector-odbc-*
 

docs/source/advanced/sysclone/sysclone.rst

@@ -1,6 +1,8 @@
 Using System Clone to Deploy Diskful Node
 =========================================
 
+.. note:: This feature has been deprecated
+
 When we want to deploy large numbers of nodes which have the same configuration, the simplest way is to clone. This means the user can customize and tweak one node's configuration according to his needs. They can verify it's proper operation, then make this node as template. They can capture an osimage from this template node, and deploy the rest of the nodes with this osimage quickly. xCat (2.8.2 and above) provides this feature which we call Sysclone to help you handle this scenario.
 
 List of Supported Arch and OS

docs/source/conf.py

@@ -59,7 +59,7 @@
 # The short X.Y version.
 version = '2'
 # The full version, including alpha/beta/rc tags.
-release = '2.16.2'
+release = '2.16.3'
 
 # The language for content autogenerated by Sphinx. Refer to documentation
 # for a list of supported languages.

docs/source/guides/admin-guides/manage_clusters/common/deployment/cfg_partition.rst

@@ -369,6 +369,8 @@ To generate the configuration, run the ``nodeset`` command: ::
 
 .. note:: **RedHat:** Running ``nodeset`` will generate the ``/install/autoinst`` file for the node.  It will replace the ``#XCAT_PARTITION_START#`` and ``#XCAT_PARTITION_END#`` directives with the contents of your custom partition file.
 
+.. note:: **SLES:** Running ``nodeset`` will generate the ``/install/autoinst`` file for the node.  It will replace the ``#XCAT-PARTITION-START#`` and ``#XCAT-PARTITION-END#`` directives with the contents of your custom partition file. Do not include ``<partitioning config:type="list">`` and ``</partitioning>`` tags, they will be added by xCAT.
+
 .. note:: **Ubuntu:** Running ``nodeset`` will generate the ``/install/autoinst`` file for the node. It will write the partition file to ``/tmp/partitionfile`` and replace the ``#XCA_PARTMAN_RECIPE_SCRIPT#`` directive in ``/install/autoinst/<node>.pre`` with the contents of your custom partition file. 
 
 .. END_partition_definition_file_Associate_partition_file_with_osimage_common

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

@@ -397,7 +397,7 @@ Kinds of variables in the template
     NTYPE=$NTYPE
     export NTYPE
 
-**Type 2:** This is the syntax to get the value of one attribute from the ``<tablename>`` and its key is ``$NODE``. It does not support tables with two keys. Some of the tables with two keys are ``litefile``, ``prodkey``, ``deps``, ``monsetting``, ``mpa``, ``networks``. ::
+**Type 2:** This is the syntax to get the value of one attribute from the ``<tablename>`` and its key is ``$NODE``. It does not support tables with two keys. Some of the tables with two keys are ``litefile``, ``prodkey``, ``deps``, ``monsetting``, ``mpa``, ``networks``. It does not support tables with keys other than ``$NODE``. Some of the tables that do not use ``$NODE`` as the key, are ``passwd``, ``rack``, ``token`` ::
 
     VARNAME=#TABLE:tablename:$NODE:attribute#
 

docs/source/guides/admin-guides/references/man1/makentp.1.rst

@@ -25,14 +25,14 @@ DESCRIPTION
 
 \ **makentp**\  command sets up the NTP server on the xCAT management node and the service node.
 
-By default, it sets up the NTP server for xCAT management node. If -a flag is specified, the command will setup the ntp servers for management node as well as all the service nodes that have \ *servicenode.ntpserver*\  set. It honors the site table attributes \ *extntpservers*\  and \ *ntpservers*\  described below:
+By default, it sets up the NTP server for xCAT management node. If \ **-a**\  flag is specified, the command will setup the ntp servers for management node as well as all the service nodes that have \ *servicenode.ntpserver*\  set. It honors the site table attributes \ *extntpservers*\  and \ *ntpservers*\  described below:
 
 
 \ *site.extntpservers*\  -- the NTP servers for the management node to sync with. If it is empty then the NTP server will use the management node's own hardware clock to calculate the system date and time.
 
 \ *site.ntpservers*\  -- the NTP servers for the service node and compute node to sync with. The keyword <xcatmaster> means that the node's NTP server is the node that is managing it (either its service node or the management node).
 
-To setup NTP on the compute node, add \ **setupntp**\  postscript to the \ *postscripts*\  table and run \ *updatenode node -P setupntp*\  command.
+To setup NTP on the compute node, add \ *setupntp*\  postscript to the \ *postscripts*\  table and run \ **updatenode node -P setupntp**\  command.
 
 
 *******
@@ -43,7 +43,7 @@ OPTIONS
 
 \ **-a|-**\ **-all**\ 
 
- Setup NTP servers for both management node and the service node. If management node has SLES installed and used as \ *ntpservers*\ , it is recommanded to use the \ **setupntp**\  postscript to set up NTP server for service nodes.
+ Setup NTP servers for both management node and the service node. If management node has SLES installed and used as \ *ntpservers*\ , it is recommanded to use the \ *setupntp*\  postscript to set up NTP server for service nodes.
 
 
 

docs/source/guides/admin-guides/references/man5/nodetype.5.rst

@@ -44,7 +44,7 @@ nodetype Attributes:
 
 \ **os**\ 
 
- The operating system deployed on this node.  Valid values: AIX, rhels\*,rhelc\*, rhas\*,centos\*,SL\*, fedora\*, sles\* (where \* is the version #). As a special case, if this is set to "boottarget", then it will use the initrd/kernel/parameters specified in the row in the boottarget table in which boottarget.bprofile equals nodetype.profile.
+ The operating system deployed on this node.  Valid values: AIX, rhels\*,rhelc\*, rhas\*,centos\*,rocky\*,SL\*, fedora\*, sles\* (where \* is the version #). As a special case, if this is set to "boottarget", then it will use the initrd/kernel/parameters specified in the row in the boottarget table in which boottarget.bprofile equals nodetype.profile.
 
 
 

docs/source/guides/admin-guides/references/man5/osimage.5.rst

@@ -104,7 +104,7 @@ osimage Attributes:
 
 \ **osvers**\ 
 
- The Linux operating system deployed on this node.  Valid values:  rhels\*,rhelc\*, rhas\*,centos\*,SL\*, fedora\*, sles\* (where \* is the version #).
+ The Linux operating system deployed on this node.  Valid values:  rhels\*,rhelc\*, rhas\*,centos\*,rocky\*,SL\*, fedora\*, sles\* (where \* is the version #).
 
 
 

docs/source/guides/admin-guides/references/man5/site.5.rst

@@ -261,6 +261,10 @@ site Attributes:
                      directory on the stateless and statelite nodes after the
                      postscripts are run. Default is no.
   
+   cleanupdiskfullxcatpost:  (yes/1 or no/0). Set to 'yes' or '1' to clean up the /xcatpost
+                     directory on the diskfull nodes after the
+                     postscripts are run with no errors. Default is no.
+  
    db2installloc:  The location which the service nodes should mount for
                    the db2 code to install. Format is hostname:/path.  If hostname is
                    omitted, it defaults to the management node. Default is /mntdb2.

docs/source/guides/admin-guides/references/man5/vm.5.rst

@@ -191,7 +191,19 @@ vm Attributes:
 
 \ **othersettings**\ 
 
- This allows specifying a semicolon delimited list of key->value pairs to include in a vmx file of VMware or KVM. For partitioning on normal power machines, this option is used to specify the hugepage and/or bsr information, the value is like:'hugepage:1,bsr=2'. For KVM cpu mode use either:'cpumode:host-passthrough' or 'cpumode:host-model'. This improves performance on x86 VMs significantly. For KVM cpu pinning, this option is used to specify the physical cpu set on the host, the value is like:"vcpupin:'0-15,^8'",Its syntax is a comma separated list and a special markup using '-' and '^' (ex. '0-4', '0-3,^2') can also be allowed, the '-' denotes the range and the '^' denotes exclusive. For KVM memory binding, the value is like:'membind:0', restrict a guest to allocate memory from the specified set of NUMA nodes. For PCI passthrough, the value is like:'devpassthrough:pci_0001_01_00_0,pci_0000_03_00_0', the value for PCI device format also can be like:'devpassthrough:0001:01:00.1', the PCI devices are assigned to a virtual machine, and the virtual machine can use this I/O exclusively, the devices list are a list of PCI device names delimited with comma, the PCI device names can be obtained by running \ **virsh nodedev-list**\  on the host.
+ This is a semicolon-delimited list of key-value pairs to be included in a vmx file of VMware or KVM. DO NOT use 'chdef <node> -p|-m vmothersetting=...' to add options to it or delete options from it because chdef uses commas, not semicolons, to separate items.
+           Hugepage on POWER systems:
+              Specify the hugepage and/or bsr (Barrier Synchronization Register) values, e.g., 'hugepage:1,bsr:2'.
+           KVM CPU mode:
+              Specify how the host CPUs are utilized, e.g., 'cpumode:host-passthrough', 'cpumode:host-model'. With the passthrough mode, the performance of x86 VMs can be improved significantly.
+           KVM CPU pinning:
+              Specify which host CPUs are used, e.g., 'vcpupin:'0-15,^8', where '-' denotes the range and '^' denotes exclusion. This option allows a comma-delimited list.
+           KVM memory binding:
+              Specify which nodes that host memory are used, e.g., 'membind:0', where the memory in node0 of the hypervisor is used. /sys/devices/system/node has node0 and node8 on some POWER systems, node0 and node1 on some x86_64 systems. This option allows a guest VM to access specific memory regions.
+           PCI passthrough:
+              PCI devices can be assigned to a virtual machine for exclusive usage, e.g., 'devpassthrough:pci_0001_01_00_0,pci_0000_03_00_0'. A PCI device can also be expressed as 'devpassthrough:0001:01:00.1'. The devices are put in a comma-delimited list. The PCI device names can be obtained by running \ **virsh nodedev-list**\  on the host.
+           VM machine type:
+              Specify a machine type for VM creation on the host, e.g., 'machine:pc'. Typical machine types are pc, q35, and pseries.
 
 
 

docs/source/guides/admin-guides/references/man7/group.7.rst

@@ -277,7 +277,19 @@ group Attributes:
 
 \ **dockerflag**\  (vm.othersettings)
 
- This allows specifying a semicolon delimited list of key->value pairs to include in a vmx file of VMware or KVM. For partitioning on normal power machines, this option is used to specify the hugepage and/or bsr information, the value is like:'hugepage:1,bsr=2'. For KVM cpu mode use either:'cpumode:host-passthrough' or 'cpumode:host-model'. This improves performance on x86 VMs significantly. For KVM cpu pinning, this option is used to specify the physical cpu set on the host, the value is like:"vcpupin:'0-15,^8'",Its syntax is a comma separated list and a special markup using '-' and '^' (ex. '0-4', '0-3,^2') can also be allowed, the '-' denotes the range and the '^' denotes exclusive. For KVM memory binding, the value is like:'membind:0', restrict a guest to allocate memory from the specified set of NUMA nodes. For PCI passthrough, the value is like:'devpassthrough:pci_0001_01_00_0,pci_0000_03_00_0', the value for PCI device format also can be like:'devpassthrough:0001:01:00.1', the PCI devices are assigned to a virtual machine, and the virtual machine can use this I/O exclusively, the devices list are a list of PCI device names delimited with comma, the PCI device names can be obtained by running \ **virsh nodedev-list**\  on the host.
+ This is a semicolon-delimited list of key-value pairs to be included in a vmx file of VMware or KVM. DO NOT use 'chdef <node> -p|-m vmothersetting=...' to add options to it or delete options from it because chdef uses commas, not semicolons, to separate items.
+           Hugepage on POWER systems:
+              Specify the hugepage and/or bsr (Barrier Synchronization Register) values, e.g., 'hugepage:1,bsr:2'.
+           KVM CPU mode:
+              Specify how the host CPUs are utilized, e.g., 'cpumode:host-passthrough', 'cpumode:host-model'. With the passthrough mode, the performance of x86 VMs can be improved significantly.
+           KVM CPU pinning:
+              Specify which host CPUs are used, e.g., 'vcpupin:'0-15,^8', where '-' denotes the range and '^' denotes exclusion. This option allows a comma-delimited list.
+           KVM memory binding:
+              Specify which nodes that host memory are used, e.g., 'membind:0', where the memory in node0 of the hypervisor is used. /sys/devices/system/node has node0 and node8 on some POWER systems, node0 and node1 on some x86_64 systems. This option allows a guest VM to access specific memory regions.
+           PCI passthrough:
+              PCI devices can be assigned to a virtual machine for exclusive usage, e.g., 'devpassthrough:pci_0001_01_00_0,pci_0000_03_00_0'. A PCI device can also be expressed as 'devpassthrough:0001:01:00.1'. The devices are put in a comma-delimited list. The PCI device names can be obtained by running \ **virsh nodedev-list**\  on the host.
+           VM machine type:
+              Specify a machine type for VM creation on the host, e.g., 'machine:pc'. Typical machine types are pc, q35, and pseries.
 
 
 
@@ -721,7 +733,7 @@ group Attributes:
 
 \ **os**\  (nodetype.os)
 
- The operating system deployed on this node.  Valid values: AIX, rhels\*,rhelc\*, rhas\*,centos\*,SL\*, fedora\*, sles\* (where \* is the version #). As a special case, if this is set to "boottarget", then it will use the initrd/kernel/parameters specified in the row in the boottarget table in which boottarget.bprofile equals nodetype.profile.
+ The operating system deployed on this node.  Valid values: AIX, rhels\*,rhelc\*, rhas\*,centos\*,rocky\*,SL\*, fedora\*, sles\* (where \* is the version #). As a special case, if this is set to "boottarget", then it will use the initrd/kernel/parameters specified in the row in the boottarget table in which boottarget.bprofile equals nodetype.profile.
 
 
 
@@ -1330,7 +1342,19 @@ group Attributes:
 
 \ **vmothersetting**\  (vm.othersettings)
 
- This allows specifying a semicolon delimited list of key->value pairs to include in a vmx file of VMware or KVM. For partitioning on normal power machines, this option is used to specify the hugepage and/or bsr information, the value is like:'hugepage:1,bsr=2'. For KVM cpu mode use either:'cpumode:host-passthrough' or 'cpumode:host-model'. This improves performance on x86 VMs significantly. For KVM cpu pinning, this option is used to specify the physical cpu set on the host, the value is like:"vcpupin:'0-15,^8'",Its syntax is a comma separated list and a special markup using '-' and '^' (ex. '0-4', '0-3,^2') can also be allowed, the '-' denotes the range and the '^' denotes exclusive. For KVM memory binding, the value is like:'membind:0', restrict a guest to allocate memory from the specified set of NUMA nodes. For PCI passthrough, the value is like:'devpassthrough:pci_0001_01_00_0,pci_0000_03_00_0', the value for PCI device format also can be like:'devpassthrough:0001:01:00.1', the PCI devices are assigned to a virtual machine, and the virtual machine can use this I/O exclusively, the devices list are a list of PCI device names delimited with comma, the PCI device names can be obtained by running \ **virsh nodedev-list**\  on the host.
+ This is a semicolon-delimited list of key-value pairs to be included in a vmx file of VMware or KVM. DO NOT use 'chdef <node> -p|-m vmothersetting=...' to add options to it or delete options from it because chdef uses commas, not semicolons, to separate items.
+           Hugepage on POWER systems:
+              Specify the hugepage and/or bsr (Barrier Synchronization Register) values, e.g., 'hugepage:1,bsr:2'.
+           KVM CPU mode:
+              Specify how the host CPUs are utilized, e.g., 'cpumode:host-passthrough', 'cpumode:host-model'. With the passthrough mode, the performance of x86 VMs can be improved significantly.
+           KVM CPU pinning:
+              Specify which host CPUs are used, e.g., 'vcpupin:'0-15,^8', where '-' denotes the range and '^' denotes exclusion. This option allows a comma-delimited list.
+           KVM memory binding:
+              Specify which nodes that host memory are used, e.g., 'membind:0', where the memory in node0 of the hypervisor is used. /sys/devices/system/node has node0 and node8 on some POWER systems, node0 and node1 on some x86_64 systems. This option allows a guest VM to access specific memory regions.
+           PCI passthrough:
+              PCI devices can be assigned to a virtual machine for exclusive usage, e.g., 'devpassthrough:pci_0001_01_00_0,pci_0000_03_00_0'. A PCI device can also be expressed as 'devpassthrough:0001:01:00.1'. The devices are put in a comma-delimited list. The PCI device names can be obtained by running \ **virsh nodedev-list**\  on the host.
+           VM machine type:
+              Specify a machine type for VM creation on the host, e.g., 'machine:pc'. Typical machine types are pc, q35, and pseries.