vania-janet/multiturn-rag-retrieval-data huggingface dataset:
For issues in open source projects that are used by IBM Cloud, see the [IBM open source and third-party policy](https://www.ibm.com/support/pages/node/737271).







 Identifying issues for Satellite-enabled IBM Cloud service 

If you experience an issue with a Satellite-enabled IBM Cloud service in your location, first check whether your issue is listed in the troubleshooting topics in the Satellite documentation. If the issue is not listed in the Satellite documentation, check the IBM Cloud documentation set for the service.

For example, if you cannot access the Red Hat OpenShift console for a Red Hat OpenShift cluster on Satellite, first check whether the issue is [specific to your Satellite location setup](https://cloud.ibm.com/docs/satellite?topic=satellite-ts-console-fail). If your Satellite location setup is not the source of the issue, then check the [Red Hat OpenShift on IBM Cloud documentation for troubleshooting console issues](https://cloud.ibm.com/docs/openshift?topic=openshift-ocp-debug).





 Reviewing logs 

You can review logs to troubleshoot issues.

If your host is not assigned to a cluster, or if the assignment fails, you can SSH into the host machine and view logs. Otherwise, Satellite disables the ability to log in to the host by using SSH for security purposes. For more information about viewing logs on your host machine, see [Logging in to a host machine to debug](https://cloud.ibm.com/docs/satellite?topic=satellite-ts-hosts-login).

If you are using Schematics, you can view job log details to find information about your deployment. For more information, see [Reviewing the Schematics job details](https://cloud.ibm.com/docs/schematics?topic=schematics-wks-state).

You can also view logs that are automatically generated for your Satellite location setup and collected in an IBM Log Analysis instance. For more information, see [Logging for Satellite](https://cloud.ibm.com/docs/satellite?topic=satellite-health).





 Feedback and questions
* Manager IBM Cloud IAM service access role for IBM Cloud Schematics



* Specifically provision a Kubernetes cluster and deploy NGINX reverse proxy in it to forward to the Direct Link endpoints.







 Step 1: Creating a Red Hat CoreOS enabled Satellite Location 

You can skip this step if you already have a Red Hat CoreOS enabled Satellite Location.

Log in to your IBM Cloud account that has Direct Link and create a Red Hat CoreOS enabled Satellite Location. For more information, see [Creating a Satellite location](https://cloud.ibm.com/docs/satellite?topic=satellite-locationsverify-coreos-location).





 Step 2: Creating a relay 

The relay is an http/https reverse proxy that supports secure Websocket connections. It can run on VSI, Red Hat OpenShift or IBM Cloud Kubernetes Service as Classic or VPC. The following steps demonstrates an example for deploying NGINX reverse proxy on a private-only VPC Red Hat OpenShift cluster (on VPC private nodes).

One essential requirement is to have a valid name that can be assigned to the cluster private ingress (Relay Ingress) and a valid certificate on IBM Cloud. On IBM Cloud, VPC Red Hat OpenShift clusters on private nodes come with default private host name and certificate. You can use them or bring your custom host name and certificate. This example uses the default private host name and certificates.

VPC clusters considerations for this scenario:



* Zone: Any multizone-capable VPC zone
* Worker node flavor: Any VPC infrastructure flavor
* Version: 4.x.x
* Worker pool: At least 2 worker nodes
* Subnets: Include Ingress Load Balancer IP subnets if the default ranges conflict with the --pod-subnet and --service-subnet values of the Red Hat OpenShift cluster on Satellite or the network CIDR where the Satellite or Red Hat OpenShift hosts are deployed on-premise.
* Cloud service endpoints: Do not specify the --disable-public-service-endpoint option if you want both public and private endpoints.
* Spread the default worker pool across zones to increase the availability of your classic or VPC cluster.
After you [create a Red Hat OpenShift cluster in your Satellite location](https://cloud.ibm.com/docs/openshift?topic=openshift-satellite-clusters), you can begin working with your cluster by accessing the cluster.

Want to set up a VPN to connect to your cluster from your local machine? Check out [Accessing private clusters by using the WireGuard VPN](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-access-wireguard).



 Accessing clusters through the cluster service URL 

Connect to your cluster through its service URL. This URL is one of your Satellite location subdomains and a node port, which is formatted such as https://p1iuql40jam23qiuxt833-q9err0fiffbsar61e78vv6e7ds8ne1tx-ce00.us-east.satellite.appdomain.cloud:30710.

If your location hosts have private network connectivity only, or if you use Amazon Web Services, Google Cloud Platform, and Microsoft Azure hosts, you must be connected to your hosts' private network, such as through VPN access, to connect to your cluster and access the Red Hat OpenShift web console. Alternatively, if your hosts have public network connectivity, you can test access to your cluster by changing your cluster's and location's DNS records to [use your hosts' public IP addresses](https://cloud.ibm.com/docs/openshift?topic=openshift-access_clustersat_public_access).

You can quickly access your Red Hat OpenShift on IBM Cloud cluster from the console.



1. In the [Red Hat OpenShift clusters console](https://cloud.ibm.com/kubernetes/clusters?platformType=openshift), click the cluster that you want to access.
2. Click Red Hat OpenShift web console.
3. Click your profile name, such as IAMname@email.com, and then click Copy Login Command.
4.
name: wasliberty
labels:
app: wasliberty
spec:
ports:
- port: 9080
selector:
app: wasliberty
type: NodePort

If you have a requirement to deploy hostNetwork pods to listen on specific ports or to use a hostPort to expose your app pods on a specific port on the worker node, use a port in the 11000-11200 range. Red Hat OpenShift on IBM Cloud designates the 11000-11200 port range on worker nodes for this purpose to avoid conflicts with local ports and other ports that Red Hat OpenShift on IBM Cloud uses. Because hostNetwork pods and hostPorts refer to a particular worker node IP address, the pods are limited to run only on that worker node. If something unanticipated happens, such as the worker node being removed or running out of resources, your pod can't be rescheduled. If you want to expose a pod’s port on the worker node, consider using a [NodePort service](https://cloud.ibm.com/docs/openshift?topic=openshift-nodeport) instead. For more information, see the [Kubernetes best practices documentation](https://kubernetes.io/docs/concepts/configuration/overview/services).





 Configmaps for container environment variables 

Configmaps provide non-sensitive configuration information for your deployment workloads.

The following example shows how you can reference values from your ConfigMap as environment variables in the container spec section of your deployment YAML. By referencing values from your ConfigMap, you can decouple this configuration information from your deployment to keep your containerized app portable.



* [Help me decide whether to use a Kubernetes ConfigMap or Secret object for variables](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_deployvariables).
Repeat these steps for each bare metal host that you want to attach to your location.







 Step 2: Assigning a Bare Metal Server host to your Red Hat OpenShift cluster 

After your Bare Metal Server is attached to your location, you can assign it to a Red Hat OpenShift cluster worker pool.



1. Find the hosts to add to your Red Hat OpenShift cluster worker pool.

ibmcloud sat hosts --location <locationID>
2. Assign the Bare Metal Server to the Red Hat OpenShift cluster worker pool

ibmcloud sat host assign --location <locationID> --cluster <clusterID> --host <hostID> --worker-pool default --zone <zone>



Repeat these step to assign more Bare Metal Servers to your cluster.

Now that your Bare Metal Server is assigned to a worker pool, you can set up Red Hat OpenShift virtualization.





 Step 3: Setting up storage for your cluster 

In this example scenario, you deploy OpenShift Data Foundation across 3 nodes in the cluster by automatically discovering the available storage disks on your Bare Metal Servers.

After you have attached at least 3 Bare Metal Servers to your location and assigned them as worker nodes in your cluster, you can deploy OpenShift Data Foundation by using the odf-local Satellite storage template.



1. From the [Satellite locations console](https://cloud.ibm.com/satellite/locations), click your location, then click Storage > Create storage configuration.
2. Give your configuration a name.
3. Select OpenShift Data Foundation for local devices and select version 4.10
4. For this example, leave the rest of the default settings and click Next.
5. Wait for ODF to deploy. Then, verify the pods are ready by listing the pods in the openshift-storage namespace.

oc get pods -n openshift-storage

Example output

NAME READY STATUS RESTARTS AGE
ocs-metrics-exporter-5b85d48d66-lwzfn 1/1 Running 0 2d1h
ocs-operator-86498bf74c-qcgvh 1/1 Running 0 2d1h
: With the latest version of the cluster autoscaler, you can [enable autoscaling for worker pools during the Helm chart installation](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-helm) instead of modifying the config map after installation.

Ingress ALB change log
: Updated the ALB [nginx-ingress image to build 524 and ingress-auth image to build 337](https://cloud.ibm.com/docs/containers?topic=containers-cluster-add-ons-changelogkube_ingress_changelog).

New! Seoul, Korea seo01 single zone location for Red Hat OpenShift clusters
: For more locations, see [Single and multizone locations in Red Hat OpenShift on IBM Cloud](https://cloud.ibm.com/docs/openshift?topic=openshift-regions-and-zones).





 23 August 2019 

New! Single zone locations for Red Hat OpenShift clusters
: You can create Red Hat OpenShift clusters in Toronto, Canada tor01 and Singapore sng01 single zone locations. For more locations, see [Single and multizone locations in Red Hat OpenShift on IBM Cloud](https://cloud.ibm.com/docs/openshift?topic=openshift-regions-and-zones).





 20 August 2019 

Ingress ALB change log
: Updated the ALB [nginx-ingress image to build 519](https://cloud.ibm.com/docs/containers?topic=containers-cluster-add-ons-changelogkube_ingress_changelog) for a custom-ports bug fix.





 17 August 2019 

IBM Cloud® Activity Tracker
: The [IBM Cloud Activity Tracker service](https://cloud.ibm.com/docs/openshift?topic=openshift-at_events) is now supported for you to view, manage, and audit user-initiated activities in your clusters.

Version change log
Add compute capacity to your location by [attaching more hosts to the location](https://cloud.ibm.com/docs/satellite?topic=satellite-attach-hosts) so that you can run [Satellite-enabled IBM Cloud service](https://cloud.ibm.com/docs/satellite?topic=satellite-managed-services).
2. Create a [Satellite-enabled IBM Cloud service](https://cloud.ibm.com/docs/satellite?topic=satellite-managed-services), such as a [Red Hat OpenShift cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-satellite-clusters). You assign the additional hosts that you previously attached as worker nodes to provide the compute power for the cluster. You can even [register existing Red Hat OpenShift clusters to your location](https://cloud.ibm.com/docs/satellite?topic=satellite-register-openshift-clusters) to use as deployment targets.
3. [Manage your applications](https://cloud.ibm.com/docs/satellite?topic=satellite-cluster-config) with Satellite Config.
4. Create [Satellite cluster storage templates](https://cloud.ibm.com/docs/satellite?topic=satellite-storage-template-ov).
5. Learn more about the [Satellite Link component](https://cloud.ibm.com/docs/satellite?topic=satellite-link-location-cloud) and how you can use endpoints to manage the network traffic between your location and IBM Cloud.



Need help? Check out [Getting support](https://cloud.ibm.com/docs/satellite?topic=satellite-get-help) where you can find information about cloud status, issues, and logging; contacting support; and setting your email notification preferences for IBM Cloud platform-related items.
* Subnets: Include Ingress Load Balancer IP subnets if the default ranges conflict with the --pod-subnet and --service-subnet values of the Red Hat OpenShift cluster on Satellite or the network CIDR where the Satellite or Red Hat OpenShift hosts are deployed on-premise.
* Cloud service endpoints: Do not specify the --disable-public-service-endpoint option if you want both public and private endpoints.
* Spread the default worker pool across zones to increase the availability of your classic or VPC cluster.
* Ensure that at least 2 worker nodes exist in each zone, so that the private ALBs that you configure in subsequent steps are highly available and can properly receive version updates.



In the following example, we create a private-only VPC cluster and use the private Ingress controller that is created by default. However, you can also use a Red Hat OpenShift cluster with a public cloud service endpoint enabled, but in this case your cluster is created with only a public Ingress controller by default. If you want to set up your relay by using a cluster with a public service endpoint, you must first enable the private Ingress controller and register it with a subdomain and certificate by following the steps in [Setting up Ingress](https://cloud.ibm.com/docs/openshift?topic=openshift-ingress-roks4).



1. Create a private-only Red Hat OpenShift cluster on VPC. For more information, see [Creating VPC clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-create-vpc-gen2&interface=ui).

There are many ways to expose apps in Red Hat OpenShift cluster in a VPC. In this example, the app will be privately exposed with private endpoints only, which is the most common use case for Direct Link customers. Red Hat OpenShift clusters that are privately exposed with private endpoints only come with default private name and certificate. They will be used in this example to expose the NGINX reverse proxy pods. You can use the default ones or bring your custom host name and certificate.
After these steps, you can fix your deployment issue and redeploy the Red Hat OpenShift platform.





 Generating new ignition files 

Your ignition files are valid for 24 hours. You can generate the .ign files by completing the following steps:



1. Remove old state, configuration, and ign files:

cd /opt/ocpinstall
rm -R .openshift_install.log .openshift_install_state.json auth .ign metadata.json
2. Copy Red Hat OpenShift the install-config backup to yaml:

cp install-config.bak install-config.yaml
openshift-install create ignition-configs --dir=/opt/ocpinstall/
3. Copy bootstrap.ign to nginx home folder.

cp bootstrap.ign /usr/share/nginx/html
4. Replace the primary section (cat master.ign) and the worker section (cat worker.ign) in terraform.tfvars. nano /opt/ocpinstall/installer/upi/vsphere/terraform.tfvars.

// Ignition config for the control plane machines. You should copy the contents of the master.ign generated by$
control_plane_ignition = <<END_OF_MASTER_IGNITION
<replace with new master.ign>
END_OF_MASTER_IGNITION

// Ignition config for the compute machines. You should copy the contents of the worker.ign generated by the i$
compute_ignition = <<END_OF_WORKER_IGNITION
<replace with new worker.ign>
END_OF_WORKER_IGNITION







 Taking a snapshot of Red Hat OpenShift 

You might want to stop and resume Red Hat OpenShift Cluster VMs during development or testing. You must consider the following before you take a snapshot.
If you have a classic Red Hat OpenShift on IBM Cloud cluster, you can choose worker node flavors that are optimized for SDS usage and that come with one or more raw, unformatted, and unmounted local disks that you can use to store your data. Portworx offers best performance when you use [SDS worker node machines](https://cloud.ibm.com/docs/openshift?topic=openshift-planning_worker_nodessds) that come with 10Gbps network speed. However, you can install Portworx on non-SDS worker node flavors in classic clusters, but you might not get the performance benefits that your app requires.

Portworx is installed by using a [Helm chart](https://cloud.ibm.com/docs/openshift?topic=openshift-storage_portworx_about). When you install the Helm chart, Portworx automatically analyzes the local persistent storage that is available in your cluster and adds the storage to the Portworx storage layer. To add storage from your Portworx storage layer to your apps, you must use [Kubernetes persistent volume claims](https://cloud.ibm.com/docs/openshift?topic=openshift-storage_portworx_deploy).

For more information about how to install and use Portworx with Red Hat OpenShift on IBM Cloud, see [Setting up software-defined storage (SDS) with Portworx](https://cloud.ibm.com/docs/openshift?topic=openshift-storage_portworx_about).





 Billing and support 

Classic SDS worker node machines that come with local disks, and classic virtual machines that you use for Portworx are in your monthly Red Hat OpenShift on IBM Cloud bill. For pricing information, see the [IBM Cloud catalog](https://cloud.ibm.com/kubernetes/catalog/about). The Portworx license is a separate cost and is not included in your monthly bill.

Contact Portworx support by using one of the following methods.
Migrating classic IBM Cloud Kubernetes Service or Red Hat OpenShift cluster to VPC 

You can migrate your classic IBM Cloud® Kubernetes Service or Red Hat® OpenShift® cluster to VPC by using the VPC+ tool for clusters that are deployed in a single data center. You can also migrate multiple data centers to a multizone region. VPC+ discovers both the classic and IBM Cloud Kubernetes Service or Red Hat OpenShift resources and components. Along with the other resources and workloads running within Kubernetes, see the following list for some of the components and resources that are discovered:



* Worker nodes and pools
* PODs
* Namespaces
* Secrets
* StatefulSets
* DaemonSet
* Deployments
* ConfigMaps
* Custom resource definitions
* PVC



As part of the migration, the VPC+ tool creates a new cluster in a VPC single availability zone, and backs up and restores the Kubernetes workload resources to your new VPC environment.



 Before you begin 

Before you begin migrating your classic IBM Cloud Kubernetes Service or Red Hat OpenShift cluster to VPC by using the VPC+ tool, review the following requirements:



1. Be familiar with the [Considerations for IBM Cloud Kubernetes Service and Red Hat OpenShift migration](https://cloud.ibm.com/docs/wanclouds-vpc-plus?topic=wanclouds-vpc-plus-migration-considerationskubernetes-migration).
2. Make sure that the IBM Cloud Kubernetes Service or Red Hat OpenShift Administrator role is assigned to your user account.
3. You need both a classic infrastructure API key and IBM Cloud VPC API key.
4. HMAC keys (Access Key ID and Secret Access Key) are required when you add a VPC account for workload backup and restore.





 Limitations 

Review the following limitations:



* Private clusters cannot be migrated.
* Only PVC with block storage is supported.
Every standard cluster is provisioned with four portable public and four portable private IP addresses that you can use to create a layer 4 TCP/UDP network load balancer (NLB) for your app. You can customize your NLB by exposing any port that your app requires. The portable public and private IP addresses that are assigned to the NLB are permanent and don't change when a worker node is re-created in the cluster. If you create public NLBs, you can create a subdomain for your app that registers the public NLB IP addresses with a DNS entry. You can also enable health check monitors on the NLB IPs for each subdomain.
* VPC clusters: [Load Balancer for VPC](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-lbaas). When you create a Kubernetes LoadBalancer service for an app in your cluster, a layer 7 VPC load balancer is automatically created in your VPC outside of your cluster. The VPC load balancer is multizonal and routes requests for your app through the private NodePorts that are automatically opened on your worker nodes. By default, the load balancer is also created with a hostname that you can use to access your app, but you can also create a subdomain for your app that creates a DNS entry.



Ingress
: You can use [Ingress](https://cloud.ibm.com/docs/openshift?topic=openshift-ingress-roks4) to expose your app to external traffic via the Red Hat OpenShift Ingress controller. The Red Hat OpenShift Controller Manager converts your Ingress resources to Route resources and the Red Hat OpenShift Ingress controller processes those Routes.





 Choosing among load balancing solutions 

Now that you understand what [options](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_network_planningexternal) you have to expose apps in your Red Hat OpenShift cluster, choose the best solution for your workload.

The following table compares the features of each app exposure method.
Your responsibilities with using Red Hat OpenShift on Satellite 

Learn about cluster management responsibilities that you have when you use Red Hat OpenShift on Satellite clusters. For overall terms of use, see [Cloud Services terms](https://cloud.ibm.com/docs/overview/terms-of-use?topic=overview-termsterms).



 Overview of shared responsibilities 

Red Hat OpenShift on IBM Cloud is a managed service in the [IBM Cloud shared responsibility model](https://cloud.ibm.com/docs/overview/terms-of-use?topic=overview-shared-responsibilities). Review the following table of who is responsible for particular cloud resources when using Red Hat OpenShift on IBM Cloud. Then, you can view more granular tasks for shared responsibilities in [Tasks for shared responsibilities by area](https://cloud.ibm.com/docs/openshift?topic=openshift-satellite-responsibilitiestask-responsibilities-sat).

If you use other IBM Cloud products such as Object Storage, responsibilities that are marked as yours in the following table, such as disaster recovery for Data, might be IBM's or shared. Consult those products' documentation for your responsibilities.



Table 1. Responsibilities by resource.

 Resource [Incident and operations management](https://cloud.ibm.com/docs/openshift?topic=openshift-satellite-responsibilitiesincident-and-ops-sat) [Change management](https://cloud.ibm.com/docs/openshift?topic=openshift-satellite-responsibilitieschange-management-sat) [Identity and access management](https://cloud.ibm.com/docs/openshift?topic=openshift-satellite-responsibilitiesiam-responsibilities-sat) [Security and regulation compliance](https://cloud.ibm.com/docs/openshift?topic=openshift-satellite-responsibilitiessecurity-compliance-sat) [Disaster Recovery](https://cloud.ibm.com/docs/openshift?topic=openshift-satellite-responsibilitiesdisaster-recovery-sat)