vania-janet/multiturn-rag-retrieval-data huggingface dataset:
* ibm-charts: Helm charts that are approved for Red Hat OpenShift on IBM Cloud and IBM Cloud Private clusters.
* ibm-community: Helm charts that originated outside IBM, such as from [Red Hat OpenShift on IBM Cloud partners](https://cloud.ibm.com/docs/openshift?topic=openshift-service-partners). These charts are supported and maintained by the community partners.
* kubernetes: Helm charts that are provided by the Kubernetes community and considered stable by the community governance. These charts are not verified to work in Red Hat OpenShift on IBM Cloud or IBM Cloud Private clusters.
* kubernetes-incubator: Helm charts that are provided by the Kubernetes community and considered incubator by the community governance. These charts are not verified to work in Red Hat OpenShift on IBM Cloud or IBM Cloud Private clusters.
* entitled: Helm charts of licensed software that you must purchase and for which you must set up cluster access with an entitlement key. For more information, see [Setting up a cluster to pull entitled software](https://cloud.ibm.com/docs/openshift?topic=openshift-registrysecret_entitled_software).



Helm charts from the iks-charts, ibm-charts, and, if licensed, entitled repositories are fully integrated into the IBM Cloud support organization. If you have a question or an issue with using these Helm charts, you can use one of the Red Hat OpenShift on IBM Cloud support channels. For more information, see [Getting help and support](https://cloud.ibm.com/docs/openshift?topic=openshift-get-help). [Install the latest release of Helm v3](https://cloud.ibm.com/docs/openshift?topic=openshift-helminstall_v3).







 Installing Helm v3 in your cluster 

Set up Helm v3 and the IBM Cloud Helm repositories in your cluster.

Before you begin: [Log in to your account. If applicable, target the appropriate resource group. Set the context for your cluster.]
Managing the Workload Protection agent in Red Hat OpenShift by using a HELM chart 

You can use a Helm chart to install, upgrade, and delete a Workload Protection agent on a Red Hat OpenShift cluster.



 Before you begin 



* Install the latest release of the version 3 [Helm CLI](https://github.com/helm/helm/releases) on your local machine.

Helm 3.6 or later is required.
* [Install the IBM Cloud CLI (ibmcloud), Kubernetes Service plug-in (ibmcloud oc), and IBM Cloud Container Registry plug-in (ibmcloud cr)](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift-clics_cli_install_steps).
* [Install the Red Hat OpenShift (oc) and Kubernetes (kubectl) CLIs](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift-clicli_oc).
* Check that you have access and permissions to deploy the Workload Protection agent on the cluster.
* Verify the ibm-observe project is available in your cluster. The agent is deployed in this project.

A project is a namespace in a cluster.

You can run oc adm new-project --node-selector='' ibm-observe to create the project.







 Deploy an agent 

Complete the following steps to deploy an agent by using Helm:



 Step 1. Setup the cluster context 

Complete the following steps:



1. Log in to the account. If you have a federated account, include the --sso option.

ibmcloud login [-g <resource_group>] [--sso]
2. Download and add the kubeconfig configuration file for your cluster to your existing kubeconfig in /.kube/config or the last file in the KUBECONFIG environment variable.

ibmcloud oc cluster config --cluster <cluster_name_or_ID>
3.
From the Red Hat OpenShift [downloads page](https://console.redhat.com/openshift/downloads), download the Red Hat OpenShift command-line interface (oc) and the Red Hat OpenShift Client (oc) mirror plug-in.
2. Copy the oc and the oc-mirror tar files to your bastion host.

scp /path/to/download root@BASTION-HOST-IP:/root
3. Log in to your bastion host. For more information, see [Connecting to your instance](https://cloud.ibm.com/docs/vpc?topic=vpc-creating-a-vpc-using-the-ibm-cloud-console&interface=cliconnecting-to-your-instance).

ssh -i <path-to-key-file> root@<bastion-host-ip-address>
4. Unpack each of tar files and move them to /usr/local/bin.

tar -C /usr/local/bin -xvzf oc.tar.gz

tar -C /usr/local/bin -xvzf oc-mirror.tar.gz
5. Install the IBM Cloud CLI tools.

curl -fsSL https://clis.cloud.ibm.com/install/linux | sh
6. Install the container-service and container-registry plug-ins.

ibmcloud plugin install container-service

ibmcloud plugin install container-registry
7. Install [Podman](https://podman.io/get-started).







 Step 5: Log in to your cluster and disable the default OperatorHub sources 

In a restricted network environment, you must have administrator access to disable the default catalogs. You can then configure OperatorHub to use local catalog sources.

While logged into your bastion host, complete the following steps.



1. [Access your Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster).
2.
Assigning cluster access by using Terraform for Red Hat OpenShift on IBM Cloud 

Terraform on IBM Cloud® enables predictable and consistent provisioning of IBM Cloud services so that you can rapidly build complex, multitiered cloud environments following Infrastructure as Code (IaC) principles. Similar to using the IBM Cloud CLI or API and SDKs, you can automate the provisioning, update, and deletion of your Red Hat OpenShift on IBM Cloud resources by using HashiCorp Configuration Language (HCL).

Looking for a managed Terraform on IBM Cloud® solution? Try out [IBM Cloud® Schematics](https://cloud.ibm.com/docs/schematics?topic=schematics-getting-started). With Schematics, you can use the Terraform scripting language that you are familiar with, but you don't have to worry about setting up and maintaining the Terraform command line or the IBM Cloud® Provider plug-in. Schematics also provides pre-defined Terraform templates that you can easily install from the IBM Cloud® catalog.



 Creating a Red Hat OpenShift cluster by using Terraform 

Before you can assign cluster access by using Terraform, follow the steps to create a Red Hat OpenShift cluster using Terraform. If you already have a cluster, see [Assigning IAM user access](https://cloud.ibm.com/docs/openshift?topic=openshift-terraform-setupterraform-cluster-IAM).

Before you begin, make sure that you have the [required access](https://cloud.ibm.com/docs/openshift?topic=openshift-access_reference) to create and work with Red Hat OpenShift on IBM Cloud resources.



1. Follow the [Terraform on IBM Cloud® getting started tutorial](https://cloud.ibm.com/docs/ibm-cloud-provider-for-terraform?topic=ibm-cloud-provider-for-terraform-getting-started) to install the Terraform CLI and configure the IBM Cloud® Provider plug-in for Terraform.
ssh -i <filepath_to_key_file> <username>@<IP_address>
5. Update your host to have the required RHEL packages. For more information about how to install these package, see the [Red Hat documentation](https://access.redhat.com/solutions/253273).
6. Run the script.

sudo nohup bash /tmp/attach.sh &
7. Check the progress of the registration script.

journalctl -f -u ibm-host-attach
8. As you run the scripts on each machine, check that your hosts are shown in the Hosts tab of your location dashboard. This process might take a few minutes to complete. All hosts show a Health status of Ready when a heartbeat for the machine can be detected, and a Status of Unassigned as the hosts are not yet assigned to your Satellite control plane or a Red Hat OpenShift cluster.
9. After you have attached your hosts, assign them to the [Satellite control plane](https://cloud.ibm.com/docs/satellite?topic=satellite-setup-control-plane) or use them to create a [Red Hat OpenShift on IBM Cloud cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-satellite-clusters).



If your host is not attaching to your location, you can log in to the host to debug it. For more information, see [Logging in to a RHEL host machine to debug](https://cloud.ibm.com/docs/satellite?topic=satellite-ts-hosts-login).

After you attach a host to your location, Satellite disables the ability to log in to the host as root with SSH for security purposes. You might see error messages if you try to SSH as root into a host that is attached successfully to a location. To restore the ability to SSH into the machine, you can [remove the host](https://cloud.ibm.com/docs/satellite?topic=satellite-host-remove) and reload the operating system.
Running, adding, or changing custom programs are not supported on IBM Cloud Qiskit Runtime. If you used this function previously, you can instead use code that calls primitives. To get performance benefits comparable to uploaded programs, you can use use sessions, which are a service aware context manager that minimizes artificial queuing latency inside an iterative workload.



Red Hat OpenShift for HPC



* What locations are available for deploying VPC resources?

Available regions and zones for deploying VPC resources, and a mapping of those to city locations and data centers can be found in [Locations for resource deployment](https://cloud.ibm.com/docs/overview?topic=overview-locations).
* What permissions do I need in order to create a cluster using the offering?

Instructions for setting the appropriate permissions for IBM Cloud services that are used by the offering to create a cluster can be found in [User access permissions](https://cloud.ibm.com/docs/openshift?topic=openshift-access_referencecluster_create_permissions).
* How many worker nodes can I deploy in my Red Hat OpenShift cluster through this offering?

Before you deploy a cluster, it is important to ensure that the cluster-related resource quota settings in your IBM Cloud account are appropriate for the size of the cluster that you would like to create. For more information, see [Service and quota limitations](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_limitationstech_limits).

The maximum number of worker nodes that are supported for the worker_nodes_per_zone deployment value is 1,000 (see [Deployment values](https://cloud.ibm.com/docs/hpc-openshift?topic=hpc-openshift-deployment-values)). However, the default quota, as noted in [Service and quota limitations](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_limitationstech_limits), is 500 worker nodes across all of the clusters in a region.
Planning app deployments 

Before you deploy an app to a Red Hat® OpenShift® on IBM Cloud® cluster, decide how you want to set up your app so that your app can be accessed properly and be integrated with other services in IBM Cloud.



 Moving workloads to Red Hat OpenShift on IBM Cloud 

Learn what kinds of workloads can be run on Red Hat OpenShift on IBM Cloud, and the optimal way to set up these workloads.



 What kind of apps can I run in Red Hat OpenShift on IBM Cloud? 

Your containerized app must be able to run on the supported operating system, RHEL 7. You also want to consider the statefulness of your app.

Stateless apps
: Stateless apps are preferred for cloud-native environments like Kubernetes. They are simple to migrate and scale because they declare dependencies, store configurations separately from the code, and treat backing services such as databases as attached resources instead of coupled to the app. The app pods don't require persistent data storage or a stable network IP address, and as such, pods can be terminated, rescheduled, and scaled in response to workload demands. The app uses a Database-as-a-Service for persistent data, and NodePort, load balancer, or Ingress services to expose the workload on a stable IP address.

Stateful apps
: Stateful apps are more complicated than stateless apps to set up, manage, and scale because the pods require persistent data and a stable network identity. Stateful apps are often databases or other distributed, data-intensive workloads where processing is more efficient closer to the data itself. If you want to deploy a stateful app, you need to set up persistent storage and mount a persistent volume to the pod that is controlled by a StatefulSet object.
Setting up the API 

Red Hat® OpenShift® on IBM Cloud® shares the same application programming interface (API) as IBM Cloud Kubernetes Service, so that you can use the same methods to consistently create and manage your community Kubernetes or Red Hat OpenShift clusters. To use the CLI, see [Setting up the CLI](https://cloud.ibm.com/docs/openshift?topic=openshift-cli-install).



 About the API 

The Red Hat OpenShift on IBM Cloud API automates the provisioning and management of IBM Cloud infrastructure resources for your clusters so that your apps have the compute, networking, and storage resources that they need to serve your users.

The API supports the different infrastructure providers that are available for you to create clusters. For more information, see [Overview of Classic and VPC infrastructure providers](https://cloud.ibm.com/docs/openshift?topic=openshift-infrastructure_providers).

You can use the version two (v2) API to manage both classic and VPC clusters. The v2 API is designed to avoid breaking existing functionality when possible. However, make sure that you review the following differences between the v1 and v2 API.

API endpoint prefix
: v1 API: https://containers.cloud.ibm.com/global/v1
: v2 API: https://containers.cloud.ibm.com/global/v2

API reference docs
: v1 API: [https://containers.cloud.ibm.com/global/swagger-global-api/](https://containers.cloud.ibm.com/global/swagger-global-api//)
: v2 API: [https://containers.cloud.ibm.com/global/swagger-global-api/](https://containers.cloud.ibm.com/global/swagger-global-api//).

API architectural style
: v1 API: Representational state transfer (REST) that focuses on resources that you interact with through HTTP methods such as GET, POST, PUT, PATCH, and DELETE.
Getting help and support for Red Hat OpenShift on IBM Cloud 

Still having issues with your cluster? Review different ways to get help and support for your Red Hat OpenShift on IBM Cloud clusters. For any questions or feedback, post in Slack.



 General ways to resolve cluster issues 



1. Keep your cluster environment up to date.



* Check monthly for available security and operating system patches to [update your worker nodes](https://cloud.ibm.com/docs/containers?topic=containers-updateworker_node).
* [Update your cluster](https://cloud.ibm.com/docs/containers?topic=containers-updatemaster) to the latest default version for [Red Hat OpenShift](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_versions).



2. Make sure that your command line tools are up to date.



* In the command line, you are notified when updates to the ibmcloud CLI and plug-ins are available. Be sure to keep your CLI up-to-date so that you can use all available commands and options.
* Make sure that [your oc CLI](https://cloud.ibm.com/docs/openshift?topic=openshift-cli-install) client matches the same Kubernetes version as your cluster server. [Kubernetes does not support](https://kubernetes.io/releases/version-skew-policy/)oc client versions that are 2 or more versions apart from the server version (n +/- 2).









 Reviewing issues and status 



1. To see whether IBM Cloud is available, [check the IBM Cloud status page](https://cloud.ibm.com/status?selected=status).
2. Filter for the Kubernetes Service component.
3. Review the [limitations and known issues documentation](https://cloud.ibm.com/docs/containers?topic=containers-limitations).
4.
Before you begin, make sure that you have the [required access](https://cloud.ibm.com/docs/openshift?topic=openshift-access_reference) to create and work with Red Hat OpenShift on IBM Cloud resources.



1. Follow the [Terraform on IBM Cloud® getting started tutorial](https://cloud.ibm.com/docs/ibm-cloud-provider-for-terraform?topic=ibm-cloud-provider-for-terraform-getting-started) to install the Terraform CLI and configure the IBM Cloud® Provider plug-in for Terraform. The plug-in abstracts the IBM Cloud® APIs that are used to provision, update, or delete Red Hat OpenShift service instances and resources.
2. Follow the tutorial to [create single and multi-zone clusters with Terraform](https://cloud.ibm.com/docs/ibm-cloud-provider-for-terraform?topic=ibm-cloud-provider-for-terraform-tutorial-tf-clusterscreate-cluster).
3. Optional: [Use Terraform to configure IAM user access policies for your Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-terraform-setupterraform-cluster-IAM).







 Assigning IAM user access to Red Hat OpenShift clusters 

You can use Terraform to assign IAM user access for Red Hat OpenShift clusters in an IBM Cloud account. For more information on using Terraform with IAM policies, see [the IBM Cloud provider Terraform documentation](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs).



1. In your Terraform directory, create a configuration file that is named iam.tf. In your iam.tf file, add the configuration parameters to create an IAM user access policy for a Red Hat OpenShift cluster by using the HashiCorp Configuration Language (HCL). The following example configuration creates the ibm_iam_user_policy and then assigns the policy to a specified cluster.
If the deployment target is a Red Hat OpenShift cluster, select a project or create a new one.
3. Click Next.
4. Configure your IBM Cloud Schematics workspace.
5. Click Next.
6. If applicable, review the license agreements, and select I have read and agree to the following license agreements:.
7. Click Validate.







 Terraform 



1. From the Validate product tab, configure your IBM Cloud Schematics workspace.
2. Click Next.
3. If applicable, review the license agreements, and select I have read and agree to the following license agreements:.
4. Click Validate.







 Operator from GitHub repository 



1. From the Validate product tab, select your Red Hat OpenShift cluster.
2. Select a project or create a new one. A project is similar to a Kubernetes cluster namespace, and the list is populated from your Red Hat OpenShift environment.
3. Click Next.
4. Configure your IBM Cloud Schematics workspace.
5. Click Next.
6. If applicable, review the license agreements, and select I have read and agree to the following license agreements:.
7. Click Validate.







 Operator from Red Hat registry 



1. From the Validate product tab, select an update channel.
2. Select an approval strategy.
3. Select your Red Hat OpenShift cluster.
4. Select a project or create a new one. A project is similar to a Kubernetes cluster namespace, and the list is populated from your Red Hat OpenShift environment.
5. Click Next.
6. Configure your IBM Cloud Schematics workspace.
7. Click Next.
8. If applicable, review the license agreements, and select I have read and agree to the following license agreements:.
9. Click Validate.







 OVA image 



1.
Select 8 vCPUs, 32 GB RAM for Flavor and at least 3 Worker nodes per data center for the test environment.
9. Enter a Cluster name and optionally Tags.
10. In the Summary pane, review the order summary and then click Create.



For additional information on the fields, see [Creating a classic standard cluster in the console](https://cloud.ibm.com/docs/openshift?topic=openshift-clustersclusters_ui).





 Provisioning your jump host 

The instructions for implementing SAP Data Hub on the Red Hat OpenShift on IBM Cloud cluster follow [SAP Data Hub 2 on OpenShift Container Platform 3](https://access.redhat.com/articles/3630111), which lays out the [jump host's requirements](https://access.redhat.com/articles/3630111jump-server-requirements). You can either use a suitable jump server that is connected to the Red Hat OpenShift on IBM Cloud cluster in IBM Cloud, or you can use the following steps to create an IBM® Virtual Servers instance to serve as your jump host.



1. Once you've confirmed that the Red Hat OpenShift on IBM Cloud cluster is building, select the Menu icon ![Menu icon](https://cloud.ibm.com/docs-content/v1/content/icons/icon_hamburger.svg) > Classic Infrastructure > Device List.
2. Click Order devices + -
3. Select Virtual Servers for Classic.
4. Leave the default values for Type of virtual server, Quantity, and Billing.
5. Enter a name, for example jump4sdh, for Hostname. Click Information for formatting specifics.
6. Enter a name, for example, sdh.com for Domain. Domain is the identification string that defines administrative control within the internet. Click Information for formatting specifics.
7. Select your Placement group, default is None.
8. Select the Location of the data center (zone) where you set up your Red Hat OpenShift on IBM Cloud cluster.
9.
* Log in to the Red Hat OpenShift web console by using the IBM Cloud console. In the console, select OpenShift > Clusters > select your cluster > OpenShift Web Console.
* Connect to Red Hat OpenShift on the command line by:



* [Logging in to IBM Cloud](https://cloud.ibm.com/docs/cli?topic=cli-ibmcloud_cliibmcloud_login) by using the IBM Cloud CLI. You can do this by running make login_ibmcloud (inside this repository).
* [Getting the cluster configuration](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_cluster_config) by using the IBM Cloud CLI. You can do this by running make get_cluster_config (inside this repository).
* Logging in to Red Hat OpenShift by running make login_cluster (inside this repository).









 Cleanup 

There is no fully documented or automated cleanup process yet. However, you can try these options:



* Destroy the resources that are in the Schematics workspace that is associated with your location. Destroying the resources deletes the location and the AWS EC2 virtual machines. Be sure to double-check this in the AWS console. For more information, see [Deleting a workspace](https://cloud.ibm.com/docs/schematics?topic=schematics-workspace-setup&interface=uidel-workspace).
* You might want to remove the cluster from your IBM Cloud console. For more information, see [Removing clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-remove).
You can import an image from IBM Cloud Container Registry into the internal registry of your Red Hat OpenShift cluster by tagging the image as an [image stream](https://docs.openshift.com/container-platform/4.11/openshift_images/image-streams-manage.html). With this setup, you can deploy apps from the image by using the local cache of the internal registry, which can make your app deployments build faster. Also, deployments in other projects can refer to the image stream so that you don't have to create image pull secret credentials to IBM Cloud Container Registry in each project.

If you update your image in IBM Cloud Container Registry, the image is not pulled automatically into the internal registry of your Red Hat OpenShift cluster. Instead, [configure periodic importing](https://docs.openshift.com/container-platform/4.11/openshift_images/image-streams-manage.htmlimages-imagestreams-import_image-streams-managing), or repeat these steps to tag the image. Depending on the image pull policy that you use in your deployment, you might also need to restart your deployment.

Want to learn more about how builds, image streams, and the internal registry work together? Read the [Red Hat OpenShift docs](https://docs.openshift.com/container-platform/4.11/registry/index.html), or check out [this blog on managing container images](https://blog.cloudowski.com/articles/why-managing-container-images-on-openshift-is-better-than-on-kubernetes).



1. [Access your Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster).
2. Switch to the default project to pull your image into the image stream. The default project is already set up with credentials to access the icr.io registries.

oc project default
3. List the available images in your IBM Cloud Container Registry.