vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Encryption The secondary disks of your worker nodes are encrypted at rest by default by the [underlying VPC infrastructure provider](https://cloud.ibm.com/docs/vpc?topic=vpc-block-storage-aboutvpc-storage-encryption). However, you can't [bring your own encryption to the underlying virtual server instances](https://cloud.ibm.com/docs/vpc?topic=vpc-creating-instances-byok). 
 Location VPC clusters are available only in [select multizone metro locations](https://cloud.ibm.com/docs/containers?topic=containers-regions-and-zoneszones-vpc). 
 Virtual Private Cloud See [Limitations](https://cloud.ibm.com/docs/vpc?topic=vpc-limitations) and [Quotas](https://cloud.ibm.com/docs/vpc?topic=vpc-quotas). 
 Worker node flavors Only certain flavors are available for worker node [virtual machines](https://cloud.ibm.com/docs/containers?topic=containers-planning_worker_nodesvm). Bare metal machines are not supported. 
 Worker node host access For security, you can't SSH into the worker node compute host. 
 Worker node updates You can't update or reload VPC worker nodes. Instead, you can delete the worker node and rebalance the worker pool with the ibmcloud ks worker replace command. If you replace multiple worker nodes at the same time, they are deleted and replaced concurrently, not one by one. Make sure that you have enough capacity in your cluster to reschedule your workloads before you replace worker nodes. 







 Networking 

Keep in mind that the [service](https://cloud.ibm.com/docs/containers?topic=containers-limitationstech_limits) limitations also apply.



VPC cluster networking limitations

 Category Description
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.



* [Attach](https://cloud.ibm.com/docs/openshift?topic=openshift-utilitiesvpc_cli_attach) an additional 3 GB disk to at least 3 worker nodes in your cluster and find the device path. To find the device path after you attach the disk, log in to your worker node with oc debug <node> and run lsblk to list the devices on that node.
* Select a device on a worker node where you want Portworx to create the journal.



3. If you want to use a specific device for the internal Portworx KVDB, choose from the following options.



* Attach an additional disk to at least 3 worker nodes use for the KVDB. [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 to use for the KVDB 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.



4. 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).
* [Change log for worker node fix pack 1.25.9_1543, released 24 April 2023](https://cloud.ibm.com/docs/containers?topic=containers-changelog_1251259_1543)
* [Change log for worker node fix pack 1.25.8_1541, released 11 April 2023](https://cloud.ibm.com/docs/containers?topic=containers-changelog_1251258_1541)
* [Change log for worker node fix pack 1.25.8_1539, released 29 March 2023](https://cloud.ibm.com/docs/containers?topic=containers-changelog_1251258_1539)
* [Change log for master fix pack 1.25.8_1536, released 28 March 2023](https://cloud.ibm.com/docs/containers?topic=containers-changelog_1251258_1536)
* [Change log for worker node fix pack 1.25.8_1537, released 27 March 2023](https://cloud.ibm.com/docs/containers?topic=containers-changelog_1251258_1537)
* [Change log for worker node fix pack 1.25.6_1535, released 13 March 2023](https://cloud.ibm.com/docs/containers?topic=containers-changelog_1251256_1535)
* [Change log for master fix pack 1.25.6_1534, released 2 March 2023](https://cloud.ibm.com/docs/containers?topic=containers-changelog_1251256_1534)
* [Change log for worker node fix pack 1.25.6_1532, released 27 February 2023](https://cloud.ibm.com/docs/containers?topic=containers-changelog_1251256_1532)
* [Change log for worker node fix pack 1.25.6_1531, released 13 February 2023](https://cloud.ibm.com/docs/containers?topic=containers-changelog_1251256_1531)
(https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-power-iaas-faqssnap-storage-req)
* [Does the snapshot and volume clone supports any safeguard policy?](https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-power-iaas-faqssnap-clone-safeguard)
* [Can you tell me more about the backup process using the PowerHA Toolkit for IBM i?](https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-power-iaas-faqspoweha-toolkit)
Razee [Razee](https://razee.io/) is an open-source project that automates and manages the deployment of Kubernetes resources across clusters, environments, and cloud providers, and helps you to visualize deployment information for your resources so that you can monitor the rollout process and find deployment issues more quickly. For more information about Razee and how to set up Razee in your cluster to automate your deployment process, see the [Razee documentation](https://github.com/razee-io/Razee). 
 IBM Cloud Monitoring Gain operational visibility into the performance and health of your apps by deploying a Monitoring agent to your worker nodes to forward metrics to IBM Cloud® Monitoring. For more information, see the following docs.<br><br><br><br> * [Setting up IBM Cloud Monitoring in a Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-health-monitor).<br> * [Tutorial: Analyzing metrics for an app that is deployed in a Kubernetes cluster](https://cloud.ibm.com/docs/monitoring?topic=monitoring-kubernetes_clusterkubernetes_cluster).<br><br><br> 
 IBM Blockchain Platform v2 Deploy and manage your own IBM Blockchain Platform on Red Hat OpenShift on IBM Cloud. With IBM Blockchain Platform v2, you can host IBM Blockchain networks or create organizations that can join other IBM Blockchain v2 networks. For more information about how to set up IBM Blockchain in Red Hat OpenShift on IBM Cloud, see [About IBM Blockchain Platform](https://cloud.ibm.com/docs/blockchain?topic=blockchain-get-started-ibp). 
 Other third-party integrations You can install many other integrations into your Red Hat OpenShift cluster, such as through the Red Hat OpenShift catalog, the [Red Hat Marketplace](https://marketplace.redhat.com/en-us/documentation/getting-started), Operators, Helm charts, or do-it-yourself open source software installations.
Also, note that after resizing a worker pool to 2, you can't later resize back down to 1 worker node.
* Which Red Hat OpenShift versions does the service support?

Red Hat OpenShift on IBM Cloud concurrently supports multiple versions of Red Hat OpenShift. When a new version (n) is released, versions up to 2 behind (n-2) are supported. Versions more than 2 behind the latest (n-3) are first deprecated and then unsupported.

For more information about supported versions and update actions that you must take to move from one version to another, see [Red Hat OpenShift on IBM Cloud version information](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_versions).
* Which worker node operating systems does the service support?

For a list of supported worker node operated systems by cluster version, see [Red Hat OpenShift on IBM Cloud version information](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_versions).
* Where is the service available?

Red Hat OpenShift on IBM Cloud is available worldwide. You can create clusters in every supported Red Hat OpenShift on IBM Cloud region.

For more information about supported regions, see [Locations](https://cloud.ibm.com/docs/openshift?topic=openshift-regions-and-zonesregions-and-zones).
* Is the service highly available?

Yes. By default, Red Hat OpenShift on IBM Cloud sets up many components such as the cluster master with replicas, anti-affinity, and other options to increase the high availability (HA) of the service. You can increase the redundancy and failure toleration of your cluster worker nodes, storage, networking, and workloads by configuring them in a highly available architecture. For an overview of the default setup and your options to increase HA, see [High availability for Red Hat OpenShift on IBM Cloud](https://cloud.ibm.com/docs/openshift?topic=openshift-ha).
Attempts to access the cluster control plane, which can be restricted by using the Cluster API type, do not generate Activity Tracker or audit log events.



 How Red Hat OpenShift on IBM Cloud integrates with context-based restrictions 

You can create context-based restrictions (CBR) for Red Hat OpenShift on IBM Cloud resources or for specific APIs. With Context-based restrictions, you can protect the following resources.

Protect Red Hat OpenShift on IBM Cloud resources
: [Restrict access to clusters, resource groups, or regions](https://cloud.ibm.com/docs/openshift?topic=openshift-cbrresources-types-cbr).

Protect specific APIs
: Restrict accessing to provisioning and managing clusters and workers. Or, restrict access to Kubernetes APIs such as viewing pods and nodes. For more information, see [Protecting specific APIs](https://cloud.ibm.com/docs/openshift?topic=openshift-cbrprotect-api-types-cbr).

Applications running on Red Hat OpenShift on IBM Cloud clusters, for example web servers exposed by a Kubernetes LoadBalancer are not restricted by CBR rules.



 Protecting Red Hat OpenShift on IBM Cloud resources 

You can create CBR rules to protect specific regions, and clusters.

Cluster
: Protects a specific Red Hat OpenShift on IBM Cloud cluster. If you select a cluster in your CBR rule, only traffic from resources in the network zones that you associate with the rule can interact with that cluster.
: If you use the CLI, you can specify the --service-instance CLUSTER-ID option to protect a specific cluster.
: If you use the API, you can specify "name": "serviceInstance","value": "CLUSTER-ID" in the resource attributes.

Region
: Protects Red Hat OpenShift on IBM Cloud resources in a specific region. If you select a region in your CBR rule, then only traffic from resources in the network zones that you associate with the rule can interact with resources in that region.
Attempts to access the cluster control plane, which can be restricted by using the Cluster API type, do not generate Activity Tracker or audit log events.



 How Red Hat OpenShift on IBM Cloud integrates with context-based restrictions 

You can create context-based restrictions (CBR) for Red Hat OpenShift on IBM Cloud resources or for specific APIs. With Context-based restrictions, you can protect the following resources.

Protect Red Hat OpenShift on IBM Cloud resources
: [Restrict access to clusters, resource groups, or regions](https://cloud.ibm.com/docs/openshift?topic=openshift-cbr&interface=uiresources-types-cbr).

Protect specific APIs
: Restrict accessing to provisioning and managing clusters and workers. Or, restrict access to Kubernetes APIs such as viewing pods and nodes. For more information, see [Protecting specific APIs](https://cloud.ibm.com/docs/openshift?topic=openshift-cbr&interface=uiprotect-api-types-cbr).

Applications running on Red Hat OpenShift on IBM Cloud clusters, for example web servers exposed by a Kubernetes LoadBalancer are not restricted by CBR rules.



 Protecting Red Hat OpenShift on IBM Cloud resources 

You can create CBR rules to protect specific regions, and clusters.

Cluster
: Protects a specific Red Hat OpenShift on IBM Cloud cluster. If you select a cluster in your CBR rule, only traffic from resources in the network zones that you associate with the rule can interact with that cluster.
: If you use the CLI, you can specify the --service-instance CLUSTER-ID option to protect a specific cluster.
: If you use the API, you can specify "name": "serviceInstance","value": "CLUSTER-ID" in the resource attributes.

Region
: Protects Red Hat OpenShift on IBM Cloud resources in a specific region. If you select a region in your CBR rule, then only traffic from resources in the network zones that you associate with the rule can interact with resources in that region.
Attempts to access the cluster control plane, which can be restricted by using the Cluster API type, do not generate Activity Tracker or audit log events.



 How Red Hat OpenShift on IBM Cloud integrates with context-based restrictions 

You can create context-based restrictions (CBR) for Red Hat OpenShift on IBM Cloud resources or for specific APIs. With Context-based restrictions, you can protect the following resources.

Protect Red Hat OpenShift on IBM Cloud resources
: [Restrict access to clusters, resource groups, or regions](https://cloud.ibm.com/docs/openshift?topic=openshift-cbr&interface=cliresources-types-cbr).

Protect specific APIs
: Restrict accessing to provisioning and managing clusters and workers. Or, restrict access to Kubernetes APIs such as viewing pods and nodes. For more information, see [Protecting specific APIs](https://cloud.ibm.com/docs/openshift?topic=openshift-cbr&interface=cliprotect-api-types-cbr).

Applications running on Red Hat OpenShift on IBM Cloud clusters, for example web servers exposed by a Kubernetes LoadBalancer are not restricted by CBR rules.



 Protecting Red Hat OpenShift on IBM Cloud resources 

You can create CBR rules to protect specific regions, and clusters.

Cluster
: Protects a specific Red Hat OpenShift on IBM Cloud cluster. If you select a cluster in your CBR rule, only traffic from resources in the network zones that you associate with the rule can interact with that cluster.
: If you use the CLI, you can specify the --service-instance CLUSTER-ID option to protect a specific cluster.
: If you use the API, you can specify "name": "serviceInstance","value": "CLUSTER-ID" in the resource attributes.

Region
: Protects Red Hat OpenShift on IBM Cloud resources in a specific region. If you select a region in your CBR rule, then only traffic from resources in the network zones that you associate with the rule can interact with resources in that region.
You can also set up the Red Hat OpenShift Service Mesh, but you must [apply a network policy](https://gist.githubusercontent.com/kitch/39c504a2ed9e381c2aadea436d5b52e4/raw/d8efa69f41d41425b16bb363a881a98d40d3708c/mesh-policy.yaml) for the service mesh ingress to work. 
 API and CLI tools OpenShift Container Platform clusters are set up with access to Kubernetes and Red Hat OpenShift API resources. You can also install command line tools such as oc and odo. Red Hat OpenShift on IBM Cloud clusters come with the same capabilities to use the Kubernetes and Red Hat OpenShift API and CLI tools. Additionally, you can use the IBM Cloud [API](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_api_install) and [CLI](https://cloud.ibm.com/docs/openshift?topic=openshift-cli-install) tools to manage your cluster infrastructure and integrate other cloud services with your cluster.
[IBM Cloud for Financial Services reference architecture with operational monitoring](https://cloud.ibm.com/docs-content/v1/content/9ac5c38b41e0aa1cb4ccc6cc7f547751ec805221/framework-financial-services/vpc/images/logmon/roks-single-region-log-mon.svg)

Figure 1. Single-region IBM Cloud for Financial Services reference architecture with operational monitoring

When you configure Red Hat OpenShift on IBM Cloud for both operational logging and operational monitoring, the worker nodes can be shared. You can use the same worker pool for both logging and monitoring. You can use the same taint tag to steer monitoring and logging pods to the shared worker pool.

Red Hat OpenShift on IBM Cloud provides a built-in monitoring stack. This stack is used to set up monitoring and default alerting. For more information, see [Understanding the monitoring stack](https://docs.openshift.com/container-platform/4.6/monitoring/understanding-the-monitoring-stack.html)

To implement your operational monitoring solution, you need to complete the following high-level steps:



1. Provision an instance of Red Hat OpenShift on IBM Cloud.
2. Configure the worker pool in your Red Hat OpenShift on IBM Cloud cluster.
3. Configuring the Red Hat OpenShift on IBM Cloud monitoring stack.
4. Configure monitoring for a user-defined Red Hat OpenShift on IBM Cloud project.
5. Configure monitoring for a VPC virtual server instance.
6. Set up a custom Grafana dashboard.







 Before you begin 



* You have a [VPC](https://cloud.ibm.com/docs/vpc?topic=vpc-getting-started) provisioned.
* Subnets are provisioned across 3 zones within a region.







 Step 1: Provision Red Hat® OpenShift® on IBM Cloud®
: Custom Satellite Link Administrator and Satellite Link Source Access Controller service access roles

What you can scope an access policy for the resource to
: Account
: Resource group
: Particular instances of the resource

Description
: [Link endpoints](https://cloud.ibm.com/docs/satellite?topic=satellite-link-location-cloud) connect services, servers, or apps that run in your Satellite location with an endpoint that runs in IBM Cloud. Access to a Satellite Link does not give a user access to the resources that the endpoint connects, such as a location or service instance. Instead, the access is to manage the endpoint itself.





 Other services 

Review details about other Satellite-enabled IBM Cloud service IAM resource types, such as Red Hat OpenShift on IBM Cloud clusters and other Satellite-enabled IBM Cloud services.

Resource type, IAM role, and scope of access policies
: Varies by service. For example, Red Hat OpenShift on IBM Cloud is the Kubernetes Service in IAM and can scope access to cluster or namespace resources. For more information, consult the service documentation.

Red Hat OpenShift on IBM Cloud clusters
: You do not assign access policies for Red Hat OpenShift clusters in Satellite. Instead, access to clusters is assigned in IBM Cloud IAM through Red Hat OpenShift on IBM Cloud (Kubernetes Service in the console or containers-kubernetes in the API or CLI). For more information, see [Platform and service roles for Red Hat OpenShift clusters](https://cloud.ibm.com/docs/satellite?topic=satellite-iamiam-roles-clusters).
: If you have access to a Satellite location or configuration, you can view the clusters that are attached to the location or configuration. However, you might not be able to access the clusters if you do not have the appropriate roles to those clusters. For example, if you have the appropriate access to a Satellite configuration, you might be able to list all the Kubernetes resources that run in registered clusters through the Satellite Config API.
Release notes for VPC+ Cloud Migration 

Use these release notes to learn about the latest updates to VPC+ Cloud Migration that are grouped by date.



 November 2022 

Multizone region (MZR) - IBM Cloud Kubernetes Service and Red Hat OpenShift migration (GA)
: The ability to discover and migrate your IBM Cloud Kubernetes Service or Red Hat OpenShift clusters from multiple data centers to a multizone region (MZR) in VPC is now generally available.





 September 2022 

Placement groups
: You can now migrate placement groups with attached virtual server instances to IBM Cloud VPC by using the VPC+ tool.

Single availability zone (SAZ) - IBM Cloud Kubernetes Service and Red Hat OpenShift migration (GA)
: The ability to migrate your IBM Cloud Kubernetes Service and Red Hat OpenShift clusters from a single data center to a single availability zone in VPC is now generally available. For more information, see [Migrating classic IBM Cloud Kubernetes Service or Red Hat OpenShift to VPC](https://cloud.ibm.com/docs/wanclouds-vpc-plus?topic=wanclouds-vpc-plus-migrate-classic-kubernetes-red-hat-openshift-cluster).

Support for multiple IBM Cloud Kubernetes Service or Red Hat OpenShift cluster migrations
: You can now migrate multiple IBM Cloud Kubernetes Service or Red Hat OpenShift clusters at the same time with the VPC+ tool.





 June 2022 

Multizone region (MZR) - IBM Cloud Kubernetes Service and Red Hat OpenShift migration (Experimental)
: Experimental users can now discover and migrate their IBM Cloud Kubernetes Service or Red Hat OpenShift clusters from multiple data centers to a multizone region (MZR) in VPC. This is an experimental feature that is available for evaluation and testing purposes and might change without notice. There are no warranties, SLAs, or support provided, and experimental features are not intended for production use.
Setting pod priority 

With pod priority and preemption, you can configure priority classes to indicate the relative priority of the pods that make up your Red Hat OpenShift cluster's workload. The Red Hat OpenShift controller takes into consideration the priority of a pod and can even preempt (remove) pods with lower priority to make room on a worker node for higher priority pods. For more information, see the [Red Hat OpenShift documentation](https://docs.openshift.com/container-platform/4.11/nodes/pods/nodes-pods-priority.html).

Why do I set pod priority?
: As a cluster administrator, you want to control which pods are more critical to your cluster workload. Priority classes can help you control the Red Hat OpenShift controller decisions to favor higher priority pods over lower priority pods. The Red Hat OpenShift controller can even preempt (remove) lower priority pods that are running so that pending higher priority pods can be scheduled.

By setting pod priority, you can help prevent lower priority workloads from impacting critical workloads in your cluster, especially in cases where the cluster starts to reach its resource capacity.

Make sure that you have [set up proper user access](https://cloud.ibm.com/docs/openshift?topic=openshift-usersusers) to your cluster, and if applicable, [security context constraints (SCCs)](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_sccoc_sccs). Access policies and SCCs can help prevent untrusted users from deploying high priority pods that prevent other pods from scheduling.

How does priority scheduling and preemption work?

In general, pending pods that have a higher priority are scheduled before lower prioritized pods. If you don't have enough resources remaining in your worker nodes, the Red Hat OpenShift controller can preempt (remove) pods to free up enough resources for the higher prioritized pods to be scheduled. Preemption is also affected by graceful termination periods, pod disruption budgets, and worker node affinity.