vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Reviewing service, API server, and worker node logs 

Forward audit logs for Red Hat OpenShift on IBM Cloud, the Kubernetes API server, and the worker nodes to a logging instance such as IBM Cloud® Activity Tracker. With audit logs, you're able to understand better what operations are initiated by users in your cluster, which can help you troubleshoot issues or report compliance to industry and internal standards.



 Kubernetes API server audit logs 

To monitor user-initiated, Kubernetes administrative activity made within your cluster, you can collect and forward audit events that are passed through your Kubernetes API server to IBM Log Analysis or an external server. Although the Kubernetes API server for your cluster is enabled for auditing by default, no auditing data is available until you set up log forwarding.



 Considerations and prerequisites 

Before you set up a Kubernetes API audit configuration, review the following information.



* To see how the audit webhook collects logs, check out the Red Hat OpenShift on IBM Cloud [openshift-audit policy](https://github.com/IBM-Cloud/kube-samples/blob/master/kube-audit/openshift-audit-policy.yaml). You can't modify the default policy or apply your own custom policy.
* For Kubernetes audit logs and verbosity, see the [Kubernetes documentation](https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/).
* Only one audit webhook can be created in a cluster.
* You must have the [Administrator IBM Cloud IAM platform access role](https://cloud.ibm.com/docs/openshift?topic=openshift-userschecking-perms) for the Red Hat OpenShift on IBM Cloud cluster.



To get started, follow the instructions to send Kubernetes API audit logs [to a resource in the IBM Cloud private network](https://cloud.ibm.com/docs/openshift?topic=openshift-health-auditaudit-api-server-priv).
Debugging your Portworx installation 

Virtual Private Cloud

Classic infrastructure

This troubleshooting topic applies to only Red Hat OpenShift clusters that run version 3.11.

 What’s happening 

When you create a Portworx service instance from the IBM Cloud catalog, the Portworx installation in your cluster fails and the service instance shows a status of Provision failure.

 Why it’s happening 

Before Portworx is installed in your cluster, a number of checks are performed to verify the information that you provided on the Portworx service page of the IBM Cloud catalog.

If one of these checks fails, the status of the Portworx service is changed to Provision failure. You can't see the details of what check failed or what information is missing to complete the installation.

 How to fix it 

Follow this guide to start troubleshooting your Portworx installation and to verify the information that you entered in the IBM Cloud catalog.

If you find information that you entered incorrectly or you must change the setup of your cluster, correct the information or the cluster setup. Then, create a new Portworx service instance to restart the installation.



 Step 1: Verifying the IBM Cloud catalog information 

Start by verifying that the information that you entered in the IBM Cloud catalog is correct. If information was entered incorrectly, the installation does not pass the pre-installation checks and fails without starting the installation.



1. Verify that the cluster where you want to install Portworx is located in the IBM Cloud region and resource group that you selected.

ibmcloud oc cluster get --cluster <cluster_name_or_ID>
2. Verify that the IBM Cloud API key that you entered has sufficient permissions to work with your cluster. You must be assigned the Editor platform access role and the Manager service access role for Red Hat OpenShift on IBM Cloud. For more information, see [User access permissions](https://cloud.ibm.com/docs/openshift?topic=openshift-access_reference).
3. Verify that you entered the etcd API endpoint for your Databases for etcd service instance in the correct format.



1.
If you have a service access role, you might want to [verify your RBAC role](https://cloud.ibm.com/docs/openshift?topic=openshift-userschecking-rbac), too.
4. To review what the roles and allowed actions permit, see the following topics.



* [IAM roles and actions](https://cloud.ibm.com/docs/account?topic=account-iam-service-roles-actions)
* [Red Hat OpenShift on IBM Cloud user access permissions](https://cloud.ibm.com/docs/openshift?topic=openshift-access_reference)
* Satellite-only: [Satellite IAM platform and service roles](https://cloud.ibm.com/docs/satellite?topic=satellite-iam-assign-access)



5. To change or assign new access policies, see [Assigning Red Hat OpenShift on IBM Cloud roles](https://cloud.ibm.com/docs/openshift?topic=openshift-usersadd_users_cli) or [Assigning Satellite access](https://cloud.ibm.com/docs/satellite?topic=satellite-iam-assign-access).









 Checking RBAC roles 

Verify your custom RBAC or synchronized IAM service access to RBAC roles in your Red Hat OpenShift on IBM Cloud cluster.



 Checking RBAC roles from the UI 



1. Log in to the [Red Hat OpenShift clusters console](https://cloud.ibm.com/kubernetes/clusters?platformType=openshift).
2. Click the cluster with the RBAC roles that you want to check.
3. Click the Red Hat OpenShift web console.

If you have a private network only cluster, you might not be able to open the dashboard unless you are on a VPN.
* [Granting user permissions for VPC resources](https://cloud.ibm.com/docs/vpc?topic=vpc-managing-user-permissions-for-vpc-resources)
* [Managing user access for Schematics](https://cloud.ibm.com/docs/schematics?topic=schematics-access)
* [Assigning access to Secrets Manager](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-assign-access)
* [User access permissions for OpenShift](https://cloud.ibm.com/docs/openshift?topic=openshift-access_reference)







 Step 2: Generate API key 

Generate an API key for your IBM Cloud account where the Red Hat OpenShift cluster will be deployed. For more information, see [Managing user API keys](https://cloud.ibm.com/docs/account?topic=account-userapikey).





 Step 3: Create SSH key 

Create an SSH key in your IBM Cloud account. This is your SSH key that you will use to access the Red Hat OpenShift cluster. Ensure that the SSH key is present in the same resource group and region where the cluster is being provisioned. The offering supports passing multiple, comma-separated SSH keys, if the cluster needs multiple SSH keys. For more information, see [Managing SSH keys](https://cloud.ibm.com/docs/vpc?topic=vpc-managing-ssh-keys).





 Step 4: Next steps 

After you've gathered the necessary input values to define your cluster configuration, you are ready to deploy your Red Hat OpenShift cluster. The Red Hat OpenShift cluster can be deployed on IBM Cloud by using the IBM Cloud Schematics UI, Schematics CLI, or the Schematics APIs. If you want to deploy your cluster by using the CLI or API, review the prerequisites for your interface of choice:
ACLs consist of inbound and outbound rules that define which ingress and egress is permitted for each VPC subnet.

When you create a VPC cluster and enable both the public and private cloud service endpoints during cluster creation, the public cloud service endpoint is used by default for access to components such as the Red Hat OpenShift web console for your cluster. In order for console pods to establish a secure, public connection over the internet through the public service endpoint, you must enable a public gateway on each VPC subnet that your worker nodes are deployed to.

When you create a VPC cluster and enable only the private cloud service endpoint during cluster creation, the private cloud service endpoint is used by default to access Red Hat OpenShift components such as the Red Hat OpenShift web console or OperatorHub. You must be connected to the private VPC network, such as through a VPN connection, to access these components or run kubectl commands on your cluster.

The default IP address range for VPC subnets is 10.0.0.0 – 10.255.255.255. For a list of IP address ranges per VPC zone, see the [VPC default address prefixes](https://cloud.ibm.com/docs/vpc?topic=vpc-configuring-address-prefixes).

If you enable classic access when you create your VPC, [classic access default address prefixes](https://cloud.ibm.com/docs/vpc?topic=vpc-setting-up-access-to-classic-infrastructureclassic-access-default-address-prefixes) automatically determine the IP ranges of any subnets that you create. However, the default IP ranges for classic access VPC subnets conflict with the subnets for the Red Hat OpenShift on IBM Cloud control plane. Instead, you must [create the VPC without the automatic default address prefixes, and then create your own address prefixes and subnets within those ranges for your cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-subnetsclassic_access_subnets).

Need to create your cluster by using custom-range subnets?
[Kubernetes does not support](https://kubernetes.io/releases/version-skew-policy/)kubectl client versions that are 2 or more versions apart from the server version (n +/- 2). If you use a community Kubernetes cluster, you might also have the Red Hat OpenShift version of kubectl, which does not work with community Kubernetes clusters.

To check your client kubectl version against the cluster server version, run oc version --short.

 How to fix it 

[Install the version of the CLI](https://cloud.ibm.com/docs/openshift?topic=openshift-cli-install) that matches the version of your cluster.

If you have multiple clusters at different versions or different container platforms such as Red Hat OpenShift, download each kubectl version binary file to a separate directory. Then, you can set up an alias in your local command-line interface (CLI) profile to point to the kubectl binary file directory that matches the kubectl version of the cluster that you want to work with, or you might be able to use a tool such as brew switch kubernetes-cli <major.minor>.





 Time out when trying to connect to a pod 

 What’s happening 

You try to connect to a pod, such as logging in with oc exec or getting logs with oc logs. The pod is healthy, but you see an error message similar to the following.

Error from server: Get https://<10.xxx.xx.xxx>:<port>/<address>: dial tcp <10.xxx.xx.xxx>:<port>: connect: connection timed out

 Why it’s happening 

The OpenVPN server is experiencing configuration issues that prevent accessing the pod from its internal address.

 How to fix it 

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



1.
Additionally, the workstation must have a directory with write permissions and sufficient storage to store the backup. 125GB of storage space is sufficient for all deployments.

To take a backup, follow these steps:



1. Access the cluster where Data Security Broker Manager is deployed by logging into a Kubernetes or Red Hat OpenShift workstation.
2. To back up the MongoDB collections and Data Security Broker Manager configuration files, create the script provided below and execute it. The location that is specified after the -b option is where the backup file is kept by the script. Check whether the script is being used to back up a Data Security Broker Manager deployment on a Red Hat OpenShift cluster or a Kubernetes cluster, and uncomment the relevant command alias for the specified type of cluster where Data Security Broker Manager is installed.



!/bin/bash
if [ $ -eq 0 ]
then
echo "No arguments supplied"
echo "Usage: $0 -b <backup location> -n <k8s namespace>"
fi

while getopts b:n: flag
do
case "${flag}" in
b) backup=${OPTARG};;
n) namespace=${OPTARG};;
esac
done

if [ -z "${backup}" ];
then
echo "Please provide backup location with -b option"
exit
fi

if [! -d "$backup" ];
then
echo "Please provide a valid backup location with -b option"
exit
fi

if [ -z "${namespace}" ];
then
echo "Please provide a valid namespace with -n option"
exit
fi

 NOTE: SET THE kb ALIAS TO THE CORRECT ONE FOR THE CLUSTER TYPE

 For Kubernetes
kb='kubectl --namespace $namespace'
 For OpenShift
kb='kubectl --namespace '$namespace

 Retrieving container details


echo $kb
There may be other, yet unknown, uses for the data that require it to be accessed or stored in different ways.

So your trucks are flying around the country and data is pouring out of them. How do you make sure everyone gets the data they need? Enter [IBM Event Streams](https://www.ibm.com/cloud/event-streams), an event-streaming platform that helps you build smart apps that can react to events as they happen. It is a fully managed service built on open-source [Apache Kafka](https://www.ibm.com/cloud/learn/apache-kafka).

Event Streams can take in the data from the trucks (data producers) and then serve it to the various applications that will use it (data consumers).

Finally, you will need to run your Truck Tracker service somewhere, and for that we will use [Red Hat OpenShift on IBM Cloud](https://www.ibm.com/cloud/openshift), a fast and secure way to containerize and deploy enterprise workloads in Kubernetes clusters. We will provision an Red Hat OpenShift on IBM Cloud cluster, deploy our applications to it and make them available to the database services that need access to it. We will also make a public-facing application to view the positions of trucks on a map. Read more about [Red Hat OpenShift on IBM Cloud.](https://cloud.redhat.com/learn/what-is-openshift)





 What you will build 

This is the high-level system that we are going to build:

Zoom

![The Truck Tracker Solution](https://cloud.ibm.com/docs-content/v1/content/5561b38c6df9e8168523d143eaf64ab6acd7b600/cloud-databases/images/TruckTrackerOS.png)

Figure 1. The Truck Tracker Solution

In a real-life scenario, your data generators (the truck's IoT devices) would have to find a way to communicate with the Event Streams application, probably using the MQTT protocol.
There may be other, yet unknown, uses for the data that require it to be accessed or stored in different ways.

So your trucks are flying around the country and data is pouring out of them. How do you make sure everyone gets the data they need? Enter [IBM Event Streams](https://www.ibm.com/cloud/event-streams), an event-streaming platform that helps you build smart apps that can react to events as they happen. It is a fully managed service built on open-source [Apache Kafka](https://www.ibm.com/cloud/learn/apache-kafka).

Event Streams can take in the data from the trucks (data producers) and then serve it to the various applications that will use it (data consumers).

Finally, you will need to run your Truck Tracker service somewhere, and for that we will use [Red Hat OpenShift on IBM Cloud](https://www.ibm.com/cloud/openshift), a fast and secure way to containerize and deploy enterprise workloads in Kubernetes clusters. We will provision an Red Hat OpenShift on IBM Cloud cluster, deploy our applications to it and make them available to the database services that need access to it. We will also make a public-facing application to view the positions of trucks on a map. Read more about [Red Hat OpenShift on IBM Cloud.](https://cloud.redhat.com/learn/what-is-openshift)





 What you will build 

This is the high-level system that we are going to build:

Zoom

![The Truck Tracker Solution](https://cloud.ibm.com/docs-content/v1/content/4dfeb7bbbdd817dfbdb17402735fb55d9cfbc7fb/messages-for-rabbitmq/includes/cloud-databases/includes/cloud-databases/images/TruckTrackerOS.png)

Figure 1. The Truck Tracker Solution

In a real-life scenario, your data generators (the truck's IoT devices) would have to find a way to communicate with the Event Streams application, probably using the MQTT protocol.
There may be other, yet unknown, uses for the data that require it to be accessed or stored in different ways.

So your trucks are flying around the country and data is pouring out of them. How do you make sure everyone gets the data they need? Enter [IBM Event Streams](https://www.ibm.com/cloud/event-streams), an event-streaming platform that helps you build smart apps that can react to events as they happen. It is a fully managed service built on open-source [Apache Kafka](https://www.ibm.com/cloud/learn/apache-kafka).

Event Streams can take in the data from the trucks (data producers) and then serve it to the various applications that will use it (data consumers).

Finally, you will need to run your Truck Tracker service somewhere, and for that we will use [Red Hat OpenShift on IBM Cloud](https://www.ibm.com/cloud/openshift), a fast and secure way to containerize and deploy enterprise workloads in Kubernetes clusters. We will provision an Red Hat OpenShift on IBM Cloud cluster, deploy our applications to it and make them available to the database services that need access to it. We will also make a public-facing application to view the positions of trucks on a map. Read more about [Red Hat OpenShift on IBM Cloud.](https://cloud.redhat.com/learn/what-is-openshift)





 What you will build 

This is the high-level system that we are going to build:

Zoom

![The Truck Tracker Solution](https://cloud.ibm.com/docs-content/v1/content/99dae60bd0de1987ffcce4822e29b2bcdefe3a43/databases-for-mysql/includes/cloud-databases/includes/cloud-databases/images/TruckTrackerOS.png)

Figure 1. The Truck Tracker Solution

In a real-life scenario, your data generators (the truck's IoT devices) would have to find a way to communicate with the Event Streams application, probably using the MQTT protocol.
Attaching bare metal hosts to a location 

You can attach bare metal hosts to your Satellite location. After your hosts are attached, you can [set up Red Hat OpenShift virtualization](https://cloud.ibm.com/docs/satellite?topic=satellite-virtualization-location) in your Satellite location. By using virtualization, you can provision Windows or other virtual machines on your Bare Metal Servers in a managed Red Hat OpenShift space.

Supported host operating systems
: Red Hat CoreOS (RHCOS)

The following steps use IBM Cloud® Bare Metal Servers for Classic. However, you can adapt these steps for your own bare metal servers.



 Prerequisites 



* Create a RHCOS-enabled location. To check whether your location is RHCOS-enabled, see [Is my location enabled for Red Hat CoreOS?](https://cloud.ibm.com/docs/satellite?topic=satellite-locationsverify-coreos-location). If your location is not enabled, [create a new one with RHCOS](https://cloud.ibm.com/docs/satellite?topic=satellite-locations).
* Attach hosts to your location and set up your [location control plane](https://cloud.ibm.com/docs/satellite?topic=satellite-setup-control-plane).
* Find and record your bare metal host name. For this Bare Metal Server, this information is found in the Name field on the Overview page for your specific Bare Metal Servers.
* Find your bare metal server network information. For this Bare Metal Server, this information is found in the Network details section on the Overview page. Record the CIDR and gateway information for the public and private interfaces for your system.
* Create or identify an IBM Cloud Object Storage bucket to store your ignition file.
* Create or identify a cluster within the Satellite location that runs a supported operating system; for example, this tutorial uses a Red Hat OpenShift cluster that is running 4.11.



In addition, the Bare Metal Servers used in this example required the following prerequisites.
[Review the available contexts](https://cloud.ibm.com/docs/openshift?topic=openshift-cbr&interface=uicbr-overview) and determine the rules you want to create.
2. Follow the steps to [create context-based restrictions in the console](https://cloud.ibm.com/docs/account?topic=account-context-restrictions-create).









 Limitations 



* After you create a rule, it might take up to 10 minutes for the rule to take effect.
* Red Hat OpenShift on IBM Cloud CBR rules that apply to all API types or the cluster API types must not reference network zones that contain IPv6 addresses. The APIs included in the cluster type don't support IPv6.
* If you add Red Hat OpenShift on IBM Cloud resources to private-only network zones, the APIs for getting and listing clusters are still accessible over the public network.
* Red Hat OpenShift on IBM Cloud CBR rules that apply to all API types or the cluster API types must not reference other services like IBM Cloud Object Storage or Key Protect
* Red Hat OpenShift on IBM Cloud CBR rules that apply to all API types or the cluster API type do not support Report-only enforcement for the cluster API type.
* Red Hat OpenShift on IBM Cloud CBR rules that apply to all API types or the cluster API types are limited to no more than 20 IPs/subnets for private rules, and 200 IPs/subnets for public rules. These limits are expected to increase after the backend scalability of our implementation of Red Hat OpenShift on IBM Cloud CBR is updated.
* Red Hat OpenShift on IBM Cloud public CBR rules that apply to the cluster API type do not effect clusters that are private service endpoint only. All public traffic to the cluster APIserver is blocked. To use public CBR rules to control access to your cluster, update your cluster to enable public service endpoint.
* Due to a limitation with how Red Hat OpenShift on IBM Cloud fetches cluster details, the APIs for getting clusters and listing clusters are still accessible regardless of the CBR rules. This means clusters are still visible (read-only) in the console and CLI.
[Review the available contexts](https://cloud.ibm.com/docs/openshift?topic=openshift-cbr&interface=clicbr-overview) and determine the rules you want to create.
2. Follow the steps to [create context-based restrictions in the console](https://cloud.ibm.com/docs/account?topic=account-context-restrictions-create).









 Limitations 



* After you create a rule, it might take up to 10 minutes for the rule to take effect.
* Red Hat OpenShift on IBM Cloud CBR rules that apply to all API types or the cluster API types must not reference network zones that contain IPv6 addresses. The APIs included in the cluster type don't support IPv6.
* If you add Red Hat OpenShift on IBM Cloud resources to private-only network zones, the APIs for getting and listing clusters are still accessible over the public network.
* Red Hat OpenShift on IBM Cloud CBR rules that apply to all API types or the cluster API types must not reference other services like IBM Cloud Object Storage or Key Protect
* Red Hat OpenShift on IBM Cloud CBR rules that apply to all API types or the cluster API type do not support Report-only enforcement for the cluster API type.
* Red Hat OpenShift on IBM Cloud CBR rules that apply to all API types or the cluster API types are limited to no more than 20 IPs/subnets for private rules, and 200 IPs/subnets for public rules. These limits are expected to increase after the backend scalability of our implementation of Red Hat OpenShift on IBM Cloud CBR is updated.
* Red Hat OpenShift on IBM Cloud public CBR rules that apply to the cluster API type do not effect clusters that are private service endpoint only. All public traffic to the cluster APIserver is blocked. To use public CBR rules to control access to your cluster, update your cluster to enable public service endpoint.
* Due to a limitation with how Red Hat OpenShift on IBM Cloud fetches cluster details, the APIs for getting clusters and listing clusters are still accessible regardless of the CBR rules. This means clusters are still visible (read-only) in the console and CLI.