vania-janet/multiturn-rag-retrieval-data huggingface dataset:
* For new clusters: [Create a cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_cluster_create) with the --entitlement cloud_pak option. When you specify the number of workers (--workers) and flavor (--flavor), make sure to specify only the number and size of worker nodes that you are entitled to use. You can optionally specify the worker node operating system (--operating-system). After your cluster is created, you are not charged the Red Hat OpenShift license fee for the entitled worker nodes in the default worker pool. If you want to use a different worker pool for your Cloud Pak, follow the steps for existing clusters.
* For existing clusters or worker pools other than default: Create a [worker pool](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_worker_pool_create) with the --entitlement cloud_pak option. When you specify the number of workers (--size-per-zone) and flavor (--flavor), make sure to specify only the number and size of worker nodes that you are entitled to use. After creation, your worker pool does not charge you the Red Hat OpenShift license fee for your entitled worker nodes.



Do not exceed your entitlement. Keep in mind that your OpenShift Container Platform entitlements can be used with other cloud providers or in other environments. To avoid billing issues later, make sure that you use only what you are entitled to use. For example, you might have an entitlement for the OCP licenses for two worker nodes of 4 CPU and 16 GB memory, and you create this worker pool with two worker nodes of 4 CPU and 16 GB memory. You used your entire entitlement, and you can't use the same entitlement for other worker pools, cloud providers, or environments.
2. In the [IBM Cloud catalog](https://cloud.ibm.com/catalog?search=label%3Acloud_paksoftware), in the Software tab, under Offering Type, check Cloud Paks.
If it is, you will not be able to delete the node until it has been removed as a consenter from all channels. After removing the node as a consenter from all channels, you will be able to delete the node by clicking the trash can icon. Note that this action will have to be taken in the console where the node was created.

As part of this same process, make sure to reach out to the other console operators to let them know that the node has been deleted so they can remove the tile from their console.

Note: if you remove all of the ordering nodes that originally formed the consenter set of a channel, you might have to create a mapping from the old ordering nodes to the new nodes by editing the configuration of any new peers you attempt to join to the channel. For more information, see [Mapping to existing ordering nodes](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-add-remove-ordereribp-console-add-remove-orderer-mapping).



 Mapping to existing ordering nodes 

When a peer attempts to join a channel, it first pulls the initial configuration block (known as the genesis block) that was created when the channel was created. This block lists, among other things, the addresses of the ordering nodes that are consenters on the channel. As long as one of these nodes is still alive, the peer can pull down the ledger associated with this channel from that node and learn about any new ordering nodes that are now servicing the channel.

If none of the ordering nodes that were consenters on the channel are still up, any peer attempting to join the channel will try and fail to connect to the nodes listed in the genesis block and be unable to proceed past that point.

In these cases, it is necessary to edit the configuration of the peer itself with a code snippet provided by the console. This code snippet will point the peer to one of the ordering nodes servicing the channel and allow the ledger of the channel to be pulled from that node.





 Editing the peer configuration
Snapshots can be taken both on bootable and secondary data volumes. If you experience accidental data deletion, you can create new data volumes from the backup snapshots and selected files can be copied over. If the snapshot was taken on a bootable volume, you can create another virtual server instance from the snapshot.

Snapshots of the volumes reside in regional IBM Cloud Object Storage buckets. To take snapshots, volumes must be attached to active virtual server instances. The first snapshot is a full snapshot and the subsequent snapshots are incremental. Snapshots inherit the encryption keys of the parent volume.





 Using snapshots for 3-Tier applications 

On a 3-tier application, snapshots work as backups, and they are the first line of defense for data protection. While critical applications might need a suite of HA and DR solutions, a non-mission critical and non-production system can rely on backup snapshots.

Snapshots can be used not only for application backups but also to create a copy of the applications either in the same zone or in another zone within a region. The applications can then be configured with a load balancer.

When you create the boot volume from snapshots, for web, MT or DB boot volumes, the instance profile does not have to be the same as the virtual machine profile that created the snapshot. This arrangement helps in use cases where you want to swap out virtual machines with higher capacities when they are under a load balancer. Creating new virtual server instances with snapshots needs only minimal changes to the software. These changes can be done through boot strap scripts.

Data volumes can be restored and attached to any other virtual server instances. This arrangement helps in use cases where user deletes a configuration file or drops a database table. The volume can be restored to another virtual server instance, to a temporary database that is created from the backup snapshot, and the deleted file or dropped table can be restored.

You can also restore the snapshots to a higher capacity and IOPS profiles and not necessarily to the same volume profiles as the source volume.





 Taking manual snapshots of your 3-tier applications 

A bootable snapshot can be taken for the web, app, and db machines.
To apply a taint to individual worker nodes:

oc adm taint node -l dedicated=edge dedicated=edge:NoExecute

Now, only pods with the dedicated=edge toleration are deployed to your edge worker nodes.
2. Verify that your edge nodes are tainted.

oc describe nodes -l dedicated=edge | egrep "Taints|Hostname"

Example output

Taints: dedicated=edge:NoExecute
Hostname: 10.176.48.83
Taints: dedicated=edge:NoExecute
Hostname: 10.184.58.7
3. If you choose to [enable source IP preservation for an NLB 1.0 service](https://cloud.ibm.com/docs/openshift?topic=openshift-loadbalancerlb_source_ip), ensure that app pods are scheduled onto the edge worker nodes by [adding edge node affinity to app pods](https://cloud.ibm.com/docs/openshift?topic=openshift-loadbalancerlb_edge_nodes). App pods must be scheduled onto edge nodes to receive incoming requests.
4. Optional: You can remove a taint from the worker nodes.

To remove all taints from all worker nodes in a worker pool,

ibmcloud oc worker-pool taint rm -c <cluster_name_or_ID> --worker-pool <worker_pool_name_or_ID>

To remove individual taints from individual worker nodes,

oc adm taint node <node_name> dedicated:NoSchedule- dedicated:NoExecute-







 Deploying the Sysdig agent on edge worker nodes 

To allow the Sysdig agent pods to be deployed to your edge worker nodes, run the following kubectl patch command to update the sysdig-agent DaemonSet. This command applies the NoExecute toleration to the DaemonSet to ensure that the agent pods don't get evicted from the node.
After the drives are wiped, the server moves into provisioning for reassignment.





 What happens to a bare metal drive if it malfunctions? 

A drive malfunction prompts manual intervention and the drive is set to end of life. The end of life process initiates when the drive malfunctions or if the age or size is beyond support. When any of these conditions occur, the drive is wiped as mentioned in the previous section. Then, the drive is physically destroyed by breaking, crushing, or shredding. The physical destruction process is tracked by using the serial number on the drive.





 Can I see what bare metal servers are available for purchase? 

Yes! You can now see what servers are available in what data center when you provision a bare metal server. But, this option is available for only the hourly offering. You cannot see server availability with the monthly offering. For more information about provisioning a bare metal server, see [Selecting from fast provisioning servers](https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-bm-select-popular-serversbm-select-popular-servers).





 How do I use IPMI? 

IPMI is a way to manage a server remotely through a network interface. Gather the IPMI address and login information from the IBM Cloud® console under Devices > your server (device details)> Remote Mgmt. Next, establish a VPN connection to the server. You can then connect by pointing your web browser to the IP address or by using a [Standalone VPN client](https://cloud.ibm.com/docs/iaas-vpn?topic=iaas-vpn-standalone-vpn-clients).
Using the IPv6 address for the host, [refresh the RMC services](https://www.ibm.com/support/pages/fixing-no-rmc-connection-error):

/opt/rsct/bin/rmcctrl -p
/opt/rsct/rmcrefreshMD -s ctrmc
4. (Optional) If you altered the node ID (that is unique to RMC), it might have impacted RMC. For example, when you are using PowerHA and trying to copy your nodeid details from an on-premises deployment that is not supported. Begin by rebuilding the node:

odmdelete -o CuAt -q name=cluster0 to remove 'cluster0' entry from the CuAt ODM.
5. (Optional) On the AIX VM, enter the cat /etc/ct_node_id command and save the output.
6. (Optional) To create new nodeid and restart RMC services:

/usr/sbin/rsct/install/bin/recfgct
7. (Optional) To build a nodeid, run the /opt/rsct/bin/rmcctrl -p command if not already done in step 3.



If these recovery steps do not restore the RMC status to active and its health to OK, open a case with [support](https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-getting-help-and-support).







 Recovering from a missing IPv6 link local address when using your own boot image 

Complete the following steps to recover from a missing IPv6 link local address:



1. Before you shut down the AIX VM, grab the IPv6 details.
2. Gather the IP interface and adapter configuration details by using smitty.
3. Run the /usr/sbin/rsct/bin/lsnodeid command to grab the nodeid.
4. Confirm that the nodeid matches the output from cat /etc/ct_node_id and cat /var/ct/cfg/ct_node_id.
5.
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.



Auto-provision feature is not available if target is VPC bare metal. User needs to select Existing System as target type in this case.









 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 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.
During the reload, your worker node machine is updated with the latest image and data is deleted if not [stored outside the worker node](https://cloud.ibm.com/docs/openshift?topic=openshift-storage-plan). The worker node public and private IP address remain the same after the reload operation.

Reloading a worker node applies patch version updates to your worker node, but not major or minor updates. To see the changes from one patch version to the next, review the [Version change log](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_versions) documentation.

Before you reload your worker node, make sure that you have enough capacity in other worker nodes to reschedule the pods on the worker node. Rescheduling pods helps to avoid downtime for your app or data corruption on your worker node.



1. List all worker nodes in your cluster and note the name of the worker node that you want to reload.

oc get nodes

The name that is returned in this command is the private IP address that is assigned to your worker node. You can find more information about your worker node when you run the ibmcloud oc worker ls --cluster <cluster_name_or_ID> command and look for the worker node with the same Private IP address.
2. Reload the worker node. As part of the reload process, the pods that run on the worker node are drained and rescheduled onto remaining worker nodes in the cluster. The worker node is also cordoned, or marked as unavailable for future pod scheduling. Use the worker node ID that is returned from the ibmcloud oc worker ls --cluster <cluster_name_or_ID> command.

ibmcloud oc worker reload --cluster <cluster_name_or_ID> --worker <worker_name_or_ID>
3. Wait for the reload to complete. When your worker node is in a Normal state, the worker node becomes available for pod scheduling again.
Additionally, you can't scale down a worker pool to fewer than 2 worker nodes per zone. For more information, see [What is the smallest size cluster that I can make?](https://cloud.ibm.com/docs/openshift?topic=openshift-faqssmallest_cluster). You can't scale worker pools down to zero. Because of the worker node quota, you are limited in the number of worker pools per cluster and number of worker nodes per worker pool. For example, with the default worker node quota of 500 per region, you might have up to 500 worker pools of 1 worker node each in a region with only 1 cluster. Or, you might have 1 worker pool with up to 500 worker nodes in a region with only 1 cluster. 
 Cluster naming To ensure that the Ingress subdomain and certificate are correctly registered, the first 24 characters of the clusters' names must be different. If you create and delete clusters with the same name or names that have the same first 24 characters 5 times or more within 7 days, such as for automation or testing purposes, you might reach the [Let's Encrypt Duplicate Certificate rate limit](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_rate_limit). 





 Version 4 cluster limitations 

Review limitations that are specific to Red Hat OpenShift version 4 clusters. Keep in mind that the [service](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_limitationstech_limits) and [classic cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_limitationsclassic_limits) or [VPC cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_limitationsks_vpc_gen2_limits) limitations also apply.



OpenShift Container Platform version 4 cluster limitations

 Category Description
Managing data with Spectrum LSF on IBM Cloud 

When you work with HPC workloads in a cloud environment, a critical challenge to address is how best to manage the data that is needed for running the workloads, as well as the output that might need to be analyzed for further processing and decision making. With IBM® Spectrum LSF clusters deployed on IBM Cloud®, you can use the following methods to manage your data.



 Hybrid setup with IBM Cloud 

If your setup is using a VPN or direct link to connect the on-premises Spectrum LSF environment to the Spectrum LSF cluster on IBM Cloud, you can configure the LSF multicluster capability and use the Spectrum LSF Data Manager component to stage the data from on-premises to your Spectrum LSF cluster on IBM Cloud.

With an on-premises cluster, data typically resides on one or more file systems that are mounted onto every compute node. In general, you don't need to consider data location or locality (certain workloads do benefit from being "closer" to the filer and IBM Spectrum LSF does have a number of capabilities that allow you to consider data locality).

In a hybrid setup, where work can run on-premises and in the cloud, how and when data is moved to and from the cloud is important. Unfortunately, there is not a one-size-fits-all solution for this, and your data movement strategy depends on multiple factors:



* Frequency and volume of workload being sent to the cloud - are you sending a handful of jobs or thousands?
* Frequency of change of that data - is the data set static or constantly changing?
* Size of the data - how much needs to be moved?
* Uniqueness of data per job - does every job requires unique data inputs or are most of the jobs reusing or sharing common data?
* Runtime of the workload - if the ratio of compute time to time taken to get the data to the cloud is low, it is probably not cost-effective to run that workload on the cloud



For data requirements that are static or that have small incremental changes, mirroring the data set between on-premises and the cloud can be cost-effective by using solutions such as IBM Aspera.
Apply the policy.

calicoctl apply -f allow-vpn-from-namespace.yaml --config=filepath/calicoctl.cfg
5. Verify that the global network policies are created in your cluster.

calicoctl get GlobalNetworkPolicy -o wide --config=filepath/calicoctl.cfg







 Limiting strongSwan VPN traffic by worker node 

When you have multiple strongSwan VPN deployments in a multi-tenant cluster, you can limit VPN traffic for each deployment to specific worker nodes that are dedicated to each tenant.

When you deploy a strongSwan Helm chart, a strongSwan VPN deployment is created. The strongSwan VPN pods are deployed to any untainted worker nodes. Additionally, a Kubernetes daemon set is created. This daemon set automatically configures routes on all untainted worker nodes in the cluster to each of the remote subnets. The strongSwan VPN pod uses the routes on worker nodes to forward requests to the remote subnet in the on-premises network.

Routes are not configured on tainted nodes unless you specify the taint in the tolerations setting in the value.yaml file. By tainting worker nodes, you can prevent any VPN routes from being configured on those workers. Then, you can specify the taint in the tolerations setting for only the VPN deployment that you do want to permit on the tainted workers. In this way, the strongSwan VPN pods for one tenant's Helm chart deployment only use the routes on that tenant's worker nodes to forward traffic over the VPN connection to the remote subnet.

Before you use this solution, review the following considerations and limitations.



* By default, Kubernetes places app pods onto any untainted worker nodes that are available. To make sure that this solution works correctly, each tenant must first ensure that they deploy their app pods only to workers that are tainted for the correct tenant. Additionally, each tainted worker node must also have a toleration to allow the app pods to be placed on the node.
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 no hosts are available with the matching host labels, the autoscaler filters the Ready or Unassigned hosts for those with only the default host labels. Then, the autoscaler updates the labels on those hosts to match the host labels of the worker pool where scaling is enabled and uses these hosts to fulfill the request.





How does scale-down work in Satellite clusters?
: When the cluster autoscaler determines that a worker node is underutilized for the specified scaleDownUnneededTime time, then the workers are deleted from the cluster. The hosts where that were used for those worker nodes are then in the Reload Required or Unassigned state in the location. These hosts can't be used by any other cluster until they are reloaded and re-attached to the location. Note that all the workers in the worker pool must be the same flavor.

What happens if my location doesn't have available hosts for scale up?
: If there are not enough hosts for scale-up then the workload is not fully deployed. But, After more hosts are added to the location, the scale-up operation is resumed automatically.

How does autoscaling different on Satellite compared to IBM Cloud® Kubernetes Service or Red Hat® OpenShift® on IBM Cloud®?
: IBM Cloud® Kubernetes Service or Red Hat® OpenShift® on IBM Cloud® can automatically provision or remove hosts in the infrastructure as part of scaling. With Satellite, since hosts reside on a variety of different infrastructure, the autoscaler can't provision and remove worker nodes automatically.