mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 2. About migrating from OpenShift Container Platform 3 to 4 OpenShift Container Platform 4 contains new technologies and functionality that result in a cluster that is self-managing, flexible, and automated. OpenShift Container Platform 4 clusters are deployed and managed very differently from OpenShift Container Platform 3. The most effective way to migrate from OpenShift Container Platform 3 to 4 is by using a CI/CD pipeline to automate deployments in an application lifecycle management framework. If you do not have a CI/CD pipeline or if you are migrating stateful applications, you can use the Migration Toolkit for Containers (MTC) to migrate your application workloads. To successfully transition to OpenShift Container Platform 4, review the following information: Differences between OpenShift Container Platform 3 and 4 Architecture Installation and upgrade Storage, network, logging, security, and monitoring considerations About the Migration Toolkit for Containers Workflow File system and snapshot copy methods for persistent volumes (PVs) Direct volume migration Direct image migration Advanced migration options Automating your migration with migration hooks Using the MTC API Excluding resources from a migration plan Configuring the MigrationController custom resource for large-scale migrations Enabling automatic PV resizing for direct volume migration Enabling cached Kubernetes clients for improved performance For new features and enhancements, technical changes, and known issues, see the MTC release notes .

Commands:
12.7. GlusterFS Storage Pools GlusterFS is a userspace file system that uses FUSE. When enabled in a guest virtual machine it enables a KVM host physical machine to boot guest virtual machine images from one or more GlusterFS storage volumes, and to use images from a GlusterFS storage volume as data disks for guest virtual machines. Important Red Hat Red Hat Enterprise Linux 6 does not support the use of GlusterFS with storage pools. However, Red Hat Enterprise Linux 6.5 and later includes native support for creating virtual machines with GlusterFS using the libgfapi library.

Commands:
Chapter 2. Architectures Red Hat Enterprise Linux 7.3 is available as a single kit on the following architectures: [1] 64-bit AMD 64-bit Intel IBM POWER7+ and POWER8 (big endian) [2] IBM POWER8 (little endian) [3] IBM z Systems [4] [1] Note that the Red Hat Enterprise Linux 7.3 installation is supported only on 64-bit hardware. Red Hat Enterprise Linux 7.3 is able to run 32-bit operating systems, including versions of Red Hat Enterprise Linux, as virtual machines. [2] Red Hat Enterprise Linux 7.3 (big endian) is currently supported as a KVM guest on Red Hat Enterprise Virtualization for Power, and on PowerVM. [3] Red Hat Enterprise Linux 7.3 (little endian) is currently supported as a KVM guest on Red Hat Enterprise Virtualization for Power, on PowerVM and PowerNV (bare metal). [4] Note that Red Hat Enterprise Linux 7.3 supports IBM zEnterprise 196 hardware or later; IBM z10 Systems mainframe systems are no longer supported and will not boot Red Hat Enterprise Linux 7.3.

Commands:
B.7. Bmap Tracepoints Block mapping is a task central to any file system. GFS2 uses a traditional bitmap-based system with two bits per block. The main purpose of the tracepoints in this subsystem is to allow monitoring of the time taken to allocate and map blocks. The gfs2_bmap tracepoint is called twice for each bmap operation: once at the start to display the bmap request, and once at the end to display the result. This makes it easy to match the requests and results together and measure the time taken to map blocks in different parts of the file system, different file offsets, or even of different files. It is also possible to see what the average extent sizes being returned are in comparison to those being requested. The gfs2_rs tracepoint traces block reservations as they are created, used, and destroyed in the block allocator. To keep track of allocated blocks, gfs2_block_alloc is called not only on allocations, but also on freeing of blocks. Since the allocations are all referenced according to the inode for which the block is intended, this can be used to track which physical blocks belong to which files in a live file system. This is particularly useful when combined with blktrace , which will show problematic I/O patterns that may then be referred back to the relevant inodes using the mapping gained by means this tracepoint.

Commands:
3.3. cpuacct The CPU Accounting ( cpuacct ) subsystem generates automatic reports on CPU resources used by the tasks in a cgroup, including tasks in child groups. Three reports are available: cpuacct.usage reports the total CPU time (in nanoseconds) consumed by all tasks in this cgroup (including tasks lower in the hierarchy). Note To reset the value in cpuacct.usage , execute the following command: The above command also resets values in cpuacct.usage_percpu . cpuacct.stat reports the user and system CPU time consumed by all tasks in this cgroup (including tasks lower in the hierarchy) in the following way: user - CPU time consumed by tasks in user mode. system - CPU time consumed by tasks in system (kernel) mode. CPU time is reported in the units defined by the USER_HZ variable. cpuacct.usage_percpu reports the CPU time (in nanoseconds) consumed on each CPU by all tasks in this cgroup (including tasks lower in the hierarchy).

Commands:
~]# echo 0 > /cgroup/cpuacct/cpuacct.usage
3.5.3. Creating Network Packet Filter Rules Before assigning any iptables rules for FTP service, review the information in Section 3.4.1, "Assigning Firewall Marks" concerning multi-port services and techniques for checking the existing network packet filtering rules. Below are rules which assign the same firewall mark, 21, to FTP traffic. For these rules to work properly, you must also use the VIRTUAL SERVER subsection of Piranha Configuration Tool to configure a virtual server for port 21 with a value of 21 in the Firewall Mark field. See Section 4.6.1, "The VIRTUAL SERVER Subsection" for details. 3.5.3.1. Rules for Active Connections The rules for active connections tell the kernel to accept and forward connections coming to the internal floating IP address on port 20 - the FTP data port. The following iptables command allows the LVS router to accept outgoing connections from the real servers that IPVS does not know about: /sbin/iptables -t nat -A POSTROUTING -p tcp -s n.n.n .0/24 --sport 20 -j MASQUERADE In the iptables command, n.n.n should be replaced with the first three values for the floating IP for the NAT interface's internal network interface defined in the GLOBAL SETTINGS panel of Piranha Configuration Tool .

Commands:
7.2. Caching Caching options can be configured with virt-manager during guest installation, or on an existing guest virtual machine by editing the guest XML configuration. Table 7.1. Caching options Caching Option Description Cache=none I/O from the guest is not cached on the host, but may be kept in a writeback disk cache. Use this option for guests with large I/O requirements. This option is generally the best choice, and is the only option to support migration. Cache=writethrough I/O from the guest is cached on the host but written through to the physical medium. This mode is slower and prone to scaling problems. Best used for small number of guests with lower I/O requirements. Suggested for guests that do not support a writeback cache (such as Red Hat Enterprise Linux 5.5 and earlier), where migration is not needed. Cache=writeback I/O from the guest is cached on the host. Cache=directsync Similar to writethrough , but I/O from the guest bypasses the host page cache. Cache=unsafe The host may cache all disk I/O, and sync requests from guest are ignored. Cache=default If no cache mode is specified, the system's default settings are chosen. In virt-manager , the caching mode can be specified under Virtual Disk . For information on using virt-manager to change the cache mode, see Section 3.3, "Virtual Disk Performance Options" To configure the cache mode in the guest XML, edit the cache setting inside the driver tag to specify a caching option. For example, to set the cache as writeback : <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/>

