vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Detached volumes are still authorized to be accessed by a specific worker node and are attached again when you create a new PV with the IBM Cloud Block Volume Attacher storage class to attach a different volume to the same worker node. To avoid attaching the old detached volume again, unauthorize the worker node to access the detached volume by using the ibmcloud sl block access-revoke command. Detaching the volume does not remove the volume from your IBM Cloud infrastructure account. To cancel the billing for your volume, you must manually [remove the storage from your IBM Cloud infrastructure account](https://cloud.ibm.com/docs/openshift?topic=openshift-block_storagecleanup_block).





 VPC: Adding raw Block Storage for VPC to VPC worker nodes by using the API 

You can use the Kubernetes Service API to attach and detach raw, unformatted [Block Storage for Classic](https://containers.cloud.ibm.com/global/swagger-global-api//storage/GetClassicVolume) to a worker node in your VPC cluster.

You can attach a volume to one worker node only. Make sure that the volume is in the same zone as the worker node for the attachment to succeed.

You can also attach, detach, and list the volume attachments of your worker nodes by using the CLI. For more information, see the [storage CLI reference](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_storage).

The instructions in this topic are available for VPC worker nodes only. If you want to attach raw, unformatted block storage to a classic worker node, you must install the [IBM Cloud Block Storage attacher plug-in](https://cloud.ibm.com/docs/openshift?topic=openshift-utilitiesblock_storage_attacher).

Before you begin:

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



1.
: Enter the number of replicas for your data that you want to store across different worker nodes. Allowed numbers are 1,2, or 3. For example, if you enter 3, then your data is replicated across three different worker nodes in your Portworx cluster. To store your data highly available, use a multizone cluster and replicate your data across three worker nodes in different zones. You must have enough worker nodes to fulfill your replication requirement. For example, if you have two worker nodes, but you specify three replicas, then the creation of the PVC with this storage class fails.

parameters.secure
: Specify whether you want to encrypt the data in your volume with IBM Key Protect. Choose between the following options.



* true: Enter true to enable encryption for your Portworx volumes. To encrypt volumes, you must have an IBM Key Protect service instance and a Kubernetes secret that holds your customer root key. For more information about how to set up encryption for Portworx volumes, see [Encrypting your Portworx volumes](https://cloud.ibm.com/docs/containers?topic=containers-storage_portworx_encryption).
* false: When you enter false, your Portworx volumes are not encrypted. If you don't specify this option, your Portworx volumes are not encrypted by default. You can choose to enable volume encryption in your PVC, even if you disabled encryption in your storage class. The setting that you make in the PVC take precedence over the settings in the storage class.



parameters.priority_io
: Enter the Portworx I/O priority that you want to request for your data. Available options are high, medium, and low. During the setup of your Portworx cluster, every disk is inspected to determine the performance profile of the device. The profile classification depends on the network bandwidth of your worker node and the type of storage device. Disks of SDS worker nodes are classified as high. If you manually attach disks to a virtual worker node, then these disks are classified as low due to the slower network speed that comes with virtual worker nodes.
parameters.priority_io
: Enter the Portworx I/O priority that you want to request for your data. Available options are high, medium, and low. During the setup of your Portworx cluster, every disk is inspected to determine the performance profile of the device. The profile classification depends on the network bandwidth of your worker node and the type of storage device. Disks of SDS worker nodes are classified as high. If you manually attach disks to a virtual worker node, then these disks are classified as low due to the slower network speed that comes with virtual worker nodes.
: When you create a PVC with a storage class, the number of replicas that you specify in parameters/repl overrides the I/O priority. For example, when you specify three replicas that you want to store on high-speed disks, but you have only one worker node with a high-speed disk in your cluster, then your PVC creation still succeeds. Your data is replicated across both high and low speed disks.

parameters.shared
: Define whether you want to allow multiple pods to access the same volume. Choose between the following options:



* True: If you set this option to true, then you can access the same volume by multiple pods that are distributed across worker nodes in different zones.
* False: If you set this option to false, you can access the volume from multiple pods only if the pods are deployed onto the worker node that attaches the physical disk that backs the volume. If your pod is deployed onto a different worker node, the pod can't access the volume.



2. Create the storage class.

oc apply -f storageclass.yaml
3. Verify that the storage class is created.

oc get storageclasses



3. Create a persistent volume claim (PVC).



1. Create a configuration file for your PVC.

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: mypvc
spec:
accessModes:
- <access_mode>
resources:
requests:
storage: <size>
storageClassName: portworx-shared-sc
Detached volumes are still authorized to be accessed by a specific worker node and are attached again when you create a new PV with the IBM Cloud Block Volume Attacher storage class to attach a different volume to the same worker node. To avoid attaching the old detached volume again, unauthorize the worker node to access the detached volume by using the ibmcloud sl block access-revoke command. Detaching the volume does not remove the volume from your IBM Cloud infrastructure account. To cancel the billing for your volume, you must manually [remove the storage from your IBM Cloud infrastructure account](https://cloud.ibm.com/docs/containers?topic=containers-block_storagecleanup_block).





 VPC: Adding raw Block Storage for VPC to VPC worker nodes by using the API 

You can use the Kubernetes Service API to attach and detach raw, unformatted [Block Storage for Classic](https://containers.cloud.ibm.com/global/swagger-global-api//storage/GetClassicVolume) to a worker node in your VPC cluster.

You can attach a volume to one worker node only. Make sure that the volume is in the same zone as the worker node for the attachment to succeed.

You can also attach, detach, and list the volume attachments of your worker nodes by using the CLI. For more information, see the [storage CLI reference](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_storage).

The instructions in this topic are available for VPC worker nodes only. If you want to attach raw, unformatted block storage to a classic worker node, you must install the [IBM Cloud Block Storage attacher plug-in](https://cloud.ibm.com/docs/containers?topic=containers-utilitiesblock_storage_attacher).

Before you begin:

[Log in to your account. If applicable, target the appropriate resource group. Set the context for your cluster.](https://cloud.ibm.com/docs/containers?topic=containers-access_cluster)



1.
* Make sure that you are assigned a [service access role](https://cloud.ibm.com/docs/openshift?topic=openshift-userschecking-perms) that grants the appropriate Kubernetes RBAC role so that you can work with Kubernetes resources in the Red Hat OpenShift project.
* Optional: [Set a label for the worker pool](https://cloud.ibm.com/docs/openshift?topic=openshift-add_workersworker_pool_labels) that you want to run the app on.



To deploy apps to specific worker nodes,



1. Get the ID of the worker pool that you want to deploy app pods to.

ibmcloud oc worker-pool ls --cluster <cluster_name_or_ID>
2. List the worker nodes that are in the worker pool, and note one of the Private IP addresses.

ibmcloud oc worker ls --cluster <cluster_name_or_ID> --worker-pool <worker_pool_name_or_ID>
3. Describe the worker node. In the Labels output, note the worker pool ID label, ibm-cloud.kubernetes.io/worker-pool-id.

The steps in this topic use a worker pool ID to deploy app pods only to worker nodes within that worker pool. To deploy app pods to specific worker nodes by using a different label, note this label instead. For example, to deploy app pods only to worker nodes on a specific private VLAN, use the privateVLAN= label.

oc describe node <worker_node_private_IP>

Example output

NAME: 10.xxx.xx.xxx
Roles: <none>
Labels: arch=amd64
beta.kubernetes.io/arch=amd64
beta.kubernetes.io/instance-type=b3c.4x16.encrypted
beta.kubernetes.io/os=linux
failure-domain.beta.kubernetes.io/region=us-south
Preparing Satellite clusters for autoscaling 

Before you can use the cluster autoscaler add-on in your Satellite cluster, complete the following steps.

Autoscaling on Satellite clusters is available in Beta for allowlisted accounts only. You can get added to the allowlist by [opening a case](https://cloud.ibm.com/unifiedsupport/cases/form) with support.

Enabling the autoscaler on an non-allowlisted account results in an The 'cluster-autoscaler' add-on is not supported on satellite clusters error. You can get added to the allowlist by [opening a case](https://cloud.ibm.com/unifiedsupport/cases/form) with support.



 Understanding autoscaling in Satellite clusters 

How does scale-up work for Satellite clusters?
: The cluster autoscaler periodically checks for pods that are stuck in pending state due to lack of memory or CPU resources.



1. The autoscaler checks whether scaling is enabled on any of the work pools in the cluster, if scaling is enabled, then the autoscaler calculates the required number to worker nodes to accommodate all the pods that are stuck in pending state. If no worker pools have autoscaling enabled, then no action occurs.
2. The autoscaler compares required worker node count, which was calculated in the previous step, and compares it to the MaxSize or total amount worker nodes allowed for scaling. If the MaxSize allowed is less than or equal to the required worker node count to satisfy all pods, the autoscaler sends a resize request to the instance group.
3. The autoscaler fetches the hosts that are Ready or Unassigned in the location and that have host labels that match the labels on the worker nodes in the worker pool where autoscaling is enabled.
4. The autoscaler determines if there are enough available Ready or Unassigned hosts to satisfy the resize request.



* If there are not enough hosts available in the location, then a warning is added to the logs that the resize operation was incomplete.
* If there are available hosts that are Ready or Unassigned and have the matching host labels, the autoscaler uses those hosts to fulfill the request.
* If you set externalTrafficPolicy: Cluster in your load balancer configuration:



Versions 1.25 and later

The VPC load balancer routes to the first 8 worker nodes that are discovered in each zone. For a single-zone cluster, the load balancer routes to 8 worker nodes total. The kube-proxy configures IP tables to route the incoming traffic from the worker node to the application pod on whichever node the application pod resides on.
Versions 1.24 and earlier

The VPC load balancer only routes to the first 50 worker nodes that are returned in the cluster's API call to the VPC load balancer. The kube-proxy configures IP tables to route the incoming traffic from the worker node to the application pod on whichever node the application pod resides on.



* If you set externalTrafficPolicy: Local in your load balancer configuration, the VPC load balancer is created only if there are 50 or fewer worker nodes on the cluster. This limit is set by VPC quota limitations of 50 pool members per VPC load balancer pool. To avoid this limitation, use the service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector annotation to limit which worker nodes are in the load balancer pool. For instance, you can use this annotation to force incoming traffic to a specific worker pool. If you use this annotation to force traffic to a specific worker pool, you must also ensure that the application pod also runs in the same worker pool.



* When you define the configuration YAML file for a Kubernetes LoadBalancer service, the following annotations and settings are not supported:



* service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan: "<vlan_id>"
* service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "ipvs"
* service.kubernetes.io/ibm-load-balancer-cloud-provider-ipvs-scheduler: "<algorithm>"
* spec.loadBalancerIP
* spec.loadBalancerSourceRanges
Continuous Relevancy Training 

Discovery Continuous Relevancy Training can learn from user behavior automatically, significantly reducing the effort required to improve the relevancy ranking of results. It uses interactions from users to learn how to surface the most relevant results. It can learn from interactions like clicks to determine which results are most valuable for users and uncover the most important signals for future queries. Continuous Relevancy Training reranks documents to surface the most relevant information at the top of the results. You can also use it for the following purposes:



* Help improve the relevance of results for support agents, based on the results they click on
* Display more relevant results in a customer chatbot based on the long-tail results selected
* Provide experts with more relevant responses, based on the results they explore



To setup Continuous Relevancy Training:



* Continuous Relevancy Training can only be enabled at the environment level. Queries must use either the /api/v1/environment/{environment_id}/query and /api/v1/environments/{environment_id}/query endpoints to query one or more collections.
* Because Discovery events (clicks) are used to create the training data needed, first integrate event tracking. See [Usage monitoring](https://cloud.ibm.com/docs/discovery?topic=discovery-usage) for details.
* A minimum of 1000 natural language queries with an associated click event are required for Continuous Relevancy Training to start. Events and logs are retained for 30 days across your instance so the 1000 clicks must be collected during that time period.
* Continuous Relevancy Training is available for Advanced plans size Small or larger, and Premium plans. It is not available for Lite plans.
* The number of collections for Continuous Relevancy Training is limited to 5. Because Continuous Relevancy Training works across multiple collections, both query and training times might be extended.
* Continuous Relevancy Training only occurs on top-level fields, and there are limits to how many fields can be used in the training process. In cases where there are more than 10 top level fields, training is more likely to encounter errors.



To use Continuous Relevancy Training:
* If you want the cluster to have a public IP, [add new worker nodes](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_worker_add) with both public and private VLANs.





 Hard reboot 

Message:

The worker did not respond to the soft reboot request. A hard reboot might be necessary.

Description and resolution:

Although you issued a reboot on your worker node, the worker node is unresponsive. You can rerun the [reboot command](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_worker_reboot) with the --hard option to power off the worker node, or run the worker reload[command](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_worker_reload).





 Instance can't be found 

Message:

can't create IMS portal token, as no IMS account is linked to the selected BSS account

Provided user not found or active

User account is currently cancel_pending.

The worker node instance '<ID>' can't be found. Review '<provider>' infrastructure user permissions.

The worker node instance can't be found. Review '<provider>' infrastructure user permissions.

The worker node instance can't be identified. Review '<provider>' infrastructure user permissions.

Description and resolution:

The owner of the API key that is used to access the IBM Cloud infrastructure portfolio does not have the required permissions to perform the action, or might be pending deletion.

As the user, follow these steps:



1. If you have access to multiple accounts, make sure that you are logged in to the account where you want to work with IBM Cloud Kubernetes Service.
2. Run ibmcloud ks api-key info --cluster <cluster_name_or_ID> to view the current API key owner that is used to access the IBM Cloud infrastructure portfolio.
3.
For more information, see [CLI prerequisites](https://cloud.ibm.com/docs/vpc?topic=vpc-set-up-environmentcli-prerequisites-setup).





* IBM Cloud CLI
* The vpc-infrastructure plugin





2. Have an [IBM Cloud VPC created](https://cloud.ibm.com/docs/vpc?topic=vpc-creating-a-vpc-using-cli).







 Gathering information to create a dedicated group by using the CLI 

Ready to create a dedicated host group? Before you can run the ibmcloud is dedicated-host-group-create command, you need to know the zone where you want to create it.

Gather the following required information:



Table 1. Required host group details

 Dedicated group details Options 

 Zone Name of the data center within the region where you want to create the group. 
 Family The profile family that you want to assign to the group, such as Memory, Balanced, or Compute. 
 Class The profile class that you want to assign to the group, such as mx2. 
 Name Unique name for your new group. 



Use the following commands to determine the required information for creating a new group.



1. List the regions that are associated with your account.

ibmcloud is regions

For this example, you'd see a response similar to the following output:

Name Endpoint Status
us-south /v1/regions/us-south available
2. List the zones that are associated with the region.

ibmcloud is zones us-south

For this example, you'd see a response similar to the following output:

Name Region Status
us-south-1 us-south available
3. List the profiles that are available for creating a dedicated host to determine what profile family and class you want to assign to the dedicated host group. The family and class that you assign to the group when it is created determines the profiles that can be used to provision dedicated hosts and instances in the group. All dedicated hosts and virtual server instances that are provisioned to the dedicated host group must be from the same family and class of profiles.
This will create additional disk of required size and will convert all eligible volumes to LVM on the target.’ In case of Windows no action is required. It will be taken care automatically by RMM.



4. After you enter your source and target information, you need to provide your IBM Cloud VPC information.
5. From the edit option in Actions menu of your source, select the IBM Cloud VPC Options tab, enter the relevent information, and click Modify.
6. Run the replication.



Ensure that your VPC, subnet, and other necessary cloud components are set up before you add a cloud user in RMM.





 Assigning environment to wave 



1. In the RackWare web console, nagivate to Replication > Waves.
2. Select the wave that needs to be migrated.
3. On the Wave Detail page, select the Autoprovision option as Not configured.
4. Select your cloud user for the Environment, enter the region where the virtual server instance needs to be provisioned, and apply the changes.











 Step 5: Prepare source and target servers 

There are a few things that need to be done on the source and target server for the migration to work. The RackWare RMM server needs to SSH into the servers; thus, the RMM public SSH keys need to be copied onto both the source and target servers. In addition, if the source server has both public and private interfaces, host routes need to be added to ensure the communication between the source and target servers occurs over the transit gateway path. Complete the following steps to prepare your relevant servers.



 Linux systems 



1. Copy the RMM SSH public key to both the source and target servers.
2. If your compute resource has both public and private IP addresses, the host level route needs to be added for it to work properly. Run the following command on your classic compute resources for the operating system:



ip route add <destination_network> via <Gateway_address> dev <private_ethernet_interface>





 Windows systems 



1. Copy the RMM SSH public key to both the source and target servers.
2. You need to download the SSH key utility.
You set scaling policies that define your desired average utilization for metrics like CPU, memory, and network usage. The policies that you define determine when virtual server instances are added or removed from your instance group.

For Red Hat OpenShift on IBM Cloud, you can use the cluster-autoscaler add-on to scale the worker pools in your cluster automatically to increase or decrease the number of worker nodes in the worker pool based on the sizing needs of your scheduled workloads. The cluster-autoscaler add-on is based on the [Kubernetes Cluster-Autoscaler project](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler). See [Autoscaling clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-ca) for more information.

In addition, it is possible to autoscale your pods. See [Scaling apps](https://cloud.ibm.com/docs/openshift?topic=openshift-update_appapp_scaling) for more information.







 Workloads in multiple regions 

Despite the steps you take to leverage multiple zones in a region and increase resiliency with auto scaling, it is still possible for an entire region to be taken out of service. For example, a natural disaster like a hurricane, tornado, or earthquake could knock out multiple zones in a region.

So, it is also recommended to establish and configure an alternate processing site in at least one geographically separate [multizone region](https://cloud.ibm.com/docs/overview?topic=overview-locations) to ensure the continuation of secure system operation. Then, in addition to spreading your workloads across zones in a region, you can distribute your workloads across regions. However, your consumers must be able to opt out of having their data stored in the alternate region based on their data residency requirements.

The diagram below shows an expansion of the VPC reference architecture to use multiple regions.