mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 1. About CI/CD OpenShift Container Platform is an enterprise-ready Kubernetes platform for developers, which enables organizations to automate the application delivery process through DevOps practices, such as continuous integration (CI) and continuous delivery (CD). To meet your organizational needs, the OpenShift Container Platform provides the following CI/CD solutions: OpenShift Builds OpenShift Pipelines OpenShift GitOps 1.1. OpenShift Builds With OpenShift Builds, you can create cloud-native apps by using a declarative build process. You can define the build process in a YAML file that you use to create a BuildConfig object. This definition includes attributes such as build triggers, input parameters, and source code. When deployed, the BuildConfig object typically builds a runnable image and pushes it to a container image registry. Docker build Source-to-image (S2I) build Custom build For more information, see Understanding image builds 1.2. OpenShift Pipelines OpenShift Pipelines provides a Kubernetes-native CI/CD framework to design and run each step of the CI/CD pipeline in its own container. It can scale independently to meet the on-demand pipelines with predictable outcomes. For more information, see Red Hat OpenShift Pipelines . 1.3. OpenShift GitOps OpenShift GitOps is an Operator that uses Argo CD as the declarative GitOps engine. It enables GitOps workflows across multicluster OpenShift and Kubernetes infrastructure. Using OpenShift GitOps, administrators can consistently configure and deploy Kubernetes-based infrastructure and applications across clusters and development lifecycles. For more information, see Red Hat OpenShift GitOps . 1.4. Jenkins Jenkins automates the process of building, testing, and deploying applications and projects. OpenShift Developer Tools provides a Jenkins image that integrates directly with the OpenShift Container Platform. Jenkins can be deployed on OpenShift by using the Samples Operator templates or certified Helm chart. For more information, see Configuring Jenkins images .

Commands:
7.2. sVirt Labeling Like other services under the protection of SELinux, sVirt uses process-based mechanisms and restrictions to provide an extra layer of security over guest instances. Under typical use, you should not even notice that sVirt is working in the background. This section describes the labeling features of sVirt. As shown in the following output, when using sVirt, each Virtual Machine (VM) process is labeled and runs with a dynamically generated level. Each process is isolated from other VMs with different levels: The actual disk images are automatically labeled to match the processes, as shown in the following output: The following table outlines the different labels that can be assigned when using sVirt: Table 7.1. sVirt Labels Type SELinux Context Description Virtual Machine Processes system_u:system_r:svirt_t:MCS1 MCS1 is a randomly selected MCS field. Currently approximately 500,000 labels are supported. Virtual Machine Image system_u:object_r:svirt_image_t:MCS1 Only processes labeled svirt_t with the same MCS fields are able to read/write these image files and devices. Virtual Machine Shared Read/Write Content system_u:object_r:svirt_image_t:s0 All processes labeled svirt_t are allowed to write to the svirt_image_t:s0 files and devices. Virtual Machine Image system_u:object_r:virt_content_t:s0 System default label used when an image exits. No svirt_t virtual processes are allowed to read files/devices with this label. It is also possible to perform static labeling when using sVirt. Static labels allow the administrator to select a specific label, including the MCS/MLS field, for a virtual machine. Administrators who run statically-labeled virtual machines are responsible for setting the correct label on the image files. The virtual machine will always be started with that label, and the sVirt system will never modify the label of a statically-labeled virtual machine's content. This allows the sVirt component to run in an MLS environment. You can also run multiple virtual machines with different sensitivity levels on a system, depending on your requirements.

Commands:
~]# ps -eZ | grep qemu system_u:system_r:svirt_t:s0:c87,c520 27950 ? 00:00:17 qemu-kvm system_u:system_r:svirt_t:s0:c639,c757 27989 ? 00:00:06 qemu-system-x86
~]# ls -lZ /var/lib/libvirt/images/* system_u:object_r:svirt_image_t:s0:c87,c520 image1
B.104. xguest B.104.1. RHBA-2010:0853 - xguest bug fix update An updated xguest package that fixes a bug is now available. The xguest package sets up the xguest user which can be used as a temporary account to switch to or as a kiosk user account. These accounts are disabled unless SELinux is in enforcing mode. Bug Fix BZ# 641811 Previously, xguest installed its 'sabayon' profile file in the wrong directory. This would cause packagekit and seapplet to be started by default for the xguest user. With this update, the 'sabayon' profile file is installed in the correct directory. All users of xguest are advised to upgrade to this updated package, which resolves this issue.

Commands:
Chapter 7. opm CLI 7.1. About opm The opm CLI tool is provided by the Operator Framework for use with the Operator Bundle Format. This tool allows you to create and maintain catalogs of Operators from a list of bundles, called an index , that are similar to software repositories. The result is a container image, called an index image , which can be stored in a container registry and then installed on a cluster. An index contains a database of pointers to Operator manifest content that can be queried through an included API that is served when the container image is run. On OpenShift Container Platform, Operator Lifecycle Manager (OLM) can use the index image as a catalog by referencing it in a CatalogSource object, which polls the image at regular intervals to enable frequent updates to installed Operators on the cluster. Additional resources See Operator Framework packaging formats for more information about the Bundle Format. To create a bundle image using the Operator SDK, see Working with bundle images . 7.2. Installing opm You can install the opm CLI tool on your Linux, macOS, or Windows workstation. Prerequisites For Linux, you must provide the following packages. RHEL 8 meets these requirements: podman version 1.9.3+ (version 2.0+ recommended) glibc version 2.28+ Procedure Navigate to the OpenShift mirror site and download the latest version of the tarball that matches your operating system. Unpack the archive. For Linux or macOS: USD tar xvf <file> For Windows, unzip the archive with a ZIP program. Place the file anywhere in your PATH . For Linux or macOS: Check your PATH : USD echo USDPATH Move the file. For example: USD sudo mv ./opm /usr/local/bin/ For Windows: Check your PATH : C:\> path Move the file: C:\> move opm.exe <directory> Verification After you install the opm CLI, verify that it is available: USD opm version Example output Version: version.Version{OpmVersion:"v1.15.4-2-g6183dbb3", GitCommit:"6183dbb3567397e759f25752011834f86f47a3ea", BuildDate:"2021-02-13T04:16:08Z", GoOs:"linux", GoArch:"amd64"} 7.3. Additional resources See Managing custom catalogs for opm procedures including creating, updating, and pruning index images.

Commands:
tar xvf <file>
echo USDPATH
sudo mv ./opm /usr/local/bin/
C:\> path
C:\> move opm.exe <directory>
opm version
Version: version.Version{OpmVersion:"v1.15.4-2-g6183dbb3", GitCommit:"6183dbb3567397e759f25752011834f86f47a3ea", BuildDate:"2021-02-13T04:16:08Z", GoOs:"linux", GoArch:"amd64"}
Chapter 36. Compiler and Tools java-1.8.0-openjdk component, BZ# 1189530 With Red Hat Enterprise Linux 7.1, the java-1.8.0-openjdk packages do not provide "java" in the RPM metadata, which breaks compatibility with packages that require Java and are available from the Enterprise Application Platform (EAP) channel. To work around this problem, install another package that provides "java" in the RPM metadata before installing java-1.8.0-openjdk .

Commands:
Chapter 6. Viewing AMQ Brokers You can configure the Fuse Console to view all AMQ brokers that are deployed on the OpenShift cluster. Prerequisites Each AMQ broker image (that you want to view in the Fuse Console) must be: Installed on the same OpenShift cluster that the Fuse Console is installed on. Configured so that the Fuse Console can recognize and connect to it, as described in the section on enabling the Artemis plugin in the Fuse Console in the AMQ Broker documentation. Procedure Click Artemis to view the AMQ management console and monitor the status of AMQ Broker. (The AMQ Broker is based on Apache ActiveMQ Artemis .) For information on using the AMQ management console, see Using AMQ Management Console in the Managing AMQ Broker guide.

Commands:
Chapter 1. Introduction Migration Toolkit for Runtimes product will be End of Life on September 30th, 2024 All customers using this product should start their transition to Migration Toolkit for Applications . Migration Toolkit for Applications is fully backwards compatible with all features and rulesets available in Migration Toolkit for Runtimes and will be maintained in the long term. 1.1. About the MTR extension for Microsoft Visual Studio Code You can migrate and modernize applications by using the Migration Toolkit for Runtimes (MTR) extension for Microsoft Visual Studio Code. The MTR extension analyzes your projects using customizable rulesets, marks issues in the source code, provides guidance to fix the issues, and offers automatic code replacement, if possible. The MTR extension is also compatible with Visual Studio Codespaces, the Microsoft cloud-hosted development environment. 1.2. About the Migration Toolkit for Runtimes What is the Migration Toolkit for Runtimes? The Migration Toolkit for Runtimes (MTR) is an extensible and customizable rule-based tool that simplifies the migration and modernization of Java applications. MTR examines application artifacts, including project source directories and application archives, and then produces an HTML report highlighting areas needing changes. MTR supports many migration paths, including the following examples: Upgrading to the latest release of Red Hat JBoss Enterprise Application Platform Migrating from Oracle WebLogic or IBM WebSphere Application Server to Red Hat JBoss Enterprise Application Platform Containerizing applications and making them cloud-ready Migrating from Java Spring Boot to Quarkus Updating from Oracle JDK to OpenJDK Upgrading from OpenJDK 8 to OpenJDK 11 Upgrading from OpenJDK 11 to OpenJDK 17 Upgrading from OpenJDK 17 to OpenJDK 21 Migrating EAP Java applications to Azure Migrating Spring Boot Java applications to Azure For more information about use cases and migration paths, see the MTR for developers web page. How does the Migration Toolkit for Runtimes simplify migration? The Migration Toolkit for Runtimes looks for common resources and known trouble spots when migrating applications. It provides a high-level view of the technologies used by the application. MTR generates a detailed report evaluating a migration or modernization path. This report can help you to estimate the effort required for large-scale projects and to reduce the work involved. How do I learn more? See the Introduction to the Migration Toolkit for Runtimes to learn more about the features, supported configurations, system requirements, and available tools in the Migration Toolkit for Runtimes.

Commands:
Chapter 20. Workload partitioning in single-node OpenShift In resource-constrained environments, such as single-node OpenShift deployments, use workload partitioning to isolate OpenShift Container Platform services, cluster management workloads, and infrastructure pods to run on a reserved set of CPUs. The minimum number of reserved CPUs required for the cluster management in single-node OpenShift is four CPU Hyper-Threads (HTs). With workload partitioning, you annotate the set of cluster management pods and a set of typical add-on Operators for inclusion in the cluster management workload partition. These pods operate normally within the minimum size CPU configuration. Additional Operators or workloads outside of the set of minimum cluster management pods require additional CPUs to be added to the workload partition. Workload partitioning isolates user workloads from platform workloads using standard Kubernetes scheduling capabilities. The following is an overview of the configurations required for workload partitioning: Workload partitioning that uses /etc/crio/crio.conf.d/01-workload-partitioning pins the OpenShift Container Platform infrastructure pods to a defined cpuset configuration. The performance profile pins cluster services such as systemd and kubelet to the CPUs that are defined in the spec.cpu.reserved field. Note Using the Node Tuning Operator, you can configure the performance profile to also pin system-level apps for a complete workload partitioning configuration on the node. The CPUs that you specify in the performance profile spec.cpu.reserved field and the workload partitioning cpuset field must match. Workload partitioning introduces an extended <workload-type>.workload.openshift.io/cores resource for each defined CPU pool, or workload type . Kubelet advertises the resources and CPU requests by pods allocated to the pool within the corresponding resource. When workload partitioning is enabled, the <workload-type>.workload.openshift.io/cores resource allows access to the CPU capacity of the host, not just the default CPU pool. Additional resources For the recommended workload partitioning configuration for single-node OpenShift clusters, see Workload partitioning .

Commands:
3.4. Configure the Maven Repository To configure the installed Red Hat JBoss Data Grid Maven repository, edit the settings.xml file. The default version of this file is available in the conf directory of your Maven installation. Maven user settings are located in the .m2 sub-directory of the user's home directory. See http://maven.apache.org/settings.html (the Maven documentation) for more information about configuring Maven. See Section B.2, "Maven Repository Configuration Example" to view a sample Maven configuration. Report a bug 3.4.1. Steps After the newest available version of Red Hat JBoss Data Grid is installed and Maven is set up and configured, see Section 9.1, "Create a New Red Hat JBoss Data Grid Project" to learn how to use JBoss Data Grid for the first time. Report a bug

Commands:
Chapter 5. Automation hub Automation hub enables you to discover and use new certified automation content, such as Ansible Collections, from Red Hat Ansible and Certified Partners. New features and enhancements This release of automation hub provides repository management functionality. With repository management, you can create, edit, delete, and move content between repositories. Bug fixes Fixed an issue in the collection keyword search which was returning an incorrect number of results. Added the ability to set OPT_REFERRALS option for LDAP, so that users can now successfully log in to the automation hub by using their LDAP credentials. Fixed an error on the UI when redhat.openshift collection's core dependency was throwing a 404 Not Found error. Fixed an error such that the deprecated execution environments are now skipped while syncing with registry.redhat.io .

Commands:
3.4. Listing Logical Networks This Ruby example lists the logical networks. # Get the reference to the root of the services tree: system_service = connection.system_service # Get the reference to the service that manages the # collection of networks: nws_service = system_service.networks_service # Retrieve the list of clusters and for each one # print its name: nws = nws_service.list nws.each do |nw| puts nw.name end In an environment with only the default management network, the example outputs: For more information, see http://www.rubydoc.info/gems/ovirt-engine-sdk/OvirtSDK4/NetworksService:list .

Commands:
Get the reference to the root of the services tree: system_service = connection.system_service Get the reference to the service that manages the collection of networks: nws_service = system_service.networks_service Retrieve the list of clusters and for each one print its name: nws = nws_service.list nws.each do |nw| puts nw.name end
ovirtmgmt
Chapter 2. Installing Automation content navigator on RHEL As a content creator, you can install Automation content navigator on Red Hat Enterprise Linux (RHEL) 8 or later. 2.1. Installing Automation content navigator on RHEL from an RPM You can install Automation content navigator on Red Hat Enterprise Linux (RHEL) from an RPM. Prerequisites You have installed RHEL 8 or later. You registered your system with Red Hat Subscription Manager. Note Ensure that you only install the navigator matching your current Red Hat Ansible Automation Platform environment. Procedure Attach the Red Hat Ansible Automation Platform SKU: USD subscription-manager attach --pool=<sku-pool-id> Install Automation content navigator with the following command: # dnf install --enablerepo=ansible-automation-platform-2.3-for-rhel-8-x86_64-rpms ansible-navigator Verification Verify your Automation content navigator installation: USD ansible-navigator --help The following example demonstrates a successful installation:

Commands:
subscription-manager attach --pool=<sku-pool-id>
dnf install --enablerepo=ansible-automation-platform-2.3-for-rhel-8-x86_64-rpms ansible-navigator
ansible-navigator --help
Chapter 1. Architecture of OpenShift AI Self-Managed Red Hat OpenShift AI Self-Managed is an Operator that is available in a self-managed environment, such as Red Hat OpenShift Container Platform, or in Red Hat-managed cloud environments such as Red Hat OpenShift Dedicated (with a Customer Cloud Subscription for AWS or GCP), Red Hat OpenShift Service on Amazon Web Services (ROSA Classic or ROSA HCP), or Microsoft Azure Red Hat OpenShift. OpenShift AI integrates the following components and services: At the service layer: OpenShift AI dashboard A customer-facing dashboard that shows available and installed applications for the OpenShift AI environment as well as learning resources such as tutorials, quick starts, and documentation. Administrative users can access functionality to manage users, clusters, notebook images, accelerator profiles, and model-serving runtimes. Data scientists can use the dashboard to create projects to organize their data science work. Model serving Data scientists can deploy trained machine-learning models to serve intelligent applications in production. After deployment, applications can send requests to the model using its deployed API endpoint. Data science pipelines Data scientists can build portable machine learning (ML) workflows with data science pipelines 2.0, using Docker containers. With data science pipelines, data scientists can automate workflows as they develop their data science models. Jupyter (self-managed) A self-managed application that allows data scientists to configure their own notebook server environment and develop machine learning models in JupyterLab. Distributed workloads Data scientists can use multiple nodes in parallel to train machine-learning models or process data more quickly. This approach significantly reduces the task completion time, and enables the use of larger datasets and more complex models. At the management layer: The Red Hat OpenShift AI Operator A meta-operator that deploys and maintains all components and sub-operators that are part of OpenShift AI. Monitoring services Prometheus gathers metrics from OpenShift AI for monitoring purposes. When you install the Red Hat OpenShift AI Operator in the OpenShift cluster, the following new projects are created: The redhat-ods-operator project contains the Red Hat OpenShift AI Operator. The redhat-ods-applications project installs the dashboard and other required components of OpenShift AI. The redhat-ods-monitoring project contains services for monitoring. The rhods-notebooks project is where notebook environments are deployed by default. You or your data scientists must create additional projects for the applications that will use your machine learning models. Do not install independent software vendor (ISV) applications in namespaces associated with OpenShift AI.

Commands:
6.2. Managing Software Repositories When a system is subscribed to the Red Hat Content Delivery Network, a repository file is created in the /etc/yum.repos.d/ directory. To verify that, use yum to list all enabled repositories: yum repolist Red Hat Subscription Management also allows you to manually enable or disable software repositories provided by Red Hat. To list all available repositories, use the following command: subscription-manager repos --list The repository names depend on the specific version of Red Hat Enterprise Linux you are using and are in the following format: Where variant is the Red Hat Enterprise Linux system variant ( server or workstation ), and version is the Red Hat Enterprise Linux system version ( 6 or 7 ), for example: To enable a repository, enter a command as follows: subscription-manager repos --enable repository Replace repository with a name of the repository to enable. Similarly, to disable a repository, use the following command: subscription-manager repos --disable repository Section 8.4, "Configuring Yum and Yum Repositories" provides detailed information about managing software repositories using yum .

Commands:
rhel- variant -rhscl- version -rpms rhel- variant -rhscl- version -debug-rpms rhel- variant -rhscl- version -source-rpms
rhel-server-rhscl- 6 -eus-rpms rhel-server-rhscl- 6 -eus-source-rpms rhel-server-rhscl- 6 -eus-debug-rpms
14.15.2.9. snapshot-revert domain Reverts the given domain to the snapshot specified by snapshot , or to the current snapshot with --current . Warning Be aware that this is a destructive action; any changes in the domain since the last snapshot was taken will be lost. Also note that the state of the domain after snapshot-revert is complete will be the state of the domain at the time the original snapshot was taken. To revert the snapshot, run Normally, reverting to a snapshot leaves the domain in the state it was at the time the snapshot was created, except that a disk snapshot with no guest virtual machine state leaves the domain in an inactive state. Passing either the --running or --paused option will perform additional state changes (such as booting an inactive domain, or pausing a running domain). Since transient domains cannot be inactive, it is required to use one of these options when reverting to a disk snapshot of a transient domain. There are two cases where a snapshot revert involves extra risk, which requires the use of --force to proceed. One is the case of a snapshot that lacks full domain information for reverting configuration; since libvirt cannot prove that the current configuration matches what was in use at the time of the snapshot, supplying --force assures libvirt that the snapshot is compatible with the current configuration (and if it is not, the domain will likely fail to run). The other is the case of reverting from a running domain to an active state where a new hypervisor has to be created rather than reusing the existing hypervisor, because it implies drawbacks such as breaking any existing VNC or Spice connections; this condition happens with an active snapshot that uses a provably incompatible configuration, as well as with an inactive snapshot that is combined with the --start or --pause option.

Commands:
snapshot-revert domain {snapshot | --current} [{--running | --paused}] [--force]