Commands:
<disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/>
Chapter 2. Tools for migrating from JBoss EAP XP 3.0 or 4.0 servers to JBoss EAP XP 5.0 servers You can choose one of the following tools to upgrade and migrate your JBoss EAP XP 3.0 or 4.0 product to the JBoss EAP XP 5.0 product: Migration Toolkit for Applications (MTA) JBoss Server Migration Tool 2.1. Use the JBoss Server Migration Tool to migrate your server configurations Use the JBoss Server Migration Tool when updating your server configuration to include the new features and settings of JBoss EAP XP 5.0. You can keep your existing JBoss EAP XP 3.0 or 4.0 server configuration, provided that JBoss EAP XP 5.0 supports the configurations. The JBoss Server Migration Tool reads your existing JBoss EAP XP 3.0 or 4.0 server configuration files and adds any new required subsystems to these files. The tool also updates existing subsystem configurations with new features, and removes any obsolete subsystem configurations. You can use the JBoss Server Migration Tool to migrate standalone servers for your JBoss EAP XP 5.0 configuration. JBoss EAP XP 5.0 does not include the JBoss Server Migration Tool, so you need to download the tool from the JBoss EAP XP download page . Additional resources Running the JBoss Server Migration Tool 2.2. Use the Migration Toolkit for Applications to analyze applications for migration The Migration Toolkit for Applications (MTA) includes extensible and customizable rule-based tools that simplify migration of Jakarta applications. You can use the toolkit to analyze an application's APIs, technologies, and architectures. The toolkit provides reports for the application you plan to migrate from JBoss EAP XP 3.0 or 4.0 to JBoss EAP XP 5.0. The MTA reports output the following information: Detailed explanations of all required migration changes. Whether the change is mandatory or optional. Whether the change is complex or simple. Links to code that requires a migration update. Hints and links to information for helping you complete the required migration changes. An estimate of the level of effort for each migration issue found and the total estimated effort to migrate the application. You can also use MTA to analyze the code and architecture of your JBoss EAP XP 3.0 or 4.0 applications before you migrate them to JBoss EAP XP 5.0. The MTA rule set for migrating applications from JBoss EAP XP 3.0 or 4.0 to JBoss EAP XP 5.0 reports on XML descriptors, specific application code, and parameters, that you need to replace with alternative configurations when migrating to JBoss EAP XP 5.0. Additional resources Product documentation for Migration Toolkit for Applications Installing and Running the CLI Assessing and analyzing applications with MTA

Commands:
1.7. Create a Connection to a VDB Using the Driver Class Prerequisites The client application must have the JBoss Data Virtualization EAP_HOME /dataVirtualization/jdbc/teiid- VERSION -redhat- N -jdbc.jar JAR file in its classpath. (If the application is running on the same application server as the JBoss Data Virtualization instance to which the connection is desired, then this will already be the case.) JBoss Data Virtualization must be installed and running, with the relevant virtual databases (VDBs) deployed. Procedure 1.1. Create a Connection to a VDB Using the Driver Class Create a Connection to the VDB Within your client application code, create a Connection to the VDB using the DriverManager.getConnection() method: See Also: Section 1.8, "Driver Connection URL Format"

Commands:
public class TeiidClient { public Connection getConnection(String user, String password) throws Exception { String url = "jdbc:teiid:myVDB@mm://localhost:31000;ApplicationName=myApp"; return DriverManager.getConnection(url, user, password); } }
Appendix C. Teiid Designer UI Reference C.1. Teiid Designer Perspectives Teiid Designer utilizes the Eclipse Workbench environment which controls visual layout via perspectives. A perspective defines the initial set and layout of views and editors. Within the application window, each perspective shares the same set of editors. Each perspective provides a set of functionality aimed at accomplishing a specific set of tasks. Perspectives also control what appears in certain menus and toolbars. They define visible action sets, which you can change to customize a perspective. You can save a perspective that you build in this manner, making your own custom perspective that you can open again later.

Commands:
Chapter 2. Creating an Activation Key for Virtual Machines Use this procedure to create an activation key with auto-attach enabled and no subscriptions attached. When you register virtual machines using this activation key, the virtual machines inherit a subscription from their hypervisor if that hypervisor has a host-based subscription attached. For more information about activation keys, see Managing Activation Keys in Managing Content . Procedure In the Satellite web UI, navigate to Content > Activation keys and click Create Activation Key . In the Name field, enter the name of the activation key. Ensure the Unlimited Hosts check box is selected. Alternatively, if you want to set a limit, clear the Unlimited hosts check box, and in the Limit field, enter the maximum number of virtual machines you can register with the activation key. In the Description field, enter a description for the activation key. From the Environment list, select the environment to use. From the Content View list, select a Content View to use. Click Save . When the new activation key appears in the Activation Keys window, click the name of the key. Click the Subscriptions tab. Ensure that Auto-Attach is set to Yes . If it is not, click the edit icon, select the check box, and click Save . Do not add any subscriptions to this activation key. For CLI Users Create the activation key: Enable auto-attach on the activation key:

