mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 5. ROSA with HCP limits and scalability This document details the tested cluster maximums for Red Hat OpenShift Service on AWS (ROSA) with hosted control planes (HCP) clusters, along with information about the test environment and configuration used to test the maximums. For ROSA with HCP clusters, the control plane is fully managed in the service AWS account and will automatically scale with the cluster. 5.1. ROSA with HCP cluster maximums Consider the following tested object maximums when you plan a Red Hat OpenShift Service on AWS (ROSA) with hosted control planes (HCP) cluster installation. The table specifies the maximum limits for each tested type in a ROSA with HCP cluster. These guidelines are based on a cluster of 500 compute (also known as worker) nodes. For smaller clusters, the maximums are lower. Table 5.1. Tested cluster maximums Maximum type 4.x tested maximum Number of pods [1] 25,000 Number of pods per node 250 Number of pods per core There is no default value Number of namespaces [2] 5,000 Number of pods per namespace [3] 25,000 Number of services [4] 10,000 Number of services per namespace 5,000 Number of back ends per service 5,000 Number of deployments per namespace [3] 2,000 The pod count displayed here is the number of test pods. The actual number of pods depends on the memory, CPU, and storage requirements of the application. When there are a large number of active projects, etcd can suffer from poor performance if the keyspace grows excessively large and exceeds the space quota. Periodic maintenance of etcd, including defragmentation, is highly recommended to make etcd storage available. There are several control loops in the system that must iterate over all objects in a given namespace as a reaction to some changes in state. Having a large number of objects of a type, in a single namespace, can make those loops expensive and slow down processing the state changes. The limit assumes that the system has enough CPU, memory, and disk to satisfy the application requirements. Each service port and each service back end has a corresponding entry in iptables . The number of back ends of a given service impacts the size of the endpoints objects, which then impacts the size of data sent throughout the system. 5.2. steps Planning your environment 5.3. Additional resources Viewing cluster notifications using the Red Hat Hybrid Cloud Console

Commands:
Chapter 5. Recovery for StatefulSet pods Pods that are part of a StatefulSet have a similar issue as pods mounting ReadWriteOnce (RWO) volumes. More information is referenced in the Kubernetes resource StatefulSet considerations . To get the pods part of a StatefulSet to re-create on the active zone after 6-8 minutes you need to force delete the pod with the same requirements (that is, OpenShift Container Platform node powered off or communication disconnected) as pods with RWO volumes.

Commands:
Chapter 5. Uninstalling a cluster on Nutanix You can remove a cluster that you deployed to Nutanix. 5.1. Removing a cluster that uses installer-provisioned infrastructure You can remove a cluster that uses installer-provisioned infrastructure from your cloud. Note After uninstallation, check your cloud provider for any resources not removed properly, especially with User Provisioned Infrastructure (UPI) clusters. There might be resources that the installer did not create or that the installer is unable to access. Prerequisites You have a copy of the installation program that you used to deploy the cluster. You have the files that the installation program generated when you created your cluster. Procedure From the directory that contains the installation program on the computer that you used to install the cluster, run the following command: USD ./openshift-install destroy cluster \ --dir <installation_directory> --log-level info 1 2 1 For <installation_directory> , specify the path to the directory that you stored the installation files in. 2 To view different details, specify warn , debug , or error instead of info . Note You must specify the directory that contains the cluster definition files for your cluster. The installation program requires the metadata.json file in this directory to delete the cluster. Optional: Delete the <installation_directory> directory and the OpenShift Container Platform installation program.

Commands:
./openshift-install destroy cluster --dir <installation_directory> --log-level info 1 2
13.3. Troubleshooting SR-IOV This section contains solutions for problems which may affect SR-IOV. Error starting the guest When starting a configured virtual machine, an error occurs as follows: This error is often caused by a device that is already assigned to another guest or to the host itself. Error migrating, saving, or dumping the guest Attempts to migrate and dump the virtual machine cause an error similar to the following: Because device assignment uses hardware on the specific host where the virtual machine was started, guest migration and save are not supported when device assignment is in use. Currently, the same limitation also applies to core-dumping a guest; this may change in the future.

Commands:
virsh start test error: Failed to start domain test error: internal error unable to start guest: char device redirected to /dev/pts/2 get_real_device: /sys/bus/pci/devices/0000:03:10.0/config: Permission denied init_assigned_device: Error: Couldn't get real device (03:10.0)! Failed to initialize assigned device host=03:10.0
virsh dump --crash 5 /tmp/vmcore error: Failed to core dump domain 5 to /tmp/vmcore error: internal error unable to execute QEMU command 'migrate': An undefined error has occurred
5.5. Controlling LVM Device Scans with Filters At startup, the vgscan command is run to scan the block devices on the system looking for LVM labels, to determine which of them are physical volumes and to read the metadata and build up a list of volume groups. The names of the physical volumes are stored in the LVM cache file of each node in the system, /etc/lvm/cache/.cache . Subsequent commands may read that file to avoiding rescanning. You can control which devices LVM scans by setting up filters in the lvm.conf configuration file. The filters in the lvm.conf file consist of a series of simple regular expressions that get applied to the device names that are in the /dev directory to decide whether to accept or reject each block device found. The following examples show the use of filters to control which devices LVM scans. Note that some of these examples do not necessarily represent best practice, as the regular expressions are matched freely against the complete pathname. For example, a/loop/ is equivalent to a/.*loop.*/ and would match /dev/solooperation/lvol1 . The following filter adds all discovered devices, which is the default behavior as there is no filter configured in the configuration file: The following filter removes the cdrom device in order to avoid delays if the drive contains no media: The following filter adds all loop and removes all other block devices: The following filter adds all loop and IDE and removes all other block devices: The following filter adds just partition 8 on the first IDE drive and removes all other block devices: Note When the lvmetad daemon is running, the filter = setting in the /etc/lvm/lvm.conf file does not apply when you execute the pvscan --cache device command. To filter devices, you need to use the global_filter = setting. Devices that fail the global filter are not opened by LVM and are never scanned. You may need to use a global filter, for example, when you use LVM devices in VMs and you do not want the contents of the devices in the VMs to be scanned by the physical host. For more information on the lvm.conf file, see Appendix B, The LVM Configuration Files and the lvm.conf (5) man page.

Commands:
filter = [ "a/.*/" ]
filter = [ "r|/dev/cdrom|" ]
filter = [ "a/loop.*/", "r/.*/" ]
filter =[ "a|loop.*|", "a|/dev/hd.*|", "r|.*|" ]
filter = [ "a|^/dev/hda8USD|", "r/.*/" ]
10.2. Setting and Removing Cluster Properties To set the value of a cluster property, use the following pcs command. For example, to set the value of symmetric-cluster to false , use the following command. You can remove a cluster property from the configuration with the following command. Alternately, you can remove a cluster property from a configuration by leaving the value field of the pcs property set command blank. This restores that property to its default value. For example, if you have previously set the symmetric-cluster property to false , the following command removes the value you have set from the configuration and restores the value of symmetric-cluster to true , which is its default value.

Commands:
pcs property set property = value
pcs property set symmetric-cluster=false
pcs property unset property
pcs property set symmetic-cluster=
4.129. libcap 4.129.1. RHSA-2011:1694 - Low: libcap security and bug fix update Updated libcap packages that fix one security issue and one bug are now available for Red Hat Enterprise Linux 6. The Red Hat Security Response Team has rated this update as having low security impact. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) associated with each description below. The libcap packages provide a library and tools for getting and setting POSIX capabilities. Security Fix CVE-2011-4099 It was found that capsh did not change into the new root when using the "--chroot" option. An application started via the "capsh --chroot" command could use this flaw to escape the chroot restrictions. Bug Fix BZ# 730957 Previously, the libcap packages did not contain the capsh(1) manual page. With this update, the capsh(1) manual page is included. All libcap users are advised to upgrade to these updated packages, which contain backported patches to correct these issues.

Commands:
8.3.6. Viewing Scan Results and Generating Scan Reports After the system scan is finished, three new buttons, Clear , Save Results , and Show Report , will appear instead of the Scan button. Warning Clicking the Clear button permanently removes the scan results. To store the scan results in the form of an XCCDF, ARF, or HTML file, click the Save Results combo box. Choose the HTML Report option to generate the scan report in human-readable form. The XCCDF and ARF (data stream) formats are suitable for further automatic processing. You can repeatedly choose all three options. If you prefer to view the scan results immediately without saving them, you can click the Show Report button, which opens the scan results in the form of a temporary HTML file in your default web browser.

Commands:
Chapter 2. Accessing Insights image builder on Red Hat Hybrid Cloud Console 2.1. Getting access to Insights image builder on Red Hat Hybrid Cloud Console Follow the steps to access Insights image builder on Red Hat Hybrid Cloud Console . Prerequisites An account at Red Hat Customer Portal . A Red Hat Insights subscription for your account. Red Hat Insights is included with your Red Hat Enterprise Linux subscription. Procedure Access Insights image builder . Login with your Red Hat credentials. You are now able to create and monitor your composes. Additional resources Create a Red Hat account Product Documentation for Red Hat Insights Registration Assistant

Commands:
7.16. bind 7.16.1. RHBA-2015:1250 - bind bug fix and enhancement update Updated bind packages that fix several bugs and add one enhancement are now available for Red Hat Enterprise Linux 6. BIND (Berkeley Internet Name Domain) is an implementation of the Domain Name System (DNS) protocols. BIND includes a DNS server (named), which resolves host names to IP addresses, a resolver library (routines for applications to use when interfacing with DNS), and tools for verifying that the DNS server is operating correctly. Bug Fixes BZ# 1112356 Previously, the "slip" option was not handled correctly in the Response Rate Limiting (RRL) code in BIND, and the variable counting the number of queries was not reset after each query, but after every other query. As a consequence, when the "slip" value of the RRL feature was set to one, instead of slipping every query, every other query was dropped. To fix this bug, the RRL code has been amended to reset the variable correctly according to the configuration. Now, when the "slip" value of the RRL feature is set to one, every query is slipped as expected. BZ# 1142152 BIND incorrectly handled errors returned by dynamic databases (from dyndbAPI). Consequently, BIND could enter a deadlock situation on shutdown under certain circumstances. The dyndb API has been fixed not to cause a deadlock during BIND shutdown after the dynamic database returns an error, and BIND now shuts down normally in the described situation. BZ# 1146893 Because the Simplified Database Backend (SDB) application interface did not handle unexpected SDB database driver errors properly, BIND used with SDB could terminate unexpectedly when such errors occurred. With this update, the SDB application interface has been cleaned to handle these errors correctly, and BIND used with SDB no longer crashes if they happen. BZ# 1175321 Due to a race condition in the beginexclusive() function, the BIND DNS server (named) could terminate unexpectedly while loading configuration. To fix this bug, a patch has been applied, and the race condition no longer occurs. BZ# 1215687 Previously, when the resolver was under heavy load, some clients could receive a SERVFAIL response from the server and numerous "out of memory/success" log messages in BIND's log. Also, cached records with low TTL (1) could expire prematurely. Internal hardcoded limits in the resolver have been increased, and conditions for expiring cached records with low TTL (1) have been made stricter. This prevents the resolver from reaching the limits when under heavy load, and the "out of memory/success" log messages from being received. Cached records with low TTL (1) no longer expire prematurely. Enhancement BZ# 1176476 Users can now use RPZ-NSIP and RPZ-NSDNAME records with Response Policy Zone (RPZ) in the BIND configuration. Users of BIND are advised to upgrade to these updated packages, which fix these bugs and add this enhancement. After installing the update, the BIND daemon (named) will be restarted automatically.

Commands:
Chapter 7. File System XFS scalability The XFS file system is currently supported in Red Hat Enterprise Linux 6 and is well suited for very large files and file systems on a single host. Integrated backup and restore, direct I/O and online resizing of the file system are some of the benefits that this file system provides. The XFS implementation has been improved to better handle metadata intensive workloads. An example of this type of workload is accessing thousands of small files in a directory. Prior to this enhancement, metadata processing could cause a bottleneck and lead to degraded performance. To address this problem an option to delay the logging of the metadata has been added that provides a significant performance improvement. As a result of this delayed logging of metadata, XFS performance is on par with ext4 for such workloads. The default mount options have also been updated to use delayed logging. Parallel NFS Parallel NFS (pNFS) is a part of the NFS v4.1 standard that allows clients to access storage devices directly and in parallel. The pNFS architecture eliminates the scalability and performance issues associated with NFS servers in deployment today. pNFS supports 3 different storage protocols or layouts: files, objects and blocks. The Red Hat Enterprise Linux 6.2 NFS client supports the files layout protocol. To automatically enable the pNFS functionality, create the /etc/modprobe.d/dist-nfsv41.conf file with the following line and reboot the system: Now when the -o minorversion=1 mount option is specified, and the server is pNFS-enabled, the pNFS client code is automatically enabled. This feature is a Technology Preview. For more information on pNFS, refer to http://www.pnfs.com/ . Asynchronous writes in CIFS The CIFS (Common Internet File System) protocol allows for a unified way to access remote files on disparate operating systems. The CIFS client has traditionally only allowed for synchronous writes. This meant that the client process would not yield back control until the writes were successfully completed. This can lead to degraded performance for large transactions that take long to complete. The CIFS client has been updated to write data in parallel without the need to wait for the sequential writes. This change can now result in performance improvements up to 200%. CIFS NTLMSSP authentication Support for NTLMSSP authentication has been added to CIFS. In addition, CIFS now uses the kernel's crypto API. autofs4 module The autofs4 module has been updated to kernel version 2.6.38. Fixed tracepoints for ext3 and jbd Fixed tracepoints have been added to ext3 and jbd . Mount options in superblock Support for the -o nobarrier mount option in ext4 , and its utilities: tune2fs , debugfs , libext2fs , has been added.

Commands:
alias nfs-layouttype4-1 nfs_layout_nfsv41_files
Chapter 15. Determining Certificate System product version The Red Hat Certificate System product version is stored in the /usr/share/pki/CS_SERVER_VERSION file. To display the version: To find the product version of a running server, access the following URLs from your browser: http:// host_name :_port_number_/ca/admin/ca/getStatus http:// host_name :_port_number_/kra/admin/kra/getStatus http:// host_name :_port_number_/ocsp/admin/ocsp/getStatus http:// host_name :_port_number_/tks/admin/tks/getStatus http:// host_name :_port_number_/tps/admin/tps/getStatus Note Note that each component is a separate package and thus could have a separate version number. The above will show the version number for each currently running component.

Commands:
cat /usr/share/pki/CS_SERVER_VERSION Red Hat Certificate System {Version} (Batch Update 1)
Chapter 2. Other installable plugins The following Technology Preview plugins are not preinstalled and must be installed from an external source: Name Plugin Version Installation Details Ansible Automation Platform Frontend @ansible/plugin-backstage-rhaap 1.0.0 Learn more Ansible Automation Platform @ansible/plugin-backstage-rhaap-backend 1.0.0 Learn more Ansible Automation Platform Scaffolder Backend @ansible/plugin-scaffolder-backend-module-backstage-rhaap 1.0.0 Learn more Note The above Red Hat Ansible Automation Platform (RHAAP) plugins, can be used as a replacement for the older plugin listed in the Technology Preview plugins section of the Configuring plugins in Red Hat Developer Hub guide .

Commands:
4.74. gnome-power-manager 4.74.1. RHBA-2012:1228 - gnome-packagekit bug fix update Updated gnome-packagekit packages that fix a bug are now available for Red Hat Enterprise Linux 6 Extended Update Support. The gnome-packagekit packages provide session applications for the PackageKit API. Bug Fix BZ# 822946 Previously, it was possible for the user to log out of the system or shut it down while the PackageKit update tool was running and writing to the RPM database (rpmdb). Consequently, rpmdb could become damaged and inconsistent due to the unexpected termination and cause various problems with subsequent operation of the rpm, yum, and PackageKit utilities. This update modifies PackageKit to not allow shutting down the system when a transaction writing to rpmdb is active, thus fixing this bug. Users of gnome-packagekit are advised to upgrade to these updated packages, which fix this bug. 4.74.2. RHBA-2012:0686 - gnome-power-manager bug fix update Updated gnome-power-manager packages that fix one bug are now available for Red Hat Enterprise Linux 6. GNOME Power Manager uses the information and facilities provided by DeviceKit-power to display icons and handle user callbacks in an interactive GNOME session. Bug Fix BZ# 800267 After resuming the system or re-enabling the display, an icon could appear in the notification area with an erroneous tooltip that read "Session active, not inhibited, screen idle. If you see this test, your display server is broken and you should notify your distributor." and included a URL to an external web page. This error message was incorrect, had no effect on the system and could be safely ignored. In addition, linking to an external URL from the notification and status area is unwanted. To prevent this, the icon is no longer used for debugging idle problems. All users are advised to upgrade to these updated gnome-power-manager packages, which fix this bug.

Commands:
Chapter 74. Coverage reports for test scenarios The test scenario designer provides a clear and coherent way of displaying the test coverage statistics using the Coverage Report tab on the right side of the test scenario designer. You can also download the coverage report to view and analyze the test coverage statistics. Downloaded test scenario coverage report supports the .CSV file format. For more information about the RFC specification for the Comma-Separated Values (CSV) format, see Common Format and MIME Type for Comma-Separated Values (CSV) Files . You can view the coverage report for rule-based and DMN-based test scenarios. 74.1. Generating coverage reports for rule-based test scenarios In rule-based test scenarios, the Coverage Report tab contains the detailed information about the following: Number of available rules Number of fired rules Percentage of fired rules Percentage of executed rules represented as a pie chart Number of times each rule has executed The rules that are executed for each defined test scenario Follow the procedure to generate a coverage report for rule-based test scenarios: Prerequisites The rule-based test scenario template are created for the selected test scenario. For more information about creating rule-based test scenarios, see Section 65.1, "Creating a test scenario template for rule-based test scenarios" . The individual test scenarios are defined. For more information about defining a test scenario, see Chapter 67, Defining a test scenario . Note To generate the coverage report for rule-based test scenario, you must create at least one rule. Procedure Open the rule-based test scenarios in the test scenario designer. Run the defined test scenarios. Click Coverage Report on the right of the test scenario designer to display the test coverage statistics. Optional: To download the test scenario coverage report, Click Download report . 74.2. Generating coverage reports for DMN-based test scenarios In DMN-based test scenarios, the Coverage Report tab contains the detailed information about the following: Number of available decisions Number of executed decisions Percentage of executed decisions Percentage of executed decisions represented as a pie chart Number of times each decision has executed Decisions that are executed for each defined test scenario Follow the procedure to generate a coverage report for DMN-based test scenarios: Prerequisites The DMN-based test scenario template is created for the selected test scenario. For more information about creating DMN-based test scenarios, see Section 66.1, "Creating a test scenario template for DMN-based test scenarios" . The individual test scenarios are defined. For more information about defining a test scenario, see Chapter 67, Defining a test scenario . Procedure Open the DMN-based test scenarios in the test scenario designer. Run the defined test scenarios. Click Coverage Report on the right of the test scenario designer to display the test coverage statistics. Optional: To download the test scenario coverage report, Click Download report .

Commands: