mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 138. KafkaMirrorMaker2MirrorSpec schema reference Used in: KafkaMirrorMaker2Spec Property Description sourceCluster The alias of the source cluster used by the Kafka MirrorMaker 2 connectors. The alias must match a cluster in the list at spec.clusters . string targetCluster The alias of the target cluster used by the Kafka MirrorMaker 2 connectors. The alias must match a cluster in the list at spec.clusters . string sourceConnector The specification of the Kafka MirrorMaker 2 source connector. KafkaMirrorMaker2ConnectorSpec heartbeatConnector The specification of the Kafka MirrorMaker 2 heartbeat connector. KafkaMirrorMaker2ConnectorSpec checkpointConnector The specification of the Kafka MirrorMaker 2 checkpoint connector. KafkaMirrorMaker2ConnectorSpec topicsPattern A regular expression matching the topics to be mirrored, for example, "topic1|topic2|topic3". Comma-separated lists are also supported. string topicsBlacklistPattern The topicsBlacklistPattern property has been deprecated, and should now be configured using .spec.mirrors.topicsExcludePattern . A regular expression matching the topics to exclude from mirroring. Comma-separated lists are also supported. string topicsExcludePattern A regular expression matching the topics to exclude from mirroring. Comma-separated lists are also supported. string groupsPattern A regular expression matching the consumer groups to be mirrored. Comma-separated lists are also supported. string groupsBlacklistPattern The groupsBlacklistPattern property has been deprecated, and should now be configured using .spec.mirrors.groupsExcludePattern . A regular expression matching the consumer groups to exclude from mirroring. Comma-separated lists are also supported. string groupsExcludePattern A regular expression matching the consumer groups to exclude from mirroring. Comma-separated lists are also supported. string

Commands:
Chapter 153. KafkaMirrorMaker2ConnectorSpec schema reference Used in: KafkaMirrorMaker2MirrorSpec Property Property type Description tasksMax integer The maximum number of tasks for the Kafka Connector. pause boolean The pause property has been deprecated. Deprecated in Streams for Apache Kafka 2.6, use state instead. Whether the connector should be paused. Defaults to false. config map The Kafka Connector configuration. The following properties cannot be set: name, connector.class, tasks.max. state string (one of [running, paused, stopped]) The state the connector should be in. Defaults to running. autoRestart AutoRestart Automatic restart of connector and tasks configuration. listOffsets ListOffsets Configuration for listing offsets. alterOffsets AlterOffsets Configuration for altering offsets.

Commands:
33.2. Adding an IPP Printer An IPP printer is a printer attached to a different system on the same TCP/IP network. The system this printer is attached to may either be running CUPS or simply configured to use IPP. If a firewall is enabled on the printer server, then the firewall should be configured to allow send / receive connections on the incoming UDP port 631. If a firewall is enabled on on the client (the system sending the print request) then the firewall must be allowed to accept and create connections through port 631. You can add a networked IPP printer by clicking the New Printer button in the main Printer Configuration Tool window to display the window in Figure 33.2, " Adding a Printer " . Enter the Printer Name (printer names cannot contain spaces and may contain letters, numbers, dashes (-), and underscores (_)), Description , and Location to distinguish this printer from others that you may configure on your system. Click Forward to proceed. In the window shown in Figure 33.4, "Adding an IPP Printer" , enter the hostname of the IPP printer in the Hostname field as well as a unique name for the printer in the Printername field. Figure 33.4. Adding an IPP Printer Click Forward to continue. , select the printer type. Refer to Section 33.5, "Selecting the Printer Model and Finishing" for details.

