vania-janet/multiturn-rag-retrieval-data huggingface dataset:
* [Updating the Calico ConfigMap](https://cloud.ibm.com/docs/containers?topic=containers-kernelcalico-cm-mtu-update)



* [Disabling the port map plug-in](https://cloud.ibm.com/docs/containers?topic=containers-kernelcalico-portmap)



[Removing clusters](https://cloud.ibm.com/docs/containers?topic=containers-removeremove)

[Preparing for host maintenance updates](https://cloud.ibm.com/docs/containers?topic=containers-host-maintenancehost-maintenance)



* [Identifying your affected workers](https://cloud.ibm.com/docs/containers?topic=containers-host-maintenanceworker-maintenance-list)
* [Actions to take before the maintenance period](https://cloud.ibm.com/docs/containers?topic=containers-host-maintenanceworker-maintenance-actions)



* [Workers in Classic clusters](https://cloud.ibm.com/docs/containers?topic=containers-host-maintenanceworker-maintenance-classic)
* [Workers in VPC clusters](https://cloud.ibm.com/docs/containers?topic=containers-host-maintenanceworker-maintenance-vpc)





[Migrating to a new Ubuntu version](https://cloud.ibm.com/docs/containers?topic=containers-ubuntu-migrateubuntu-migrate)



* [Prerequisites](https://cloud.ibm.com/docs/containers?topic=containers-ubuntu-migrateubuntu-migrate-prereqs)
* [Migration steps](https://cloud.ibm.com/docs/containers?topic=containers-ubuntu-migrateubuntu-migrate-steps)
* [Removing your old worker pools](https://cloud.ibm.com/docs/containers?topic=containers-ubuntu-migrateubuntu-migrate-removal)









 Managing cluster costs
* [17 July 2019](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift-relnotesopenshift-july1719)



* Ingress ALB change log



* [15 July 2019](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift-relnotesopenshift-july1519)



* Ingress ALB change log
* Troubleshooting clusters



* [2 July 2019](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift-relnotesopenshift-july0219)



* CLI change log



* [1 July 2019](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift-relnotesopenshift-july0119)



* Infrastructure permissions
* Red Hat OpenShift FAQs
* strongSwan VPN service





* [June 2019](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift-relnotesopenshift-jun19)



* [24 June 2019](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift-relnotesopenshift-june2419)



* Calico network policies
* Ingress ALB change log



* [21 June 2019](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift-relnotesopenshift-june2119)



* Accessing clusters
* Troubleshooting Red Hat OpenShift clusters



* [18 June 2019](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift-relnotesopenshift-june1819)



* CLI change log
* Ingress ALB change log
* Removing persistent storage
* Service bindings with private endpoint
IBM monitoring actions to address certain scenarios.

 Scenario Action 

 Location control plane does not have a host in three separate zones. Check for attached, unassigned hosts in the location. If a host is available, assign the host to the location control plane for the missing zone, giving preference to hosts with a label that matches the zone. 
 Cluster capacity exceeds 80% in a zone. Prevent or allow Red Hat OpenShift clusters to be created. Assign available hosts to a location control plane for more compute resources. 
 Red Hat OpenShift clusters are in an unhealthy state. Resolve certain health issues with Red Hat OpenShift clusters. 
 Default monitoring tools like Prometheus do not work. Send alerts to your IBM Log Analysis instance and return a status message with further troubleshooting information. 
 Ingress subdomain registration fails. Alert IBM engineers to troubleshoot the issues further and return a status message with further troubleshooting information. 









 Viewing location, host, and cluster health 

You can review the health of Satellite resources such as locations, hosts, clusters, and Kubernetes resources that run in clusters.



 Viewing location health 

When you set up a Satellite location, IBM Cloud monitors the host and reports back statuses that you can use to keep your location healthy. For more information, see [IBM monitoring to resolve and report location alerts](https://cloud.ibm.com/docs/satellite?topic=satellite-monitormonitoring-default). For troubleshooting help, see [Debugging location health](https://cloud.ibm.com/docs/satellite?topic=satellite-ts-locations-debug).

You can review the host health from the Locations table in the [Satellite console](https://cloud.ibm.com/satellite/locations), or by running ibmcloud sat location ls.



Location health states

 Health state Description 

 action required The location needs your attention. Check the status and message for more information, and try [debugging your location](https://cloud.ibm.com/docs/satellite?topic=satellite-ts-locations-debug).
Kubernetes Ingress image
: Versions 1.0.3_1730_iks and 0.49.3_1830_iks of the [Kubernetes Ingress image](https://cloud.ibm.com/docs/containers?topic=containers-cluster-add-ons-changelogkube_ingress_changelog) are released.





 18 November 2021 

IBM Cloud Activity Tracker and IBM Cloud Activity Tracker
: Previously, clusters running in Toronto (ca-tor) sent logs to Washington D.C., and clusters running in Osaka (jp-osa) or Sydney (au-syd) sent logs to Tokyo. Beginning 18 November 2021, all instances of Log Analysis and Activity Tracker that are used for clusters running in Osaka (jp-osa), Toronto (ca-tor), and Sydney (au-syd) send logs to their respective regions. To continue receiving logs for clusters in these regions, you must create instances of IBM Cloud Activity Tracker and IBM Cloud Activity Tracker in the same region as your cluster. If you already have instances in these regions, look for logs in those instances.

IBM Cloud Object Storage
: Version 2.1.7 of the [IBM Cloud Object Storage plug-in](https://cloud.ibm.com/docs/containers?topic=containers-cos_plugin_changelog) is released.





 17 November 2021 

Worker node fix pack update
: Change log documentation is available for version [1.22.3_1529](https://cloud.ibm.com/docs/containers?topic=containers-changelog_1221223_1529), [1.21.6_1539](https://cloud.ibm.com/docs/containers?topic=containers-changelog_1211216_1539), [1.20.12_1561](https://cloud.ibm.com/docs/containers?topic=containers-changelog_12012012_1561), and [1.19.16_1568](https://cloud.ibm.com/docs/containers?topic=containers-changelog_11911916_1568).





 15 November 2021 

CLI change log
kind: ConfigMap
metadata:
name: ingress-deploy-config
namespace: kube-system
data:
"updatePercentage": "35"
"updateStartTime": "20:34"
"updateEndTime": "23:59"
2. Deploy the ConfigMap in your cluster. The new rules apply the next time an update takes place.

kubectl apply -f <filename>.yaml







 Choosing a supported image version 

IBM Cloud Kubernetes Service supports only the Kubernetes Ingress image for the Ingress application load balancers (ALBs) in your cluster. The Kubernetes Ingress image is built on the community Kubernetes project's implementation of the NGINX Ingress controller. The previously supported IBM Cloud Kubernetes Service Ingress image, which was built on a custom implementation of the NGINX Ingress controller, is unsupported.

Clusters created on or after 01 December 2020: Default application load balancers (ALBs) run the Kubernetes Ingress image in all new IBM Cloud Kubernetes Service clusters.

Clusters created before 01 December 2020:



* Existing clusters with ALBs that run the custom IBM Ingress image continue to operate as-is.
* Support for the custom IBM Ingress image ended on 02 June 2021.
* You must move to the new Kubernetes Ingress by migrating any existing Ingress setups. Your existing ALBs and other Ingress resources are not automatically migrated to the new Kubernetes Ingress image.
* Any ALBs with the unsupported image continue to run, but are not supported by IBM.
create = "15m"
update = "15m"
delete = "15m"
}
}
Show more
2. After you finish building your configuration file, initialize the Terraform CLI. For more information, see [Initializing Working Directories](https://www.terraform.io/cli/init).

terraform init
3. Provision the resources from the main.tf file. For more information, see [Provisioning Infrastructure with Terraform](https://www.terraform.io/cli/run).



1. Run terraform plan to generate a Terraform execution plan to preview the proposed actions.

terraform plan
2. Run terraform apply to create the resources that are defined in the plan.

terraform apply



4. From the [IBM Cloud resource list](https://cloud.ibm.com/resources), select the CIS instance that you created and note the instance ID.
5. Verify that the access policy is successfully assigned. For more information, see [Reviewing assigned access in the console](https://cloud.ibm.com/docs/account?topic=account-assign-access-resourcesreview-your-access-console).







 What's next? 

Now that you successfully created your first CIS service instance with Terraform on IBM Cloud, you can visit the [Cloud Internet Services (CIS) Terraform registry](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/cis) to perform additional tasks using Terraform.
Both setups offer the same level of availability for your app, but also add complexity when it comes to data sharing and data replication. For most cases, staying within the same geolocation is sufficient. But if you have users across the world, it might be better to set up a cluster where your users are so that your users don't experience long waiting times when they send a request to your app.





 What options do I have to load balance workloads across multiple clusters? 

To load balance workloads across multiple clusters, you must make your apps available on the public network by using [Application Load Balancers (ALBs)](https://cloud.ibm.com/docs/containers?topic=containers-managed-ingress-aboutmanaged-ingress-albs) or [Network Load Balancers (NLBs)](https://cloud.ibm.com/docs/containers?topic=containers-loadbalancer-about). The ALBs and NLBs are assigned a public IP address that you can use to access your apps.

To load balance workloads across your apps, add the public IP addresses of your ALBs and NLBs to a CIS global load balancer or your own global load balancer.





 Setting up a CIS global load balancer 



1. Set up [Kubernetes load balancer services](https://cloud.ibm.com/docs/containers?topic=containers-loadbalancer-qs) or the [Ingress service](https://cloud.ibm.com/docs/containers?topic=containers-managed-ingress-about) to expose the apps in your cluster.
2. Set up the CIS global load balancer by following steps 1 - 5 in [Getting Started with IBM Cloud Internet Services (CIS)](https://cloud.ibm.com/docs/cis?topic=cis-getting-startedgetting-started). These steps walk you through provisioning the service instance, adding your app domain, and configuring your name servers, and creating DNS records. Create a DNS record for each ALB or NLB IP address that you collected.
* [Multi-Zone Region (MZR) overview](https://cloud.ibm.com/docs/loadbalancer-service?topic=loadbalancer-service-multi-zone-region-mzr-overview)





 Commands 

Commands to pull the needed information:

The following command lists all the routes that are used to access your applications.

ibmcloud cf routes



The following command lists all the domains that are being used in those potential routes.

ibmcloud cf domains

If you use the IBM Cloud Internet Service for routing, or to check, install the CIS command plug-in using the following command.

ibmcloud plugin install cis

Then use commands in the [IBM Cloud Internet Service documentation](https://cloud.ibm.com/docs/cis?topic=cis-cli-plugin-cis-cli) to see what you are using in IBM Cloud Internet Service





 Output 

Capture the route and domain information and make sure that you know how each critical application is access from the internet.





 Migration steps 

You will need to ensure that you set up similar routes and domain access in your new compute environment.



* If you have a custom domain setup (such as xyzcompany.com) you might need to upload a certificate into IBM Cloud Secrets Manager to allow that custom domain to work and enable that properly with your application hosting service.
* If you use load balancing, be sure to make note of the load balancing information for the new compute environment.









 Services and service bindings 

You need to understand the services you are using that are bound to an application with permission to use that service.



* [Cloud Foundry application bindings](https://docs.cloudfoundry.org/devguide/services/application-binding.html)





 Commands 

The following command list the IBM Cloud services you have mapped to be used in your IBM® Cloud Foundry applications.

ibmcloud cf services

The following command lists any "customer user provided services" you might have set up.

ibmcloud cf cups





 Output 

These are provided in VCAP_APPLICATION and VCAP_SERVICES variable groups in Cloud Foundry, but different services do these different ways.





 Migration steps
Both setups offer the same level of availability for your app, but also add complexity when it comes to data sharing and data replication. For most cases, staying within the same geolocation is sufficient. But if you have users across the world, it might be better to set up a cluster where your users are so that your users don't experience long waiting times when they send a request to your app.





 What options do I have to load balance workloads across multiple clusters? 

To load balance workloads across multiple clusters, you must make your apps available on the public network by using [Ingress](https://cloud.ibm.com/docs/openshift?topic=openshift-ingress-about-roks4), [routers](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_routes), or [Network Load Balancers (NLBs)](https://cloud.ibm.com/docs/openshift?topic=openshift-loadbalancer-about). The router services and NLBs are assigned a public IP address that you can use to access your apps.

To load balance workloads across your apps, add the public IP addresses of your router services and NLBs to a CIS global load balancer or your own global load balancer.





 Setting up a CIS global load balancer 



1. Set up [Kubernetes load balancer services](https://cloud.ibm.com/docs/openshift?topic=openshift-loadbalancer-qs), [routes](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_routes), or the [Ingress service](https://cloud.ibm.com/docs/containers?topic=containers-managed-ingress-about) to expose the apps in your cluster.
2. Set up the CIS global load balancer by following steps 1 - 5 in [Getting Started with IBM Cloud Internet Services (CIS)](https://cloud.ibm.com/docs/cis?topic=cis-getting-startedgetting-started).
* [Let's Encrypt](https://letsencrypt.org/) to generate the TLS certificates.
* IBM Cloud Secrets Manager to integrate with Let's Encrypt to generate the TLS certificate for secure-file-storage.example.com and securely store.
* Kubernetes [External Secrets Operator](https://external-secrets.io/v0.7.0/) to pull the secret TLS certificate directly from Secrets Manager





 Provision a CIS and Secrets Manager instance 



* A [IBM Cloud Internet Services](https://cloud.ibm.com/catalog/services/internet-services) instance is required. Use an existing instance or create one from this [catalog entry](https://cloud.ibm.com/catalog/services/internet-services). A number of pricing plans are available, including a free trial. The provisioning process of a new CIS will explain how to configure your existing DNS registrar (perhaps not in IBM Cloud) to use the CIS-provided domain name servers. This tutorial uses example.com for the DNS name. Substitute your domain for example.com in all steps. Also export it in the shell:

export MYDOMAIN=example.com
* A Secrets Manager instance is required. Use an existing instance or create a new one described in [Creating a Secrets Manager service instance](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-create-instance&interface=ui). If creating a new instance, name it secure-file-storage-sm. You can enhance the security of your secrets at rest by integrating with the Key Protect instance created earlier.



Create a DNS entry in the CIS instance using YOUR-CLUSTER Ingress subdomain as the alias.



1. Open the CIS service instance, you can find it in the [Resource List](https://cloud.ibm.com/resources).
2. Click the Reliability tab on the left.
3. Click the DNS tab on the top.
4. Scroll down to the DNS Records section and click Add to create a new record:



1.
Plan Qiskit Runtime for an organization 

In an organization where individuals might work on several projects, Qiskit Runtime governance can seem complex. However, access management can be used to easily enable user collaboration and to restrict visibility of users and projects when necessary. Managing access becomes more relevant with Qiskit Runtime resources that are not free: that is, Qiskit Runtime service instances that use the Standard plan (which organizations are charged for).



 Overview 

IBM Cloud provides various ways to implement these mechanisms described in this tutorial. There are several ways to achieve these objectives. Additionally, most of the steps in this tutorial are generic to IBM Cloud and not specific to Qiskit Runtime, except the custom role details.



 Involved Personas 

The are several main personas that are mentioned in this tutorial:



* User: Someone who gets access to Qiskit Runtime resources (service instances) and can potentially collaborate with other users on these resources. Users' access is controlled by an administrator and they cannot create or delete service instances.
* Cloud administrator: An IBM Cloud account owner who owns Qiskit Runtime resources and manages which users can access these resources. As the resource owner, the administrator is charged for any paid resource use.
* IDP administrator: An administrator who defines identities and their attributes in an identity provider (IDP).







 Terminology 

This tutorial uses the following terms:



* Resource: A generic IBM Cloud term that refers to an object that can be managed through the Cloud user interface, CLI, or API. For this tutorial, a resource is a Qiskit Runtime service instance.
* Service instance: A service instance is used to access Cloud functions. Specifically, quantum computing on real devices or simulators. It is defined through the catalog. You can define several service instances based on the same or different plans, which offer access to different quantum computing backends. See [Qiskit Runtime plans](https://cloud.ibm.com/docs/quantum-computing?topic=quantum-computing-plans) for more details.
* Project: A grouping unit that enables users to work on the same resources. This tutorial uses two projects; ml and finance.
* Follow the [Terraform on IBM Cloud® getting started tutorial](https://cloud.ibm.com/docs/ibm-cloud-provider-for-terraform?topic=ibm-cloud-provider-for-terraform-getting-started) to install the Terraform CLI and configure the IBM Cloud® Provider plug-in for Terraform. The plug-in abstracts the IBM Cloud® APIs that are used to provision, update, or delete IBM Cloud Internet Services service instances and resources.
* Create a Terraform configuration file that is named main.tf. In this file, you add the configuration to create a CIS service instance and to assign a user an access policy in Identity and Access Management (IAM) for that instance by using HashiCorp Configuration Language (HCL). For more information, see the [Terraform documentation](https://www.terraform.io/docs/language/index.html).





1. Create a CIS instance by using the ibm_resource_instance resource argument in your main.tf file. The CIS instance in the following example is named test and is created with the standard pricing plan. The resource_group_id is data.ibm_resource_group.group.id, and the location property is set to global.

data "ibm_resource_group" "group" {
name = "test"
}

resource "ibm_cis" "cis_instance" {
name = "test"
plan = "standard"
resource_group_id = data.ibm_resource_group.group.id
tags = ["tag1", "tag2"]
location = "global"

//User can increase timeouts
timeouts {
create = "15m"
update = "15m"
delete = "15m"
}
}
Show more
2. After you finish building your configuration file, initialize the Terraform CLI. For more information, see [Initializing Working Directories](https://www.terraform.io/cli/init).

terraform init
3.
For non-default port numbers, refer to [FAQs](https://cloud.ibm.com/docs/CDN?topic=CDN-faqsare-there-any-restrictions-on-what-port-numbers-are-allowed) for a list of allowed port numbers.

An SSL certificate option appears if you select HTTPS port. You can choose Wildcard or DV SAN certificate as your SSL certificate option. Both offer the enhanced security provided by HTTPS.
* DV SAN certificate (default) allows HTTPS traffic over your domain, but requires additional steps to verify. See [Completing Domain Control Validation for HTTPS](https://cloud.ibm.com/docs/CDN?topic=CDN-completing-domain-control-validation-for-https-with-dv-san) to understand the steps that are required and time constraints that are involved with choosing this option.
* Wildcard certificate allows HTTPS traffic only when using the CNAME and requires no further action on your part.



6. Review pricing estimates in the right pane.
7. Agree to the terms of the Master Service Agreement.
8. Click the Create button to create your CDN.
9. Follow steps for your specific configuration in [Getting to Running status](https://cloud.ibm.com/docs/CDN?topic=CDN-next-steps-after-ordering).
Three methods exist that you can use to control caching in general, and Origin Cache Control is the second one.

Setting Origin Cache Control invokes caching rules that seek to adhere closely to internet best practices and RFCs, primarily with respect to revalidation. For example, the CIS default behavior with max-age=0 is not to cache at all, whereas setting Origin Cache Control caches, but it always revalidates.



 Setting up Origin Cache Control 

To enable Origin Cache Control, follow these steps:



1. Use the navigation menu to select Page Rules under Performance.
2. Create a page rule with the URL pattern that references your domain.
3. Add the Origin Cache Control setting with the toggle on.
4. Select Provision Resource.







 Page Rule precedence 

Two specific page rules take precedence for caching overall:



* If a page rule has Cache Level set to Bypass, the resources that match that page rule are not cached. CIS still acts as a proxy, and our other performance features remain active. However, your content is fetched from your origin server directly, instead of served from our cache.
* If a page rule has Cache Level set to Cache everything, resources that match the page rule are cached. Using this page rule setting is the only way to tell us to cache resources beyond what we consider static, including HTML.



If no page rule is set, we use the Standard caching mode, which is based the extension of the resource. We cache static resources only.







 Forwarding URL 

To ensure that your content is always available, create page rule with the Forwarding URL setting used, in case your site is unavailable.

When you enable a Forwarding URL, all of your other settings are disabled because you are sending all of your traffic to another URL.



 Setting up a forwarding URL 

To enable Forwarding URL, follow these steps:



1. Use the navigation menu to select Page Rules under Performance.
2. Create a page rule with the URL pattern that references your domain.
3. Add the Forwarding URL setting.
4. Select the forwarding type and enter the destination URL.
5.