vania-janet/multiturn-rag-retrieval-data huggingface dataset:
London (eu-gb) kubectl apply -f https://assets.eu-gb.logging.cloud.ibm.com/clients/logdna-agent-ds-os.yaml -n ibm-observe 
 Toronto (ca-tor) kubectl apply -f https://assets.ca-tor.logging.cloud.ibm.com/clients/logdna-agent-ds-os.yaml -n ibm-observe 
 Dallas (us-south) kubectl apply -f https://assets.us-south.logging.cloud.ibm.com/clients/logdna-agent-ds-os.yaml -n ibm-observe 
 Washington (us-east) kubectl apply -f https://assets.us-east.logging.cloud.ibm.com/clients/logdna-agent-ds-os.yaml -n ibm-observe 









 Step 5. Forward your API audit logs 

Follow the [forwarding Kubernetes API audit logs steps](https://cloud.ibm.com/docs/openshift?topic=openshift-health-auditaudit-api-server-la) to configure the system to collect and forward events from your Kubernetes API server to IBM® Log Analysis.





 Step 6. Verify that the logging agent is deployed successfully 

To verify that the logging agent is deployed successfully, run the following command:



1. Target the project where the logging agent is deployed.

oc project ibm-observe
2. Verify that the pods on each node are in a Running status.

oc get pods -n PROJECT_NAME

For example, the following command lists all the pods in the namespace ibm-observe.

oc get pods -n ibm-observe



The deployment is successful when you see one or more logging pods.



* The number of logging pods equals the number of worker nodes in your cluster.
* All pods must be in a Running state.
* Stdout and stderr are automatically collected and forwarded from all containers. Log data includes application logs and worker logs.
If you choose to manually assign hosts, you must [label your worker nodes](https://cloud.ibm.com/docs/satellite?topic=satellite-storage-azurefile-csi-driverazure-file-label-nodes) before creating your storage configuration.
2. [Set up Satellite Config](https://cloud.ibm.com/docs/satellite?topic=satellite-setup-clusters-satconfig).
3. [Create a Satellite cluster](https://cloud.ibm.com/docs/satellite?topic=openshift-satellite-clusters) that runs on compute hosts in Azure. Make sure that you select the Enable cluster admin access for Satellite Config option when you create the cluster. If you don't enable Administrator (admin) access for Satellite Config when creating your cluster, you must re-create your cluster and enable admin access before you can deploy storage.





 Optional: Labeling your worker nodes when using Azure File 

Complete the following steps to add the required labels to your worker nodes for the Azure File CSI driver template.

If you manually assigned your Azure hosts to your location and did not use an automated deployment such as deploying from the console or a Terraform template, then you must [label your worker nodes](https://cloud.ibm.com/docs/satellite?topic=satellite-storage-azurefile-csi-driverazure-file-label-nodes) before creating your storage configuration.



1. List your Azure worker nodes and make a note of the name of each node.

oc get nodes
2. Get the details of each node and make a note of the zone that the node is in. For example: eastus-1.

oc get nodes NODE-NAME -o yaml | grep zone
3. Label your Azure worker nodes with the zone value that you retrieved earlier. Replace <node_name> and <zone> with the node name and zone of your worker nodes. For example, if you have a worker node in zone: eastus-1, use the following commands to add eastus-1 as a label to the worker node in the eastus-1 zone.
Preparing and Installing SAP Data Intelligence 

In the previous chapter we have created a Red Hat OpenShift on IBM Cloud cluster and prepared the jump host. The next steps cater to the preparation of the cluster to be ready for the SAP Data Intelligence installation.

The instructions for implementing SAP Data Intelligence on the Red Hat OpenShift on IBM Cloud cluster follow the Red hat article (RHA) [SAP Data Intelligence 3 on OpenShift Container Platform 4](https://access.redhat.com/articles/5100521) starting from [3.3. OCP Post Installation Steps](https://access.redhat.com/articles/5100521ocp-post-installation), because in this scenario Red Hat OpenShift on IBM Cloud 4.8.x already has been provisioned.



 Setting the sdi role for the worker nodes for SAP Data Intelligence 

According to section [3.3.4.1. Label the compute nodes for SAP Data Intelligence](https://access.redhat.com/articles/5100521ocp-post-label-nodes) in the RHA, set the sdi role for the worker nodes that will be considered by Red Hat's SDI observer. See below the parameter SDI_NODE_SELECTOR in the SDI observers's installation script.



1. Determine the nodes' names.

oc get nodes

Example output:

NAME STATUS ROLES AGE VERSION
10..177 Ready master,worker 1d v1.21.8+ed4d8fd
10..182 Ready master,worker 1d v1.21.8+ed4d8fd
10..185 Ready master,worker 1d v1.21.8+ed4d8fd
2. Set the nodes' role.

$ oc label node/10..177 node-role.kubernetes.io/sdi=""
$ oc label node/10..182 node-role.kubernetes.io/sdi=""
$ oc label node/10..185 node-role.kubernetes.io/sdi=""
3. Check the nodes.
Do the clusters of worker nodes in your VPC need to send and receive information to and from IBM Cloud classic infrastructure? Follow the steps in [Creating VPC subnets for classic access](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-subnetsca_subnet_cli) to create a classic-enabled VPC and VPC subnets without the automatic default address prefixes.
3. [Create a subnet for your VPC](https://cloud.ibm.com/docs/vpc?topic=vpc-creating-vpc-resources-with-cli-and-api&interface=clicreate-a-subnet-cli).



* If you want to create a [multizone cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-ha_clustersmz-clusters), repeat this step to create additional subnets in all the zones that you want to include in your cluster.
* VPC subnets provide IP addresses for your worker nodes and load balancer services in the cluster, so [create a VPC subnet with enough IP addresses](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-subnetsvpc_basics_subnets), such as 256. You can't change the number of IPs that a VPC subnet has later.
* Do not use the following reserved ranges: 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16, and 172.20.0.0/16.
* If worker nodes must access public endpoints, or if you plan to enable both the public and private cloud service endpoints, you must [attach a public gateway](https://cloud.ibm.com/docs/vpc?topic=vpc-creating-vpc-resources-with-cli-and-api&interface=cliattach-public-gateway-cli) to each subnet to access default Red Hat OpenShift components such as the web console or OperatorHub.
In the example YAML, the affinity section has publicVLAN as the key and "2234945" as the value.
4. Apply the updated deployment configuration file.

oc apply -f with-node-affinity.yaml
5. Verify that the app pods deployed to worker nodes connected to the designated VLAN.



1. List the pods in your cluster. Replace <selector> with the label that you used for the app.

oc get pods -o wide app=<selector>

Example output

NAME READY STATUS RESTARTS AGE IP NODE
cf-py-d7b7d94db-vp8pq 1/1 Running 0 10d 172.30.xxx.xxx 10.176.48.78
2. In the output, identify a pod for your app. Note the NODE ID of the worker node that the pod is on.

In the example output of the previous step, the app pod cf-py-d7b7d94db-vp8pq is on worker node 10.176.48.78.
3. List the details for the worker node.

oc describe node <worker_node_ID>

Example output

NAME: 10.xxx.xx.xxx
Role:
Labels: arch=amd64
beta.kubernetes.io/arch=amd64
beta.kubernetes.io/os=linux
failure-domain.beta.kubernetes.io/region=us-south
failure-domain.beta.kubernetes.io/zone=dal10
ibm-cloud.kubernetes.io/encrypted-docker-data=true
kubernetes.io/hostname=10.xxx.xx.xxx
privateVLAN=2234945
publicVLAN=2234967
...
4. In the Labels section of the output, verify that the public or private VLAN is the VLAN that you designated in previous steps.
Because myapp2 is on a worker node that is on a private VLAN only, the VRA acts as a secure connection between the worker nodes and the on-premises network. The VRA uses the destination IP address to determine which network packets to send to the on-premises network.
3. The request is encrypted and sent over the VPN tunnel to the on-premises data center.
4. The incoming request passes through the on-premises firewall and is delivered to the VPN tunnel endpoint (router) where it is decrypted.
5. The VPN tunnel endpoint (router) forwards the request to the on-premises server or mainframe, depending on the destination IP address that was specified in step 2. The necessary data is sent back over the VPN connection to myapp2 through the same process.



To set up a Virtual Router Appliance,



1. [Order a VRA](https://cloud.ibm.com/docs/virtual-router-appliance).
2. [Configure the private VLAN on the VRA](https://cloud.ibm.com/docs/virtual-router-appliance?topic=virtual-router-appliance-managing-vlans-and-gateway-appliances).
3. To enable a VPN connection by using the VRA, [configure VRRP on the VRA](https://cloud.ibm.com/docs/virtual-router-appliance?topic=virtual-router-appliance-working-with-high-availability-and-vrrphigh-availability-vpn-with-vrrp).



If you have an existing router appliance and then add a cluster, the new portable subnets that are ordered for the cluster are not configured on the router appliance. To use networking services, you must enable routing between the subnets on the same VLAN by [enabling VLAN spanning or VRF](https://cloud.ibm.com/docs/containers?topic=containers-plan_basicsworker-worker).
After removing the worker nodes from the dedicate host, follow the steps to [remove each dedicated host from the dedicated host pool](https://cloud.ibm.com/docs/openshift?topic=openshift-dedicated-hostsremove-dedicated-hosts-cli).
3. List your dedicated host pools and make a note of the pool that you want to remove.

ibmcloud oc dedicated host pool ls
4. Get the details of your dedicated host pool.

ibmcloud oc dedicated pool get --pool POOL
5. Get the details of each host in the pool and verify no worker nodes are placed on it.

ibmcloud oc dedicated host get --pool POOL --host HOST
6. Delete the dedicated host pool.

ibmcloud oc dedicated pool rm ---pool POOL
7. Verify the dedicated host pool is removed.

ibmcloud oc dedicated pool get --pool POOL
image: us.icr.io/NAMESPACE/redhat/redhat-operator-index:v4.10 Add your registry
sourceType: grpc
displayName: Red Hat Operators
publisher: Red Hat
updateStrategy:
registryPoll:
interval: 10m0s
secrets: Add the odf-secret
- "odf-secret"
6. Create the catalog source in your cluster.

oc create -f catalogSource-redhat-operator-index.yaml
7. Verify that the pods and packagemanifest are created in your cluster.

oc get pods,packagemanifest -n openshift-marketplace







 Step 11: Update your image pull secret 



1. Extract the global pull secret to a file called .dockerconfigjson.

oc extract secret/pull-secret -n openshift-config --to=.

Example output

.dockerconfigjson
2. Print the details of your auth.json file.

printf auth.json
3. Add the icr.io section from auth.json to your .dockerconfigjson.

{"auths": {"us.icr.io": {"auth": "BASE64-VALUE","email": "IBM-EMAIL"}}}
4. Update the pull secret in the openshift-config namespace to use your .dockerconfigjson.

oc set data secret/pull-secret -n openshift-config --from-file=.dockerconfigjson







 Step 12: Replace each worker node to pick up configuration changes 



1. Get a list of nodes in your cluster.

ibmcloud oc worker ls -c CLUSTER
2. Run the ibmcloud oc worker replace to replace each worker node in your cluster.

ibmcloud oc worker replace -c CLUSTER --worker WORKER-NODE







 Step 13: Update the registries.conf file on each noderegistries.conf file on each node
[Manually add](https://cloud.ibm.com/docs/openshift?topic=openshift-utilitiesmanual_block) a 3 GB block storage device to at least 3 worker nodes in your cluster and find the device path. To find the device path after attaching the disk, log in to your worker node with oc debug <node> and run lsblk to list the devices on that node.
* Select one of the block storage devices that you added earlier and find the device path. To find the device path after attaching the disk, log in to your worker node with oc debug <node> and run lsblk to list the devices on that node.



5. [Attach the block storage](https://cloud.ibm.com/docs/openshift?topic=openshift-utilitiesattach_block) to your worker nodes.
6. Continue with your Portworx setup by [Setting up a key-value store for Portworx metadata](https://cloud.ibm.com/docs/openshift?topic=openshift-storage_portworx_kv_store).







 VPC clusters 

Virtual Private Cloud



1. Follow the [steps](https://cloud.ibm.com/docs/openshift?topic=openshift-utilitiesvpc_cli_attach) to create the Block Storage for VPC instances and attach these to each worker node that you want to add to the Portworx storage layer. For highly available data storage, Portworx requires at least 3 worker nodes with raw and unformatted block storage.
2. If you want to use [journal devices](https://docs.portworx.com/install-with-other/operate-and-maintain/performance-and-tuning/tuning/), choose from the following options. Journal devices allow Portworx to write logs directly to a local disk on your worker node.
selector Replace <my-selector-key> and <my-selector-value> with the key/value pair that you used in the spec.template.metadata.labels section of your deployment YAML. To associate the service with the deployment, the selector must match the deployment labels. 
 port Replace <8081> with the port that your service listens on. 
 nodePort Optional: Replace <31514> with a NodePort in the 30000 - 32767 range. Do not specify a NodePort that is already in use by another service. If no NodePort is assigned, a random one is assigned for you. <br>To specify a NodePort and see which NodePorts are already in use, run the kubectl get svc command. Any NodePorts in use appear under the Ports field. 



2. Save the updated configuration file.
3. When the app is deployed, you can use the public IP address of any worker node and the NodePort to form the public URL to access the app in a browser. If your worker nodes are connected to a private VLAN only, then a private NodePort service was created and can be accessible through a worker node's private IP address.



1. Get the public IP address for a worker node in the cluster. If you want to access the worker node on a private network or have a VPC cluster, get the private IP address instead.

ibmcloud ks worker ls --cluster <cluster_name>

Output

ID Public IP Private IP Size State Status
prod-dal10-pa215dcf5bbc0844a990fa6b0fcdbff286-w1 192.0.2.23 10.100.10.10 u3c.2x4 normal Ready
prod-dal10-pa215dcf5bbc0844a990fa6b0fcdbff286-w2 192.0.2.27 10.100.10.15 u3c.2x4 normal Ready
2. If a random NodePort was assigned, find out which one was assigned.

kubectl describe service <service_name>

Output

NAME: <service_name>
selector Replace <my-selector-key> and <my-selector-value> with the key/value pair that you used in the spec.template.metadata.labels section of your deployment YAML. To associate the service with the deployment, the selector must match the deployment labels. 
 port Replace <8081> with the port that your service listens on. 
 nodePort Optional: Replace <31514> with a NodePort in the 30000 - 32767 range. Do not specify a NodePort that is already in use by another service. If no NodePort is assigned, a random one is assigned for you. <br>To specify a NodePort and see which NodePorts are already in use, run the oc get svc command. Any NodePorts in use appear under the Ports field. 



2. Save the updated configuration file.
3. When the app is deployed, you can use the public IP address of any worker node and the NodePort to form the public URL to access the app in a browser. If your worker nodes are connected to a private VLAN only, then a private NodePort service was created and can be accessible through a worker node's private IP address.



1. Get the public IP address for a worker node in the cluster. If you want to access the worker node on a private network or have a VPC cluster, get the private IP address instead.

ibmcloud oc worker ls --cluster <cluster_name>

Output

ID Public IP Private IP Size State Status
prod-dal10-pa215dcf5bbc0844a990fa6b0fcdbff286-w1 192.0.2.23 10.100.10.10 u3c.2x4 normal Ready
prod-dal10-pa215dcf5bbc0844a990fa6b0fcdbff286-w2 192.0.2.27 10.100.10.15 u3c.2x4 normal Ready
2. If a random NodePort was assigned, find out which one was assigned.

oc describe service <service_name>

Output

NAME: <service_name>
When the download of the configuration files is finished, a command is displayed that you can use to set the path to the local Kubernetes configuration file as an environment variable. Copy and paste the command that is displayed in your terminal to set the KUBECONFIG environment variable.

Every time you log in to the IBM Cloud Kubernetes Service CLI to work with your cluster, you must run this setup to set the path to the cluster's configuration file as a session variable. IBM Cloud Kubernetes Service uses this variable to find a local configuration file and certificates that are necessary to connect with your cluster.
3. Create a Kubernetes secret to store your logging ingestion key for your service instance. The logging ingestion key is used to open a secure web socket to the logging ingestion server and to authenticate the logging agent with the IBM Log Analysis service.

kubectl create secret generic logdna-agent-key --from-literal=logdna-agent-key=<logDNA_ingestion_key>
4. Create a Kubernetes daemon set to deploy the logging agent on every worker node of your Kubernetes cluster. The logging agent collects logs with the extension .log and extensionsless files that are stored in the /var/log directory of your pod. By default, logs are collected from all namespaces, including kube-system, and automatically forwarded to the IBM Log Analysis service.

kubectl create -f https://assets.us-south.logging.cloud.ibm.com/clients/logdna-agent-ds.yaml
5. Verify that the logging agent is deployed successfully.

kubectl get pods

The deployment is successful when you see one or more logging pods. The number of logging pods equals the number of worker nodes in your cluster. All pods must be in a Running state.







 Step 4: Launch the logging dashboard and view logs 

To launch the logging dashboard through the IBM Cloud console, complete the following steps:



1. Log in to your [IBM Cloud account](https://cloud.ibm.com/login).
2. From the menu !
7. Apply the updated deployment configuration file.

kubectl apply -f with-node-affinity.yaml
8. Verify that the app pods deployed to the correct worker nodes.



1. List the pods in your cluster. In the output, identify a pod for your app. Note the NODE private IP address of the worker node that the pod is on.

kubectl get pods -o wide

In this example output, the app pod cf-py-d7b7d94db-vp8pq is on a worker node with the IP address 10.240.01.00.

NAME READY STATUS RESTARTS AGE IP NODE
cf-py-d7b7d94db-vp8pq 1/1 Running 0 15d 172.30.xxx.xxx 10.240.01.00
2. List the worker nodes in your cluster. In the output, look for the worker nodes in the zone where you attached the public gateway. Verify that the worker node with the private IP address that you identified in the previous step is deployed in this zone.

ibmcloud ks worker ls --cluster <cluster_name_or_ID>

Example output

ID Primary IP Flavor State Status Zone Version
kube-bl25g33d0if1cmfn0p8g-vpctest-default-000005ac 10.240.02.00 c2.2x4 normal Ready us-south-2 1.26.6
kube-bl25g33d0if1cmfn0p8g-vpctest-default-00000623 10.240.01.00 c2.2x4 normal Ready us-south-1 1.26.6



9. Optional: If you use [access control lists (ACLs)](https://cloud.ibm.com/docs/containers?topic=containers-vpc-network-policy) to control your cluster network traffic, create inbound and outbound rules in this subnet's ACL to allow ingress from and egress to the external public endpoints that your pods must access.
Worker nodes are automatically provisioned with optimized kernel performance, but you can change the default settings by applying a custom [Kubernetes DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) with an [init Container](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/) to your cluster. The daemon set modifies the settings for all existing worker nodes and applies the settings to any new worker nodes that are provisioned in the cluster. The init container makes sure that these modifications occur before other pods are scheduled on the worker node. No pods are affected.

You must have the [Manager IBM Cloud IAM service access role](https://cloud.ibm.com/docs/openshift?topic=openshift-userschecking-perms) for all namespaces to run the sample privileged initContainer. After the containers for the deployments are initialized, the privileges are dropped.

Before you begin: [Access your Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster).



1. Save the following daemon set in a file named worker-node-kernel-settings.yaml. In the spec.template.spec.initContainers section, add the fields and values for the sysctl parameters that you want to tune. This example daemon set changes the default maximum number of connections that are allowed in the environment via the net.core.somaxconn setting and the ephemeral port range via the net.ipv4.ip_local_port_range setting.

Depending on the systctl settings that you try to change, you might want to configure the security context. For more information, see the [Red Hat OpenShift documentation](https://docs.openshift.com/container-platform/4.11/nodes/containers/nodes-containers-sysctls.html).

apiVersion: apps/v1
kind: DaemonSet
metadata:
name: kernel-optimization
Add the CPU and memory usage amounts to the [worker node resource reserves](https://cloud.ibm.com/docs/openshift?topic=openshift-planning_worker_nodesresource_limit_node) that are set for each worker node by default.
4. Subtract the worker node reserved and default app usage amounts from the total worker node size. This amount represents the total compute resources of your worker nodes before you deploy any apps or other workloads.



3. [Deploy your apps](https://cloud.ibm.com/docs/containers?topic=containers-deploy_app) to the cluster, and make sure to [set resource requests and limits](https://cloud.ibm.com/docs/containers?topic=containers-appresourcereq) based on the [app size that you previously estimated](https://cloud.ibm.com/docs/openshift?topic=openshift-strategysizing_resources) for your apps, to limit the amount of compute resources the apps can consume.
4. Deploy any add-ons, plug-ins, or other cloud services that you want to use.
5. Review what compute resources your workloads consume and calculate the remaining cluster capacity to deploy additional apps or scale existing apps.



1. With at least the IBM Cloud IAM Reader service access role for the cluster in all namespaces: [Access your Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster).
2. List the pods that run in your cluster.

oc get pods --all-namespaces
3. Get the details of a pod. Note the limits and request map of the CPU and memory.

oc get pod -n <project> <pod> -o=jsonpath='{range .spec.containers[]} {.name}:{.resources}{"n"}{end}'
4. Repeat the previous step for each pod in your cluster.
5.