Commands:
Chapter 4. Migrating a Server from a Container to a Host System This chapter describes how you can migrate a server originally installed in a container to a bare-metal or a virtual machine system. In the following scenario, we migrate to a Red Hat Enterprise Linux system. 4.1. Migrating an Identity Management Server from a Container to the Host System This procedure shows how to migrate a containerized Identity Management server to the host system and, optionally, decomission the container. Procedure Enroll the host system as an Identity Management replica against the container. If you want to decommission the container with the Identity Management server later, make sure you create the replica with a certificate authority (CA) configured. See Installing and Uninstalling Identity Management Replicas . Migrate the CA master responsibilities from the server in the container to the new replica on the host system. See Promoting a Replica to a Master CA Server . Decommission the server in the container. See Chapter 5, Uninstalling Server and Replica Containers .

Commands:
20.3. SMBIOS System Information Some hypervisors allow control over what system information is presented to the guest virtual machine (for example, SMBIOS fields can be populated by a hypervisor and inspected using the midecode command in the guest virtual machine). The optional sysinfo element covers all such categories of information. ... <os> <smbios mode='sysinfo'/> ... </os> <sysinfo type='smbios'> <bios> <entry name='vendor'>LENOVO</entry> </bios> <system> <entry name='manufacturer'>Fedora</entry> <entry name='vendor'>Virt-Manager</entry> </system> </sysinfo> ... Figure 20.5. SMBIOS system information The <sysinfo> element has a mandatory attribute type that determines the layout of sub-elements, and may be defined as follows: smbios - Sub-elements call out specific SMBIOS values, which will affect the guest virtual machine if used in conjunction with the smbios sub-element of the <os> element. Each sub-element of sysinfo names a SMBIOS block, and within those elements can be a list of entry elements that describe a field within the block. The following blocks and entries are recognized: bios - This is block 0 of SMBIOS, with entry names drawn from vendor , version , date , and release . <system> - This is block 1 of SMBIOS, with entry names drawn from manufacturer , product , version , serial , uuid , sku , and family . If a uuid entry is provided alongside a top-level uuid element, the two values must match.

Commands:
<os> <smbios mode='sysinfo'/> </os> <sysinfo type='smbios'> <bios> <entry name='vendor'>LENOVO</entry> </bios> <system> <entry name='manufacturer'>Fedora</entry> <entry name='vendor'>Virt-Manager</entry> </system> </sysinfo>
Chapter 6. Installing a three-node cluster on vSphere In OpenShift Container Platform version 4.16, you can install a three-node cluster on VMware vSphere. A three-node cluster consists of three control plane machines, which also act as compute machines. This type of cluster provides a smaller, more resource efficient cluster, for cluster administrators and developers to use for testing, development, and production. You can install a three-node cluster using either installer-provisioned or user-provisioned infrastructure. 6.1. Configuring a three-node cluster You configure a three-node cluster by setting the number of worker nodes to 0 in the install-config.yaml file before deploying the cluster. Setting the number of worker nodes to 0 ensures that the control plane machines are schedulable. This allows application workloads to be scheduled to run from the control plane nodes. Note Because application workloads run from control plane nodes, additional subscriptions are required, as the control plane nodes are considered to be compute nodes. Prerequisites You have an existing install-config.yaml file. Procedure Set the number of compute replicas to 0 in your install-config.yaml file, as shown in the following compute stanza: Example install-config.yaml file for a three-node cluster apiVersion: v1 baseDomain: example.com compute: - name: worker platform: {} replicas: 0 # ... If you are deploying a cluster with user-provisioned infrastructure: Configure your application ingress load balancer to route HTTP and HTTPS traffic to the control plane nodes. In a three-node cluster, the Ingress Controller pods run on the control plane nodes. For more information, see the "Load balancing requirements for user-provisioned infrastructure". After you create the Kubernetes manifest files, make sure that the spec.mastersSchedulable parameter is set to true in cluster-scheduler-02-config.yml file. You can locate this file in <installation_directory>/manifests . For more information, see "Creating the Kubernetes manifest and Ignition config files" in "Installing a cluster on vSphere with user-provisioned infrastructure". Do not create additional worker nodes. Example cluster-scheduler-02-config.yml file for a three-node cluster apiVersion: config.openshift.io/v1 kind: Scheduler metadata: creationTimestamp: null name: cluster spec: mastersSchedulable: true policy: name: "" status: {} 6.2. steps Installing a cluster on vSphere with customizations Installing a cluster on vSphere with user-provisioned infrastructure

Commands:
apiVersion: v1 baseDomain: example.com compute: - name: worker platform: {} replicas: 0
apiVersion: config.openshift.io/v1 kind: Scheduler metadata: creationTimestamp: null name: cluster spec: mastersSchedulable: true policy: name: "" status: {}
Appendix A. VDSM and Hooks A.1. VDSM The VDSM service is used by the Red Hat Virtualization Manager to manage Red Hat Virtualization Hosts (RHVH) and Red Hat Enterprise Linux hosts. VDSM manages and monitors the host's storage, memory and network resources. It also co-ordinates virtual machine creation, statistics gathering, log collection and other host administration tasks. VDSM is run as a daemon on each host managed by Red Hat Virtualization Manager. It answers XML-RPC calls from clients. The Red Hat Virtualization Manager functions as a VDSM client.

Commands:
Chapter 9. Overview Business Central enables you to automate your business processes. A business process is a diagram that describes the order in which a series of steps must be executed and consists of predefined nodes and connections. Each node represents one step in the process while the connections specify how to transition from one node to another. For example, a bank offers a housing mortgage loan service. Using Business Central, the housing mortgage department of the bank creates a complete business process for the mortgage loan. When a customer wants to buy a new property using credit, the following steps occur: The customer contacts a broker at the bank who assists in filing for a mortgage loan. The broker collects information about the property and the customer, such as the salary of the customer, social security number, the property sale price, and the requested loan amount. The broker then submits a request on behalf of the customer. Whenever a customer submits a request, a new process instance is created. This ensures consistency in the quality of evaluating each request, provides complete visibility into the status of each request, and makes the process efficient and effective.

Commands:
Chapter 9. Uninstalling a cluster on VMC You can remove a cluster installed on VMware vSphere infrastructure that you deployed to VMware Cloud (VMC) on AWS by using installer-provisioned infrastructure. 9.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 clusters. There might be resources that the installation program did not create or that the installation program 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 On the computer that you used to install the cluster, go to the directory that contains the installation program, and 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
Chapter 2. Eviction [policy/v1] Description Eviction evicts a pod from its node subject to certain policies and safety constraints. This is a subresource of Pod. A request to cause such an eviction is created by POSTing to ... /pods/<pod name>/evictions. Type object 2.1. Specification Property Type Description apiVersion string APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources deleteOptions DeleteOptions DeleteOptions may be provided kind string Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds metadata ObjectMeta ObjectMeta describes the pod that is being evicted. 2.2. API endpoints The following API endpoints are available: /api/v1/namespaces/{namespace}/pods/{name}/eviction POST : create eviction of a Pod 2.2.1. /api/v1/namespaces/{namespace}/pods/{name}/eviction Table 2.1. Global path parameters Parameter Type Description name string name of the Eviction Table 2.2. Global query parameters Parameter Type Description dryRun string When present, indicates that modifications should not be persisted. An invalid or unrecognized dryRun directive will result in an error response and no further processing of the request. Valid values are: - All: all dry run stages will be processed fieldValidation string fieldValidation instructs the server on how to handle objects in the request (POST/PUT/PATCH) containing unknown or duplicate fields. Valid values are: - Ignore: This will ignore any unknown fields that are silently dropped from the object, and will ignore all but the last duplicate field that the decoder encounters. This is the default behavior prior to v1.23. - Warn: This will send a warning via the standard warning response header for each unknown field that is dropped from the object, and for each duplicate field that is encountered. The request will still succeed if there are no other errors, and will only persist the last of any duplicate fields. This is the default in v1.23+ - Strict: This will fail the request with a BadRequest error if any unknown fields would be dropped from the object, or if any duplicate fields are present. The error returned from the server will contain all unknown and duplicate fields encountered. HTTP method POST Description create eviction of a Pod Table 2.3. Body parameters Parameter Type Description body Eviction schema Table 2.4. HTTP responses HTTP code Reponse body 200 - OK Eviction schema 201 - Created Eviction schema 202 - Accepted Eviction schema 401 - Unauthorized Empty

Commands:
Chapter 15. Fixed issues in Red Hat Decision Manager 7.13.5 Red Hat Decision Manager 7.13.5 provides increased stability and fixed issues listed in this section. 15.1. Business Central Cannot clone project by ssh when business central is integrated with LDAP [ RHPAM-4478 ] System error occurs when you access the Form asset or the Task form which have the listbox component [ RHPAM-4778 ] Duplicate signals received [ RHPAM-4813 ] 15.2. KIE Server Backport DROOLS-7014 to Red Hat Decision Manager libraries [ RHDM-2006 ] An immutable KIE container is not deployed with auto scan in SpringBoot kie-server after upgrading to 7.13.1 [ RHPAM-4800 ] Exclusion on kie-server affects custom endpoints [ RHPAM-4876 ] 15.3. Decision engine Coercion from interger literal to BigDecimal bind variable [ RHDM-1991 ] Behavior of multiple updates in executable model is different from non-executable model [ RHDM-1993 ] Performance degradation when increasing concurrency of rule execution in multi threads [ RHDM-1994 ] Non-matching rule fires randomly and results in infinite-loop [ RHDM-2007 ] The Drools executable-model fails with BigDecimal coercion for method arguments [ RHDM-2014 ] EXISTS and NOT do not work correctly with multiple constraints with BigDecimal [ RHDM-2016 ] Drools executable-model fails with a bind variable to a calculation result of int and BigDecimal [ RHDM-2020 ]

Commands:
Chapter 1. Overview of deploying in external mode Red Hat OpenShift Data Foundation can make services from an external Red Hat Ceph Storage cluster available for consumption through OpenShift Container Platform clusters running on any platform. See Planning your deployment for more information. For instructions regarding how to install a RHCS cluster, see the installation guide . Follow these steps to deploy OpenShift Data Foundation in external mode: Deploy OpenShift Data Foundation using Red Hat Ceph Storage . Deploy OpenShift Data Foundation using IBM FlashSystem . 1.1. Disaster recovery requirements Disaster Recovery features supported by Red Hat OpenShift Data Foundation require all of the following prerequisites to successfully implement a disaster recovery solution: A valid Red Hat OpenShift Data Foundation Advanced subscription A valid Red Hat Advanced Cluster Management for Kubernetes subscription For more information, see the knowledgebase article on OpenShift Data Foundation subscriptions . For detailed disaster recovery solution requirements, see Configuring OpenShift Data Foundation Disaster Recovery for OpenShift Workloads guide, and Requirements and recommendations section of the Install guide in Red Hat Advanced Cluster Management for Kubernetes documentation. 1.2. Network ports required between OpenShift Container Platform and Ceph when using external mode deployment List of TCP ports, source OpenShift Container Platform and destination RHCS TCP ports To be used for 6789, 3300 Ceph Monitor 6800 - 7300 Ceph OSD, MGR, MDS 9283 Ceph MGR Prometheus Exporter For more information about why these ports are required, see Chapter 2. Ceph network configuration of RHCS Configuration Guide .

Commands:
Appendix F. Teiid Designer Main Menu F.1. Teiid Designer Main Menu There are 8 categories of actions on Teiid Designer's main menu bar. These categories include: Resource management actions Standard edit actions including undo/redo Resource actions (i.e. Rename, Move, etc...) Find data within your workspace. Model level actions Custom metadata-related actions Change perspectives or add/remove views to your perspective. Access available Teiid Designer help documents, Teiid Designer SQL Support Guide and Eclipse Overview information. Figure F.1. Application Main Menu

