vania-janet/multiturn-rag-retrieval-data huggingface dataset:
For more information, see [User access permissions](https://cloud.ibm.com/docs/openshift?topic=openshift-access_reference).
* Viewer platform access role to the resource group of the cluster where you want to create the toolchain.
* Editor platform access role to the Toolchain service (note that this service is separate than Continuous Delivery).



To add a continuous delivery pipeline to your cluster,



1. From the [Red Hat OpenShift clusters console](https://cloud.ibm.com/kubernetes/clusters?platformType=openshift), select the cluster for which you want to set up a continuous delivery pipeline.
2. Select the DevOps tab.
3. Click Create a toolchain.
4. Review the available toolchains. IBM provides pre-defined toolchains that you can use to deploy, test, and monitor Kubernetes-native apps or Helm charts. You can expand each toolchain to find an overview of the tools that are set up for you and to find the scripts in GitHub that are used to configure the toolchain in your cluster. For more information about each toolchain, see [Toolchain templates](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-cd_abouttemplates). If you know what tools you want to use, you can create your own toolchain.
5. Select the toolchain that you want to use and click Create.
6. Follow the directions in the console to configure your toolchain. Make sure to include the name of your cluster in your toolchain name so that you can easily find the toolchain that is associated with your cluster later. For more information, see [Creating toolchains](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-toolchains_getting_started).
7. Select Delivery Pipeline to review the stages of your continuous integration and continuous delivery pipeline.
3. Click the URL(Location) next to grafana
4. Log into Red Hat OpenShift on IBM Cloud and allow the requested permissions to see the Grafana dashboard.



2. Click the Dashboard menu in the left navigation panel, select the Manage tab, then istio and Istio Service Dashboard.
3. Select productpage.bookinfo.svc.cluster.local in the Service drop down.
4. Go to your IBM Cloud Shell tab/window and generate a small load to the app by sending traffic to the Ingress host location you set in the last section.

for i in {1..20}; do sleep 0.5; curl -I $INGRESS_HOST/productpage; done



This Grafana dashboard provides metrics for each workload. Explore the other dashboards provided as well.





 Observe your Service mesh with Kiali 

Kiali is an open-source project that installs as an add-on on top of Istio to visualize your service mesh. Kiali provides deeper insight into how your microservices interact with one another, and provides features such as circuit breakers and request rates for your services.



1. From the Red Hat OpenShift on IBM Cloud web console,



1. On the left pane, Under Networking and then click Routes
2. select istio-system as your project from the top bar
3. Click the URL(Location) next to kiali and if prompted, click Login with OpenShift



2. Click the Graph on the left pane and select the bookinfo and istio-system namespaces from the top bar to see the a visual Versioned app graph of the various services in your Istio mesh.
3. To see the request rates, click Display and choose Traffic Rate.
4. In a different tab/window, visit the BookInfo application URL and refresh the page multiple times to generate some load, or run the load script in the previous section to generate load.
5. Now, check the Kiali Graph to see the requests per second.



Kiali has a number of views to help you visualize your services.
IAM platform access roles 

Red Hat OpenShift on IBM Cloud is configured to use IBM Cloud IAM Identity Service roles. IBM Cloud IAM platform access roles determine the actions that users can perform on IBM Cloud resources such as clusters, worker nodes, and Ingress application load balancers (ALBs). IBM Cloud IAM platform access roles also automatically set basic infrastructure permissions for users. To assign platform access roles, see [Granting users access to your cluster through IBM Cloud IAM](https://cloud.ibm.com/docs/openshift?topic=openshift-userschecking-perms).

See the IAM Policy Management [API reference](https://cloud.ibm.com/apidocs/iam-policy-managementlist-roles) for more information on managing IAM roles with the API.

Do not assign IBM Cloud IAM platform access roles at the same time as a service access role. You must assign platform and service access roles separately.



* Actions requiring no permissions: Any user in your account who runs the CLI command or makes the API call for the action sees the result, even if the user has no assigned permissions.
* Viewer actions: The Viewer platform access role includes the actions that require no permissions, plus the permissions that are shown in the Viewer tab of following table. With the Viewer role, users such as auditors or billing can see cluster details but not modify the infrastructure.
* Editor actions: The Editor platform access role includes the permissions that are granted by Viewer, plus the following. With the Editor role, users such as developers can bind services, work with Ingress resources, and set up log forwarding for their apps but can't modify the infrastructure.
* Operator actions: The Operator platform access role includes the permissions that are granted by Viewer, plus the permissions that are shown in the Operator tab of the following table. With the Operator role, users such as site reliability engineers, DevOps engineers, or cluster administrators can add worker nodes and troubleshoot infrastructure such as by reloading a worker node, but can't create or delete the cluster, change the credentials, or set up cluster-wide features like service endpoints or managed add-ons.
These changes are not compatible with earlier versions. After you update your scripts, you must continue to use version 1.0 of the plug-in within the script or the environment where the script is run. Do not change the IKS_BETA_VERSION environment variable to a different version.

ibmcloud oc script update [--in-place] FILE [FILE ...]

Minimum required permissions
: None

Command options:

--in-place
: Optional: Rewrite the source file with the updated command structure. If this option is not specified, you can see a summary of the changes to the script file in STDOUT.

FILE [FILE ...]
: The file that contains the scripts that you want to update.

To use this command to prepare your automation scripts for the release of version 1.0 of the Red Hat OpenShift on IBM Cloud plug-in:



1. Run the command on a test script without the --in-place option.

ibmcloud oc script update ./mytestscript.sh
2. Review the proposed changes to the script in the difference that is shown in the command line STDOUT. Example output

--- a/script-test-2
+++ b/script-test-2
@@ -1,5 +1,5 @@
-ibmcloud ks logging-config-get --cluster mycluster
-ibmcloud ks logging-config-update --cluster mycluster --id myconfig --logsource application --type ibm --app-containers app1,app2,app3 --app-paths /var/log/path/
-ibmcloud ks logging-config-update --cluster mycluster --id myconfig --logsource application --type ibm --app-paths=/var/log/path/,/var/log/other/path/
-ibmcloud ks clusters -s --locations dal09,dal12 --output json
-ibmcloud ks subnets --locations sao01
Click on the URL under Routes to visit your application. Enter any string for username and password, for instance test:test because the app is running in demonstration mode.



The Node.js app has been deployed to Red Hat OpenShift Container Platform. To recap:



* The "Example Health" Node.js application was deployed directly from GitHub into your cluster.
* The application was examined in the Red Hat OpenShift on IBM Cloud console.
* A Build Configuration was created - a new commit can be both built and deployed by clicking Start Build in the Builds section of the application details.









 Step 3: Logging and monitoring 

In this section, you will explore the out-of-the-box logging and monitoring capabilities that are offered in Red Hat OpenShift on IBM Cloud.



 Simulate Load on the Application 

Create a script to simulate load.



1. Make sure you're connected to the project where you deployed your app.

oc project example-health
2. Retrieve the public route to access your application:

oc get routes

Output looks similar to this, note your value for Host:

NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD
patient-health-frontend patient-health-frontend-example-health.roks07-872b77d77f69503584da5a379a38af9c-0000.eu-de.containers.appdomain.cloud patient-health-frontend 8080-tcp None
3. Define a variable with the host:

HOST=$(oc get routes -o json | jq -r '.items[0].spec.host')
4. Verify access to the application. It outputs patient information:

curl -s -L http://$HOST/info

Output should look like:

$ curl -s -L http://$HOST/info
{: codeblock} The default admin-username is admin and password is the password you set for the admin_password parameter during installation, in the setup_openshift.sh command.







 Integrate Ansible Tower with IBM Cloud Pak for Multicloud Management 

Enable navigation to Red Hat Ansible Tower within the IBM Cloud Pak console.

Complete the following steps on a Linux system. These steps enable navigation to Ansible from the IBM Cloud Pak console:



1. Obtain the menu customization script, automation-navigation-updates.sh. See Before you begin. You must run the script on a Linux operating system.
2. Install and authenticate kubectl. For more information, see [Installing the Kubernetes CLI (kubectl)](https://www.ibm.com/support/knowledgecenter/SSFC4F_2.1.0/kubectl/install_kubectl.html)).
3. Download and configure the JQ tool by using the following commands:

wget -O jq https://github.com/stedolan/jq/releases/download/jq-1.6/jq-linux64

chmod +x ./jq

mv jq /usr/bin

For more information, see [Download jq](https://stedolan.github.io/jq/download/).
4. Copy the automation-navigation-updates.sh script to a directory location. Set the file permissions on the script and run the script to enable navigation to your Ansible instance:

chmod 755 ./automation-navigation-updates.sh

./automation-navigation-updates.sh -a <name>

where <name> is the name that is used for the openshift_project paramater in step 10.
For example, ./setup_openshift.sh -e openshift_project=ansible-tower. In this example, ansible-tower is the name that is used.
5.
Default Red Hat OpenShift components, such as the web console and OperatorHub, require public network access. If you skip this step, you must instead be connected to your VPC private network, such as through a VPN connection, to access the Red Hat OpenShift web console or access your cluster with kubectl commands.

ibmcloud is public-gateway-create gateway-us-south-1 <vpc_ID> us-south-1
3. Create a subnet for your VPC, and note its ID. Consider the following information when you create the VPC subnet:



* Zones: You must have one VPC subnet for each zone in your cluster. The available zones depend on the metro location that you created the VPC in. To list available zones in the region, run ibmcloud is zones.
* IP addresses: VPC subnets provide private IP addresses for your worker nodes and load balancer services in your cluster, so make sure to [create a 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 IP addresses that a VPC subnet has later.
* Public gateways: Include the public gateway that you previously created. You must have one public gateway for each zone in your cluster.

ibmcloud is subnet-create mysubnet1 <vpc_ID> --zone us-south-1 --ipv4-address-count 256 --public-gateway-id <gateway_ID>





3. Create a standard IBM Cloud Object Storage instance to back up the internal registry in your cluster. In the output, note the instance ID.

ibmcloud resource service-instance-create myvpc-cos cloud-object-storage standard global
4. Create a cluster in your VPC in the same zone as the subnet. The following command creates a version 4.11 cluster in Dallas with the minimum configuration of 2 worker nodes that have at least 4 cores and 16 GB memory so that default Red Hat OpenShift components can deploy.
Run the registration script on your machine.

nohup bash /tmp/attach.sh &
11. Monitor the progress of the registration script.

journalctl -f -u ibm-host-attach
12. Exit the SSH session.

exit
13. Check that your hosts are shown in the Hosts tab of your [Satellite console](https://cloud.ibm.com/satellite/locations). All hosts show a Health status of Ready when a connection to the machine can be established, and a Status of Unassigned as the hosts are not yet assigned to your Satellite location control plane or a Red Hat OpenShift on IBM Cloud cluster.
14. Assign your hosts to the [Satellite control plane](https://cloud.ibm.com/docs/satellite?topic=satellite-setup-control-plane) or a [Red Hat OpenShift on IBM Cloud cluster](https://cloud.ibm.com/docs/satellite?topic=satellite-assigning-hostshost-assign-manual).







 Manually adding IBM Cloud RHCOS hosts to Satellite 

You can create your Satellite location with hosts that you added from IBM Cloud.

All hosts that you want to add must meet the general host requirements, such as the RHEL 7 or 8 packages and networking setup. For more information, see [Host requirements](https://cloud.ibm.com/docs/satellite?topic=satellite-host-reqs).

Before you begin, [create a Satellite location](https://cloud.ibm.com/docs/satellite?topic=satellite-locations).



1. Get the registration script to attach hosts to your IBM Cloud Satellite location. Note that the token in the script is an API key, which should be treated and protected as sensitive information. Make a note of the location of the attach script. Also note that for RHCOS hosts, the attach script is a RHCOS ignition file.

ibmcloud sat host attach --location <location_name_or_ID>
2.
Deploying Workload Protection features on a host 

IBM Cloud Monitoring can be configured to integrate Workload Protection features.

For more information about Workload Protection, see the [IBM Cloud® Security and Compliance Center Workload Protection documentation.](https://cloud.ibm.com/docs/workload-protection).



  Step 1. Check the service plan of your Monitoring instance 

If you have the Monitoring service deployed in your account with the Graduated tier service plan, you must upgrade to the Graduated Tier - Sysdig Secure + Monitor plan.

If you provision a Monitoring instance, choose the Graduated Tier - Sysdig Secure + Monitor plan.





  Step 2. Deploy the agent for orchestrated environments by using Helm 

For orchestrated environments, deploy the Monitoring agent by using Helm:



*  [Deploying an agent on a Kubernetes cluster by using helm](https://cloud.ibm.com/docs/monitoring?topic=monitoring-agent-deploy-kube-helm).
*  [Deploying an agent on a Red Hat OpenShift cluster by using helm](https://cloud.ibm.com/docs/monitoring?topic=monitoring-agent-deploy-openshift-helm).



You can only deploy the agent by using Helm if you want to use the Workload Protection features on an orchestarted environment. If you deployed your agent by using the script, you must manually remove the agent and redeploy it by using Helm.
Planning your Ingress setup 

Expose multiple apps in your Red Hat® OpenShift® on IBM Cloud® cluster by creating Ingress resources that are managed by the Ingress controller.

This information is for clusters that run Red Hat OpenShift version 4 only.

For information about how to expose apps in Satellite, see [Exposing apps in Satellite clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-sat-expose-apps).



 Planning networking for single or multiple projects 

One Ingress resource is required per project where you have apps that you want to expose.



 All apps are in one project 

If the apps in your cluster are all in the same project, you must create one Ingress resource to define the routing rules for the apps that you want to expose.

For example, if you have app1 and app2 exposed by services in a development project, you can create an Ingress resource in the project. The resource specifies domain.net as the host and registers the paths that each app listens on with domain.net.

Zoom

![One resource is required per project](https://cloud.ibm.com/docs-content/v1/content/bce0f0917a9eea684d1b4b704ac6343a1f65f446/openshift/images/cs_ingress_single_ns.png)

Figure 1. One resource is required per project

Note that if you want to use different domains for the apps within the same project, you can create one resource per domain.





 Apps are in multiple projects 

If the apps in your cluster are in different projects, you must create one Ingress resource for each project to define the app's routing rules.

You can either define the same domain in multiple resources, or use a wildcard domain to specify different subdomains within the Ingress resource for each project.

When a wildcard domain is registered, multiple subdomains can all resolve to the same host.
Complete your setup by using one of the following options.



* To pull images in Red Hat OpenShift projects other than default or from other IBM Cloud accounts, [copy or create another image pull secret](https://cloud.ibm.com/docs/openshift?topic=openshift-registryother).
* To restrict the image pull secret access to particular registry resources such as namespaces or regions:



1. Make sure that [IBM Cloud IAM policies for IBM Cloud Container Registry are enabled](https://cloud.ibm.com/docs/Registry?topic=Registry-user).
2. [Edit the IBM Cloud IAM policies](https://cloud.ibm.com/docs/account?topic=account-serviceidsupdate_serviceid) for the service ID, or [create another image pull secret](https://cloud.ibm.com/docs/openshift?topic=openshift-registryother_registry_accounts).













 Using an image pull secret to access images in other IBM Cloud accounts or external private registries from non-default Red Hat OpenShift projects 

Set up your own image pull secret in your cluster to deploy containers to Red Hat OpenShift projects other than default, use images that are stored in other IBM Cloud accounts, or use images that are stored in external private registries. Further, you might create your own image pull secret to apply IAM access policies that restrict permissions to specific registry image namespaces, or actions (such as push or pull).

After you create the image pull secret, your containers must use the secret to be authorized to pull an image from the registry. You can add the image pull secret to the service account for the project, or refer to the secret in each deployment. For instructions, see [Using the image pull secret to deploy containers](https://cloud.ibm.com/docs/openshift?topic=openshift-registryuse_imagePullSecret).

Image pull secrets are valid only for the Red Hat OpenShift projects that they were created for. Repeat these steps for every namespace where you want to deploy containers.

Before you begin:



1.
* Logging: You can use Log Analysis to manage operating system logs, application logs, and platform logs. If you want to enable this integration later, see [Logging for clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-health&interface=ui).



: 

* Monitoring: The monitoring service integration allows operational visibility into the performance and health of your applications, services, and platforms. If you disable this integration and want to enable it later, see [Monitoring cluster health](https://cloud.ibm.com/docs/openshift?topic=openshift-health-monitor&interface=ui).







 Creating a standard classic cluster in the CLI 

Create your single zone or multizone classic cluster by using the IBM Cloud CLI.



* Ensure that you complete the prerequisites to [prepare your account](https://cloud.ibm.com/docs/containers?topic=containers-clusters&interface=ui) and decide on your cluster setup. Keep in mind that you need a cluster with a minimum of 2 worker nodes of the 4x16 flavor so that default Red Hat OpenShift components can deploy.
* Install the IBM Cloud CLI and the [Red Hat OpenShift on IBM Cloud plug-in](https://cloud.ibm.com/docs/openshift?topic=openshift-cli-install).





1. Log in to the IBM Cloud CLI. Enter your IBM Cloud credentials when prompted. If you are logging in with a federated ID, use ibmcloud login --sso.

ibmcloud login [--sso]
2. If you have multiple IBM Cloud accounts, select the account where you want to create your cluster.
3. To create clusters in a resource group other than default, target that resource group. A cluster can be created in only one resource group, and after the cluster is created, you can't change its resource group.
If your OpenShift cluster is behind a firewall, see [Deploy from Red Hat Marketplace (airgap installation)](https://cloud.ibm.com/docs/blockchain-sw-254?topic=blockchain-sw-254-deploy-ocp-rhm-fw).
11. Continue to [Step one: Apply the Security Context Constraint](https://cloud.ibm.com/docs/blockchain?topic=blockchain-deploy-ocp-rhmdeploy-ocp-rhm-scc).







 Step one: Apply the Security Context Constraint 

The IBM Blockchain Platform requires specific security and access policies to be added to your project. The ibp-scc.yaml file is provided here for you to copy and edit to define the security policies for your project. Before attempting this step, you should be logged in to the oc CLI.

Copy and save the following security context constraint object to your local system as ibp-scc.yaml. Edit the file and replace <PROJECT_NAME> with the name of your project.

allowHostDirVolumePlugin: false
allowHostIPC: false
allowHostNetwork: false
allowHostPID: false
allowHostPorts: false
allowPrivilegeEscalation: true
allowPrivilegedContainer: true
allowedCapabilities:
- NET_BIND_SERVICE
- CHOWN
- DAC_OVERRIDE
- SETGID
- SETUID
- FOWNER
apiVersion: security.openshift.io/v1
defaultAddCapabilities: []
fsGroup:
type: RunAsAny
groups:
- system:serviceaccounts:<PROJECT_NAME>
kind: SecurityContextConstraints
metadata:
name: <PROJECT_NAME>
readOnlyRootFilesystem: false
requiredDropCapabilities: []
runAsUser:
type: RunAsAny
seLinuxContext:
type: RunAsAny
Log in to the [IBM Cloud® console](https://cloud.ibm.com/) by using your unique credentials.
2. From the dashboard, click Menu icon ![Menu icon](https://cloud.ibm.com/docs-content/v1/content/9de14ae11cc0bda57c240e5b42f2964edeaab3c6/icons/icon_hamburger.svg) > VPC Infrastructure > SSH keys.
3. Click Create.
4. Enter the SSH key name (for example, hpcc-ssh-key), select the resource group, add tags, and select the region.
5. Copy and paste the public key into the Public key field (the contents that you saved from .ssh/id_rsa.pub).
6. Click Add SSH key.







 Step 3: Create API key 

Complete the following steps to create your API key:



1. In the IBM Cloud console, go to Manage > Access (IAM) > API keys.
2. Click Create an IBM Cloud API key.
3. Enter a name and description for your API key.
4. Click Create.
5. Click Show to display the API key, Copy to copy and save it for later, or click Download.







 Step 4: Create and configure a Red Hat OpenShift for HPC cluster from the IBM Cloud Schematics UI 

Complete the following steps to create your Red Hat OpenShift cluster.



 Creating a workspace using the UI 



1. Go the [Schematics, IBM Cloud's deployment manager](https://cloud.ibm.com/schematics/overview).
2. In the navigation menu, select Workspaces, and then select Create workspace.
3. In the Specify template section:



* Provide the Red Hat OpenShift repository URL that is provided by IBM Cloud in this [public GitHub repository](https://github.com/IBM-Cloud/hpc-cluster-openshift).