vania-janet/multiturn-rag-retrieval-data huggingface dataset:
For more information, see [Deploying OpenShift Data Foundation on VPC clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-deploy-odf-vpc).

Satellite clusters
: If you want to deploy ODF to Satellite clusters, you can use the Satellite storage template. For more information, see the following links.
: [Deploying the OpenShift Data Foundation template for remote, dynamically provisioned disks](https://cloud.ibm.com/docs/satellite?topic=satellite-storage-odf-remote).
: [Deploying the OpenShift Data Foundation template for local disks](https://cloud.ibm.com/docs/satellite?topic=satellite-storage-odf-local).

Classic clusters
: You can deploy ODF by using local disks on your bare metal worker nodes. For more information, see [Deploying OpenShift Data Foundation on Classic clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-deploy-odf-classic).
Make sure that all your clusters have sufficient [raw and unformatted block storage](https://cloud.ibm.com/docs/containers?topic=containers-utilitiesmanual_block) so that you can build your Portworx storage layer.
3. Review your [options to configure a Portworx key-value store](https://cloud.ibm.com/docs/containers?topic=containers-storage_portworx_kv_store). Because both clusters are in different regions, each cluster must use its own key-value store. You can use the internal Portworx KVDB or set up a Databases for etcd instance.
4. Enable Portworx [volume encryption](https://cloud.ibm.com/docs/containers?topic=containers-storage_portworx_encryption) for both of your clusters. The IBM Key Protect credentials are later used by Portworx to encrypt data traffic between the clusters.
5. Follow the instructions to [install Portworx](https://cloud.ibm.com/docs/containers?topic=containers-storage_portworx_deploy) with the disaster recovery plan in both of your clusters. If you installed Portworx without the disaster recovery plan in one of your clusters already, you must re-install Portworx in that cluster with the disaster recovery plan. Make sure that you configure the Portworx key-value store that each cluster uses.
6. Follow the [Portworx documentation](https://docs.portworx.com/portworx-install-with-kubernetes/disaster-recovery/async-dr/) to create a cluster pair, enable disaster recovery mode, and schedule data migrations between your clusters.
Make sure that all your clusters have sufficient [raw and unformatted block storage](https://cloud.ibm.com/docs/openshift?topic=openshift-utilitiesmanual_block) so that you can build your Portworx storage layer.
3. Review your [options to configure a Portworx key-value store](https://cloud.ibm.com/docs/openshift?topic=openshift-storage_portworx_kv_store). Because both clusters are in different regions, each cluster must use its own key-value store. You can use the internal Portworx KVDB or set up a Databases for etcd instance.
4. Enable Portworx [volume encryption](https://cloud.ibm.com/docs/openshift?topic=openshift-storage_portworx_encryption) for both of your clusters. The IBM Key Protect credentials are later used by Portworx to encrypt data traffic between the clusters.
5. Follow the instructions to [install Portworx](https://cloud.ibm.com/docs/openshift?topic=openshift-storage_portworx_deploy) with the disaster recovery plan in both of your clusters. If you installed Portworx without the disaster recovery plan in one of your clusters already, you must re-install Portworx in that cluster with the disaster recovery plan. Make sure that you configure the Portworx key-value store that each cluster uses.
6. Follow the [Portworx documentation](https://docs.portworx.com/portworx-install-with-kubernetes/disaster-recovery/async-dr/) to create a cluster pair, enable disaster recovery mode, and schedule data migrations between your clusters.
(https://cloud.ibm.com/docs/containers?topic=containers-vpc_ts_albvpc_ts_alb)

[Why does no Ingress subdomain exist after cluster creation?](https://cloud.ibm.com/docs/containers?topic=containers-ingress_subdomainingress_subdomain)



* [Classic clusters](https://cloud.ibm.com/docs/containers?topic=containers-ingress_subdomainno-ingress-subdomain-classic)



* [VPC clusters](https://cloud.ibm.com/docs/containers?topic=containers-ingress_subdomainno-ingress-subdomain-vpc)





[Why does no Ingress subdomain exist after I create clusters of the same or similar name?](https://cloud.ibm.com/docs/containers?topic=containers-cs_rate_limitcs_rate_limit)

[Why do ALB pods not deploy to worker nodes?](https://cloud.ibm.com/docs/containers?topic=containers-alb-pod-affinityalb-pod-affinity)

[Classic clusters: Why are no ALBs deployed in a zone?](https://cloud.ibm.com/docs/containers?topic=containers-cs_subnet_limitcs_subnet_limit)

[Classic clusters: Why does source IP preservation fail when using tainted nodes?](https://cloud.ibm.com/docs/containers?topic=containers-cs_source_ip_failscs_source_ip_fails)

[Classic clusters: Why does enabling Ingress ALBs result in subnet errors?](https://cloud.ibm.com/docs/containers?topic=containers-cs_alb_subnetcs_alb_subnet)

[Why does a connection via WebSocket close after 60 seconds?](https://cloud.ibm.com/docs/containers?topic=containers-cs_ingress_websocketcs_ingress_websocket)
reserved_private_ip:
----

reserved_private_vlan_id:
----

reserved_public_ip:
----

Events: <none>



* VPC clusters: Verify that the VPC load balancer for your ALBs exists. In the output, look for the VPC load balancer Name that starts with kube-<cluster_ID>. If you did not install the infrastructure-service plug-in, install it by running ibmcloud plugin install infrastructure-service.

ibmcloud is load-balancers



Even though the VPC load balancer is listed, its DNS entry might still be registering. When a VPC load balancer is created, the hostname is registered through a public DNS. Sometimes, it can take several minutes for this DNS entry to be replicated to the specific DNS that your client is using.
3. Check whether an ALB exists for your cluster and that the ALB has an IP address (classic clusters) or hostname (VPC clusters) assigned.

ibmcloud ks ingress alb ls -c <cluster_name_or_ID>

Example output

ALB ID Enabled Status Type ALB IP Zone Build ALB VLAN ID NLB Version
private-crbmnj1b1d09lpvv3oof0g-alb1 false disabled private - dal10 ingress:1.1.2_2507_iks 2234947 2.0
public-crbmnj1b1d09lpvv3oof0g-alb1 true enabled public 169.XX.XXX.XX dal10 ingress:1.1.2_2507_iks 2234945 2.0



* If a public ALB is listed and is assigned an IP address (classic clusters) or hostname (VPC clusters), continue to the next step.
* If a public ALB is listed and but is not assigned an IP address (classic clusters) or hostname (VPC clusters), try to disable and re-enable the ALBs.



* Classic clusters:
Create the IngressController resource in the openshift-ingress-operator namespace of your cluster. When you create the IngressController resource, a private Ingress controller is automatically created and deployed in the openshift-ingress namespace based on the IngressController settings. Additionally, a Ingress controller service is created to expose the Ingress controller with an IP address (classic clusters) or a VPC hostname (VPC clusters).

oc create -f private.yaml -n openshift-ingress-operator
4. Get the IP address or VPC hostname in the EXTERNAL IP field of the router-private service.

oc get svc router-private -n openshift-ingress

Example output for classic clusters:

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
router-private LoadBalancer 172.21.57.132 10.XX.XX.XX 80/TCP,443/TCP,1940/TCP 3m

Example output for VPC clusters:

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
router-private LoadBalancer 172.21.57.132 1234abcd-us-south.lb.appdomain.cloud 80/TCP,443/TCP,1940/TCP 3m
5. Register the service's external IP address or VPC hostname with the domain that you chose in step 1.



* Custom domain, classic or VPC clusters: Work with your DNS provider to add the service's external IP address as an A record (classic clusters) or VPC hostname as a CNAME (VPC clusters) that maps to your custom domain.
* IBM-provided domain, VPC clusters only: Create a DNS entry for the service's VPC hostname. When you run the following command, the subdomain that you specified in step 2 is automatically generated, and is registered with the Ingress controller service.

ibmcloud oc nlb-dns create vpc-gen2 --cluster <cluster_name_or_ID> --lb-host <router_VPC_hostname> --type private



6.
Adding Spectrum multicluster (SMC) to Spectrum Symphony 

The Spectrum multicluster feature in IBM Spectrum Symphony Advanced Edition is used to connect multiple IBM Spectrum Symphony clusters into a federation cluster. Using this feature, you can:



* Use workload placement to redirect IBM Spectrum Symphony sessions to nonbusy clusters. Redirecting sessions balances workloads so that tasks within one session can be dispatched to multiple clusters based on resource availability on each federation member cluster.
* Deploy and manage service packages from the multicluster management console across member clusters.
* Monitor workload and resources, as this feature collects data from IBM Spectrum Symphony clusters and sends it to the IBM Spectrum Symphony multicluster primary cluster for aggregation and display.



SMC supports multiple Operating Systems, but the solution here uses RHEL8.6.

Adding SMC involves:



1. Manually creating a Schematics workspace to define your Terraform environment.
2. Manually entering and changing the SMC-related parameters.
3. Generating a Terraform plan that varifies the parameter settings and shows the resources that the scripts will create.
4. Applying the generated plan to deploy the configured resources.





 Architecture diagram 

Zoom

![Architecture diagram](https://cloud.ibm.com/docs-content/v1/content/7a8d1342aca7be29e4771ffe1bc72ebc54df73dc/hpc-spectrum-symphony/images/SMC-arch-diagram-Multi-Region.drawio.svg)

Figure 1. Architecture diagram zones and regions





 Before you begin 

Before you begin set up SMC, you must:

Deploy 3 lone (symphony) clusters in different regions or zones. For more information about creating symphony clusters, see the [readme file](https://github.com/IBM-Cloud/hpc-cluster-symphonyreadme).

When you provision lone symphony clusters, the cidr blocks and cluster_id must be unique for each Lone symphony cluster.
* NFS protocol - The NFS version of the storage.



* Network Interface - VLAN details



* VLAN number - The unique VLAN number.
* Description - The description of the VLAN.
* Location - The data center location.
* Primary route - The primary route of the VLAN. Click View resource to access the VLAN details.



* Network Interface - Subnet details



* Name - The subnet name. Click the name to access the subnet details.
* Type - The type of subnet, primary or portable.
* Description - The description of the subnet.



* Network Interface - IP details



* IP - The IP address.
* Status - The status of the IP address.
* Description - The description of the IP address.











 Deleting clusters from vCenter Server with Hybridity Bundle instances 

You might want to delete a cluster from an instance when it's no longer needed.

Deleting clusters from instances with vSphere 6.5 is not supported.



 Before you delete clusters from vCenter Server with Hybridity Bundle instances 



* Whenever possible, delete clusters by using the IBM Cloud® for VMware Solutions console and not the VMware vSphere® Web Client. Changes that you make on the vSphere Web Client are not synchronized with the VMware Solutions console. If you want to delete clusters from vCenter Server instances by using the vSphere Web Client, do so only for on-premises clusters or clusters that you don't manage in the VMware Solutions console.
* You can delete any cluster except for the first cluster (the one that is created during initial deployment).
* You can delete multiple clusters at a time. You can also delete a cluster while another cluster is being created or deleted.
* Ensure that all nodes in a cluster are powered on and operational before you delete the cluster.
* When you delete a cluster, all VMs (virtual machines) from the cluster are also deleted and they can't be recovered. If you want to keep the VMs, migrate them to other clusters.









 Procedure to delete clusters from vCenter Server with Hybridity Bundle instances 



1.
Registering clusters with Satellite Config 

Clusters you create in your Satellite Location are automatically registered with Satellite Config. You can also manually register other clusters in the public cloud or your existing Red Hat OpenShift on IBM Cloud clusters with Satellite Config. Follow the steps to run the registration script in your cluster to set up the Satellite Config components and make the cluster visible in Satellite.

After you complete these steps, the cluster can be added to a cluster group in your location and [subscribed to Satellite configurations](https://cloud.ibm.com/docs/satellite?topic=satellite-satcon-manage-direct-upload). However, you must still use Red Hat OpenShift on IBM Cloud to manage the worker nodes for these clusters.



1. Find the cluster in the public cloud that you want to attach to Satellite Config. To list available clusters, run ibmcloud oc cluster ls or go to the [Red Hat OpenShift cluster dashboard](https://cloud.ibm.com/kubernetes/clusters?platformType=openshift).

Do not manually register clusters created in a Satellite Location. These clusters are automatically registered with Satellite Config. Registering them again manually might cause issues in your Location or cluster.
2. From the Satellite [Clusters](https://cloud.ibm.com/satellite/clusters) dashboard, click Register cluster.
3. Enter the name of your cluster and click Register cluster. Registering a cluster creates an entry in the Satellite Config ConfigMap. However, your cluster cannot be subscribed to a Satellite configuration until you install the Satellite Config agent in your cluster.
4. Copy the command that is displayed to you.
5. [Log in to your Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster) and run the command in your cluster. The command creates the razeedeploy project, custom resource definitions and RBAC policies on your cluster that are required to make your cluster visible to Satellite Config.

Example output

namespace/razeedeploy created
Why aren't my OpenShift clusters being scanned? 

  What’s happening 

You created a connection between the OpenShift Compliance Operator and the Security and Compliance Center, but your clusters are not being scanned.

  Why it’s happening 

There are a few reasons that this might happen:



*  Your scope does not contain any OpenShift clusters.
*  The integration might not be enabled in your scan settings.



  How to fix it 

To resolve the issue:



*  Verify that your scope contains OpenShift clusters.
*  Verify that the integration is enabled in your scan settings.
Planning your cluster for high availability 

Design your standard cluster for maximum availability and capacity for your app with Red Hat® OpenShift® on IBM Cloud®.

Your users are less likely to experience downtime when you distribute your apps across multiple worker nodes, zones, and clusters. Built-in capabilities, like load balancing and isolation, increase resiliency against potential failures with hosts, networks, or apps. Review these potential cluster setups that are ordered with increasing degrees of availability.

Zoom

![High availability for clusters](https://cloud.ibm.com/docs-content/v1/content/bce0f0917a9eea684d1b4b704ac6343a1f65f446/openshift/images/cs_cluster_ha_roadmap_multizone_public.png)

Figure 1. High availability for clusters



1. A [single zone cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-ha_clusterssingle_zone) with multiple worker nodes in a worker pool.
2. A [multizone cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-ha_clustersmz-clusters) that spreads worker nodes across zones within one region.
3. Clusters with public network connectivity: [Multiple clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-ha_clustersmultiple-clusters-glb) that are set up across zones or regions and that are connected via a global load balancer.





 Single zone clusters 

Single zone clusters can be created in one of the supported [single zone locations](https://cloud.ibm.com/docs/openshift?topic=openshift-regions-and-zoneszones-sz). To improve availability for your app and to allow failover for the case that one worker node is not available in your cluster, add additional worker nodes to your single zone cluster.
Enable [image security enforcement](https://cloud.ibm.com/docs/openshift?topic=openshift-imagesportieris-image-sec) by installing the Portieris Kubernetes admission controller and the associated default image policies in your cluster.

ibmcloud oc cluster image-security enable --cluster CLUSTER [-f] [-q]

Minimum required permissions
: Administrator platform access role for the cluster in IBM Cloud Kubernetes Service

Command options:

-c, --cluster CLUSTER
: Required: The name or ID of the cluster.

-f
: Optional: Force the command to run with no user prompts.

-q
: Optional: Do not show the message of the day or update reminders.



 Example cluster image-security enable command 

ibmcloud oc cluster image-security enable --cluster my_cluster







 ibmcloud oc cluster ls 

Virtual Private Cloud

Classic infrastructure

Satellite

List all clusters in your IBM Cloud account.

Clusters in all locations are returned. To filter clusters by a specific location, include the --location option. For example, if you filter clusters for the dal metro, multizone clusters in that metro and single-zone clusters in data centers (zones) within that metro are returned. If you filter clusters for the dal10 data center (zone), multizone clusters that have a worker node in that zone and single-zone clusters in that zone are returned. You can pass one location or a comma-separated list of locations.

ibmcloud oc cluster ls [--provider (classic | vpc-gen2)] [--location LOCATION] [--output json] [-q]

Minimum required permissions
: Viewer platform access role for the cluster in IBM Cloud Kubernetes Service

Command options:

--provider (classic | vpc-gen2)
: Optional: Filter output based on infrastructure provider type.

-l, --location LOCATION
: Filter output by a specific location. To see supported locations, run ibmcloud oc locations. To specify multiple locations, use one option for each location, such as -l dal -l seo.
When the PVDC contains multiple clusters and one cluster is deleted, all VMs running in that cluster are migrated to other clusters in the same PVDC.

VMs deployed to a specific storage performance tier are only migrated to the same performance tier of storage in the remaining clusters. You must ensure that the remaining clusters have compatible storage performance layers of the deleted cluster. The remaining clusters must also have enough CPU and memory to contain the VMs of the deleted cluster.

If not enough CPU, RAM, or equivalent storage performance for the cluster exists, the delete operation does not succeed. When the delete cluster operations are not successful, workloads are not impacted, and the operation is retried. Resource constraints are resolved by either stopping or deleting VMs or ensuing other clusters in the PVDC have the resource to support migrated workload VMs.





 Procedure to delete clusters 



1. In the VMware Solutions console, click Resources > VMware as a Service from the left navigation pane.
2. In the VMware as a Service table, click the Cloud director sites tab, then click an instance name.
3. Click the Infrastructure tab.
4. On the Clusters tab, locate the cluster that you want to delete.
5. Click the vertical overflow menu next to the Status column for that cluster and click Delete cluster.
6. Confirm that you want to delete.







 Related links 



* [Adding virtual data centers](https://cloud.ibm.com/docs/vmware-service?topic=vmware-service-vdc-adding)
* [Viewing and deleting virtual data centers](https://cloud.ibm.com/docs/vmware-service?topic=vmware-service-vdc-view-delete)
* [Viewing VMware as a Service instances](https://cloud.ibm.com/docs/vmware-service?topic=vmware-service-tenant-viewing)
[Gathering Ingress logs](https://cloud.ibm.com/docs/openshift?topic=openshift-ingress-must-gatheringress-must-gather)

[Classic clusters: Why can't my app connect via Ingress?](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_ingress_failscs_ingress_fails)

[VPC clusters: Why can't my app connect via Ingress?](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc_ts_albvpc_ts_alb)

[Why does no Ingress subdomain exist after cluster creation?](https://cloud.ibm.com/docs/openshift?topic=openshift-ingress_subdomainingress_subdomain)

[Why does no Ingress subdomain exist after I create clusters of the same or similar name?](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_rate_limitcs_rate_limit)

[VPC clusters: Why does the VPC load balancer for Ingress controller only route to one zone?](https://cloud.ibm.com/docs/openshift?topic=openshift-router-mzr-errorrouter-mzr-error)

[Classic clusters: Why doesn't the Ingress controller deploy in a zone?](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_subnet_limit_43cs_subnet_limit_43)



* [Resolving VLAN issues](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_subnet_limit_43resolve_vlan)
These apps are accessible by a public endpoint, which is secured by the API Gateway to the world. Then, researchers and data analysts from everywhere can download data sets and do their own analysis.

Developers started by deploying their research-sharing SaaS apps in containers with IBM Cloud Kubernetes Service. They created clusters for a Development environment that allow worldwide Developers to collaboratively deploy app improvements quickly.

Security first: The Development Exec chose bare metal to host the research clusters. With bare metal for IBM Cloud Kubernetes Service, the sensitive research workloads now have familiar isolation but within the flexibility of public cloud. Because this nonprofit also has a partnership with pharmaceutical companies, app security is crucial. Competition is fierce, and corporate espionage is possible. From that secure core, Vulnerability Advisor provides scanning.



* Image vulnerability scanning
* Policy scanning based on ISO 27k



Secured research apps lead to increased clinical trial participation.

To achieve global availability, the Dev, Test, and Production systems are deployed across the globe in several data centers. For HA, they use a combination of clusters in multiple geographic regions as well as multizone clusters. They can easily deploy the research app to Frankfurt clusters to comply with the local European regulation. They also deploy the app within the United States clusters to ensure availability and recovery locally. They also spread the research workload across multizone clusters in Frankfurt to ensure that the European app is available and also balances the workload efficiently. Because researchers are uploading sensitive data with the research-sharing app, the app’s clusters are hosted in regions where stricter regulations apply.

Developers focus on domain problems, by using existing tools: Instead of writing unique ML code, ML logic is snapped into apps, by binding IBM Cloud services to clusters. Developers are also freed up from infrastructure management tasks because IBM takes care of Kubernetes and infrastructure upgrades, security, and more.

Compute, storage, and apps run in public cloud with secure access to research data across the globe, as warranted. Compute in clusters is tamper-proof and isolated to bare metal.

Technical solution:



* IBM Cloud Kubernetes Service
* IBM Cloud® Functions
* IBM Cloudant
* IBM® Secure Gateway for IBM Cloud®