Commands:
Chapter 6. Debugging and troubleshooting 6.1. Debugging V2V conversions Problems encountered when attempting a V2V conversion can be more easily explained to engineers or support services if debugging messages are enabled when V2V is run. Exporting the debugging messages increases the verbosity of the V2V process, causing virt-v2v to print out messages as it runs. These messages will be displayed in the terminal from which virt-v2v is run. Simple redirection can be used to print virt-v2v debug messages to a file. The conversion runs normally like this: Instead, edit this command to export the debug messages to the virt-v2v.log file. To do this, prefix the above command with the environment variables LIBGUESTFS_TRACE=1 LIBGUESTFS_DEBUG=1 , and redirect the output to the virt-v2v.log file by adding ... 2>&1 | tee virt-v2v.log to the end of the command.

Commands:
virt-v2v -i libvirtxml -os pool --bridge bridge_name guest_name.xml
LIBGUESTFS_TRACE=1 LIBGUESTFS_DEBUG=1 virt-v2v -i libvirtxml -os pool --bridge bridge_name guest_name.xml ... 2>&1 | tee virt-v2v.log
2.5. Additional Resources For more information on how to use systemd and related tools to manage system resources on Red Hat Enterprise Linux, see the sources listed below: Installed Documentation Man Pages of Cgroup-Related Systemd Tools systemd-run (1) - The manual page lists all command-line options of the systemd-run utility. systemctl (1) - The manual page of the systemctl utility that lists available options and commands. systemd-cgls (1) - This manual page lists all command-line options of the systemd-cgls utility. systemd-cgtop (1) - The manual page contains the list of all command-line options of the systemd-cgtop utility. machinectl (1) - This manual page lists all command-line options of the machinectl utility. systemd.kill (5) - This manual page provides an overview of kill configuration options for system units. Controller-Specific Kernel Documentation The kernel-doc package provides detailed documentation of all resource controllers. This package is included in the Optional subscription channel. Before subscribing to the Optional channel, see the Scope of Coverage Details channel, then follow the steps documented in the article called How to access Optional and Supplementary channels, and -devel packages using Red Hat Subscription Manager (RHSM)? on Red Hat Customer Portal. To install kernel-doc from the Optional channel, type as root : After the installation, the following files will appear under the /usr/share/doc/kernel-doc- <kernel_version> /Documentation/cgroups/ directory: blkio subsystem - blkio-controller.txt cpuacct subsystem - cpuacct.txt cpuset subsystem - cpusets.txt devices subsystem - devices.txt freezer subsystem - freezer-subsystem.txt memory subsystem - memory.txt net_cls subsystem - net_cls.txt Additionally, see the following files on further information about the cpu subsystem: Real-Time scheduling - /usr/share/doc/kernel-doc- <kernel_version> /Documentation/scheduler/sched-rt-group.txt CFS scheduling - /usr/share/doc/kernel-doc- <kernel_version> /Documentation/scheduler/sched-bwc.txt Online Documentation Red Hat Enterprise Linux 7 System Administrators Guide - The System Administrator's Guide documents relevant information regarding the deployment, configuration and administration of Red Hat Enterprise Linux 7. It is oriented towards system administrators with a basic understanding of the system. The D-Bus API of systemd - The reference for D-Bus API commands for accessing systemd .

Commands:
~]# yum install kernel-doc
2.3.5. Testing the Fence Configuration As of Red Hat Enterprise Linux Release 6.4, you can test the fence configuration for each node in a cluster with the fence_check utility. The following example shows the output of a successful execution of this command. For information on this utility, see the fence_check (8) man page.

Commands:
fence_check fence_check run at Wed Jul 23 09:13:57 CDT 2014 pid: 4769 Testing host-098 method 1: success Testing host-099 method 1: success Testing host-100 method 1: success