Commands:
hammer activation-key create --name " VM_Activation_Key " --unlimited-hosts --description " For VMs to inherit a VDC Subscription " --lifecycle-environment " Environment_Name " --content-view " CV_Name " --organization " My_Organization "
hammer activation-key update --name " VM_Activation_Key " --organization " My_Organization " --auto-attach true
Chapter 6. Additional Information 6.1. Implemented SAP Notes in sap*preconfigure The implemented SAP notes in the three preconfigure roles, along with the SAP note versions, are contained in each preconfigure role's vars files, in a variable named _<role_name>_sapnotes_versions . Sample file name: /usr/share/ansible/roles/sap_general_preconfigure/vars/RedHat_8.yml . In these files the variable _sap_general_preconfigure_sapnotes_versions contains the implemented SAP notes along with their version numbers. 6.2. Role Variables The file README.md of each role, located in directory /usr/share/ansible/roles/<role> , describes the purpose of all user configurable variables as well as their default settings. The variables are defined and can be changed in several places, e.g. in an inventory file, in your playbooks, or by using the ansible-playbook command line parameter --extra-vars or -e .

Commands:
Chapter 11. Kafka Streams API overview The Kafka Streams API allows applications to receive data from one or more input streams, execute complex operations like mapping, filtering or joining, and write the results into one or more output streams. It is part of the kafka-streams JAR package that is available in the Red Hat Maven repository. 11.1. Adding the Kafka Streams API as a dependency to your Maven project This procedure shows you how to add the AMQ Streams Java clients as a dependency to your Maven project. Prerequisites A Maven project with an existing pom.xml . Procedure Add the Red Hat Maven repository to the <repositories> section of your pom.xml file. Add kafka-streams to the <dependencies> section of your pom.xml file. Build your Maven project.

Commands:
<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <!-- ... --> <repositories> <repository> <id>redhat-maven</id> <url>https://maven.repository.redhat.com/ga/</url> </repository> </repositories> <!-- ... --> </project>
<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <!-- ... --> <dependencies> <dependency> <groupId>org.apache.kafka</groupId> <artifactId>kafka-streams</artifactId> <version>2.8.0.redhat-00002</version> </dependency> </dependencies> <!-- ... --> </project>
Release notes Red Hat OpenShift AI Self-Managed 2.18 Features, enhancements, resolved issues, and known issues associated with this release

Commands:
Connecting to cache endpoint ds-pipeline-dspa.project-name.svc.cluster.local:8887 panic: runtime error: invalid memory address or nil pointer dereference
get ValidatingWebhookConfiguration,MutatingWebhookConfiguration | grep -i knative
get ValidatingWebhookConfiguration,MutatingWebhookConfiguration | grep -i knative
As of transformers v4.44, default chat template is no longer allowed, so you must provide a chat template if the tokenizer does not define one
containers: - args: - --chat-template=<CHAT_TEMPLATE>
ReconcileCompletedWithComponentErrors DataScienceCluster resource reconciled with component errors: 1 error occurred: * CustomResourceDefinition.apiextensions.k8s.io "appwrappers.workload.codeflare.dev" is invalid: status.storedVersions[0]: Invalid value: "v1beta1": must appear in spec.versions
oc delete crd appwrappers.workload.codeflare.dev
oc get crd appwrappers.workload.codeflare.dev NAME CREATED AT appwrappers.workload.codeflare.dev 2024-11-22T18:35:04Z
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-ingress-to-myapp spec: podSelector: matchLabels: app: myapp ingress: - {}
Failed to get endpoint for this deployed model. routes.rout.openshift.io"<model_name>" not found
oc patch OdhDashboardConfig odh-dashboard-config -n redhat-ods-applications --type=merge -p '{"spec": {"dashboardConfig": {"notebookController.enabled": true}}}'
runc create failed: unable to start container process: unable to init seccomp: error loading seccomp filter into kernel: error loading seccomp filter: errno 524
Error creating workbench Operation cannot be fulfilled on notebooks.kubeflow.org "workbench-name": the object has been modified; please apply your changes to the latest version and try again
Request invalid against a username that does not exist.
import os os.environ["TENSORBOARD_PROXY_URL"]= os.environ["NB_PREFIX"]+"/proxy/6006/"
3.5. Setting up a Kerberos Client for Smart Cards Smart cards can be used with Kerberos, but it requires additional configuration to recognize the X.509 (SSL) user certificates on the smart cards: Install the required PKI/OpenSSL package, along with the other client packages: Edit the /etc/krb5.conf configuration file to add a parameter for the public key infrastructure (PKI) to the [realms] section of the configuration. The pkinit_anchors parameter sets the location of the CA certificate bundle file. Add the PKI module information to the PAM configuration for both smart card authentication ( /etc/pam.d/smartcard-auth ) and system authentication ( /etc/pam.d/system-auth ). The line to be added to both files is as follows:

Commands:
yum install krb5-pkinit-openssl yum install krb5-workstation krb5-libs krb5-auth-dialog
[realms] EXAMPLE.COM = { kdc = kdc.example.com.:88 admin_server = kdc.example.com default_domain = example.com pkinit_anchors = FILE:/usr/local/example.com.crt }
auth optional pam_krb5.so use_first_pass no_subsequent_prompt preauth_options=X509_user_identity=PKCS11:/usr/lib64/pkcs11/libcoolkeypk11.so
Chapter 1. Benefits of Red Hat Developer Hub Red Hat Developer Hub offers targeted benefits for developers, platform engineers, and organizations by simplifying workflows, improving productivity, and enabling efficient governance. For developers Simplified access to tools, resources, and workflows through a centralized dashboard. Self-service capabilities with guardrails for cloud-native development. Streamlined software and service creation using pre-configured templates. For Platform engineers Tailored platforms with curated tools to support developers efficiently. Centralized repositories for consistent configuration management. Simplified governance of technology choices and operational processes. For organizations Scalability to onboard new teams quickly while maintaining consistency. Enhanced security with enterprise-grade Role-Based Access Control (RBAC). Cost and time efficiency by mitigating cognitive load and eliminating workflow bottlenecks. 1.1. Key features Centralized Dashboard Provides a single interface for accessing developer tools, CI/CD pipelines, APIs, monitoring tools, and documentation. Integrated with systems like Git, OpenShift, Kubernetes, and JIRA. Dynamic Plugins Add, update, or remove plugins dynamically without downtime. Popular plugins like Tekton, GitOps, Nexus Repository, and JFrog Artifactory are supported and verified by Red Hat. Software Templates Simplify development processes by automating tasks such as repository setup, variable insertion, and production pipeline creation. Role-Based Access Control (RBAC) Manage user access with robust security permissions tailored to organizational needs. Scalability Support growing teams and applications while maintaining access to the same tools and services. Configuration Management Centralized repositories ensure synchronized updates, improving version control and environment configuration. Additional resources For more information about the different features of Red Hat Developer Hub and how to extend it, see Red Hat Developer Hub overview .

Commands:
Chapter 3. Installing and preparing the Operators You install the Red Hat OpenStack Services on OpenShift (RHOSO) OpenStack Operator ( openstack-operator ) and create the RHOSO control plane on an operational Red Hat OpenShift Container Platform (RHOCP) cluster. You install the OpenStack Operator by using the RHOCP web console. You perform the control plane installation tasks and all data plane creation tasks on a workstation that has access to the RHOCP cluster. 3.1. Prerequisites An operational RHOCP cluster, version 4.16. For the RHOCP system requirements, see Red Hat OpenShift Container Platform cluster requirements in Planning your deployment . The oc command line tool is installed on your workstation. You are logged in to the RHOCP cluster as a user with cluster-admin privileges. 3.2. Installing the OpenStack Operator You use OperatorHub on the Red Hat OpenShift Container Platform (RHOCP) web console to install the OpenStack Operator ( openstack-operator ) on your RHOCP cluster. Procedure Log in to the RHOCP web console as a user with cluster-admin permissions. Select Operators OperatorHub . In the Filter by keyword field, type OpenStack . Click the OpenStack Operator tile with the Red Hat source label. Read the information about the Operator and click Install . On the Install Operator page, select "Operator recommended Namespace: openstack-operators" from the Installed Namespace list. Click Install to make the Operator available to the openstack-operators namespace. The Operators are deployed and ready when the Status of the OpenStack Operator is Succeeded .

Commands: