vania-janet/multiturn-rag-retrieval-data huggingface dataset:
export REDIS_CR_NAME=oc get redissentinels.redis.databases.cloud.ibm.com -l icpdsupport/addOnId=assistant -n ${PROJECT_CPD_INSTANCE} | grep -v NAME| awk '{print $1}'
3. Delete the Redis custom resource:

oc delete redissentinels.redis.databases.cloud.ibm.com ${REDIS_CR_NAME} -n ${PROJECT_CPD_INSTANCE}

It might take approximately 5 minutes for the custom resource to be re-created.
4. Verify that Redis is running:

oc get redissentinels.redis.databases.cloud.ibm.com -n ${PROJECT_CPD_INSTANCE}
5. Export the name of your Watson Assistant instance as an environment variable:

export INSTANCE=oc get wa -n ${PROJECT_CPD_INSTANCE} |grep -v NAME| awk '{print $1}'
6. Delete the Redis analytics secret:

oc delete secrets ${INSTANCE}-analytics-redis
7. Delete the ${INSTANCE}-analytics deployment pods.









 4.0.x 



 Data Governor error causing deployment failure 

The following fix applies to Watson Assistant 4.0.0 through 4.0.8. In some cases, Watson Assistant deployment is stuck and pods are not coming up because of an issue with the interaction between the Events operator and the Data Governor custom resource (CR).

Complete the following steps to determine whether you are impacted by this issue and, if necessary, apply the patch to resolve it:



1. To determine whether you are impacted, run the following command to see whether the CR was applied successfully:

oc get dataexhaust wa-data-governor -n $OPERAND_NS -o yaml

If you do not receive any error, then you do not need to apply the patch. If you receive an error similar to the following example, complete the next step to apply the patch:
4. Use the list menu to select Resolve Override with COS under the Performance section.
5. Use the Cloud Object Storage Instance list to select the instance you want.
6. Use the Bucket list to select the bucket you want.
7. Click Create to complete the rule.







 Editing a page rule 

After editing the page rule, the Resolve Override with COS is no longer displayed on the page. However, the Resolve Override<bucket>.<domain> and Host Header Override<bucket>.<cos-endpoint> replace Resolve Override with COS.

Making changes to the Resolve Override does not automatically create a new CNAME record (for example, <updated-bucket>.<domain>). This is only done upon the initial creation of a page rule using Resolve Override with COS. To automatically create the CNAME record for the bucket follow the [Create page rule](https://cloud.ibm.com/docs/cis?topic=cis-resolve-override-coscos-create-page-rule) steps.





 Deleting the page rule 

If the Resolve Override with COS page rule is no longer needed, the CNAME should be manually deleted along with the page rule.





 What happens in the background 

When creating a Resolve Override with COS page rule, CIS automatically creates the other necessary resources for the COS integration. These include:



* CNAME



* A CNAME DNS record for <bucket-name>.<cos-endpoint> as <bucket-name>.
* For example, if your CIS domain is foo.com, you have a COS bucket called images and your public COS endpoint is s3.us-west.objectstorage.uat.test.net then CIS creates a CNAME as images.foo.com that points to images.s3.us-west.objectstorage.uat.test.net.



If the Resolve Override with COS page rule is no longer needed the CNAME should be manually deleted along with the page rule.
* Host Header Override
When an IBM Cloud region becomes unavailable, the apps that are running in that region are also unavailable, even if the same apps are running in another IBM Cloud region.

 Why it’s happening 

IBM Cloud doesn't yet provide automatic failover from one region to another.

 How to fix it 

You can use a DNS provider that supports intelligent failover among many ID addresses, and manually configure your DNS settings to enable the automatic failover between IBM Cloud regions. DNS providers with this feature include NSONE, Akamai, and Dyn.

When you configure your DNS settings, you must specify the public IP addresses of the IBM Cloud regions that your apps are running in. To get the public IP address of an IBM Cloud region, use the nslookup command. For example, you can type the following command in a command line window.

nslookup cloud.ibm.com





 Can't reuse names of deleted apps 

After you delete an app, you can reuse the app name only after you delete the app route.

 What’s happening 

When you try to reuse the app name, you receive the following message:

The name is already used by another app.

 Why it’s happening 

When an app is deleted, its route, which is the URL for the app, isn't automatically deleted and it's not available for reuse. You must go to the space where the app was created to delete the route so that it can be reused.

 How to fix it 

Complete the following steps to delete the unused route:



1. Check whether the route belongs to the current space by entering the following command:

ibmcloud cf routes
2. If the route doesn't belong to the current space, switch to the space or org that it belongs to by entering the following command:

ibmcloud cf target -o org_name -s space_name
3. Delete the app route by entering the following command:

ibmcloud cf delete-route domain_name -n host_name

For example:

ibmcloud cf delete-route cf.cloud.ibm.com -n app001
--name value: Job name. Required.--enable value: Enable the job or not. The job is disabled by default.--fields value: Define the list of log fields to be included in log files. Multiple fields can be separated by commas and use command [ibmcloud cis logpush-available-fields DNS_DOMAIN_ID to get the comprehensive list of available log fields, or use all to include all available fields in log files. Note that fields are expected to be case sensitive.--timestamps value: Set the format in which response timestamps are returned. Valid values: unix, unixnano, rfc3339.--dataset value: The category of logs you want to receive. This value cannot be changed after the job is created. Valid values: http_requests, range_events, firewall_events. The default value is http_requests.--frequency value: The frequency at which CIS sends batches of logs to your destination. Setting frequency to high sends your logs in larger quantities of smaller files. Setting frequency to low sends logs in smaller quantities of larger files. Valid values: high, low.-i , --instance value: Instance name or ID. If not set, the context instance specified by ibmcloud cis instance-set INSTANCE is used.--output: Specify output format, only JSON is supported.<-- </section "id="section-command-options-logpush-job-create" "> --><-- <section "id="section-command-example-logpush-job-create" "> --> Examples Create a log push job for domain 31984fea73a15b45779fa0df4ef62f9b.
Log in to IBM Cloud by using the [IBM Cloud CLI](https://cloud.ibm.com/docs/cli?topic=cli-install-ibmcloud-cli).

ibmcloud login

If the login fails, run the ibmcloud login --sso command to try again. The --sso parameter is required when you log in with a federated ID. If you use this option, go to the link that is listed in the CLI output to generate a one-time passcode.
2. Optional. List all of the Continuous Delivery service instances in the targeted account to identify the instance that you want to delete.

ibmcloud resource service-instances --all-resource-groups --service-name continuous-delivery
3. Delete a service instance by running the [ibmcloud resource service-instance-delete](https://cloud.ibm.com/docs/cli?topic=cli-ibmcloud_commands_resourceibmcloud_resource_service_instance_delete) command.

ibmcloud resource service-instance-delete SERVICE_NAME_OR_ID



The following table lists and describes each of the variables that are used in the previous steps.



Table 1. Variables for deleting the Continuous Delivery service from the CLI

 Variable Description 

 SERVICE_NAME_OR_ID The name or ID of the Continuous Delivery service instance that you want to delete. 







 Deleting a Continuous Delivery service instance with the API 



1. [Obtain an IAM bearer token](https://cloud.ibm.com/apidocs/resource-controllerauthentication). Alternatively, if you are using an SDK, [obtain an IAM API key](https://cloud.ibm.com/iam/apikeys) and set the client options by using environment variables.

export RESOURCE_CONTROLLER_APIKEY={iam_api_key}
2. Delete the instance of the Continuous Delivery service instance that you want to remove.



* Curl
* Java
* Node
* Python
* Go
* Max per-partition throughput: The maximum MB/s that can be mirrored within a single partition. Select the number of partitions that are configured for the source topics to ensure the per partition load remains within this limit.



Exceeding the limits results in an increasing time lag between the data in the source and target instances. Having a large data lag can result in significant data loss. The monitoring dashboards can be used to determine the latency for each topic. For more information, see [Monitoring mirroring](https://cloud.ibm.com/docs/EventStreams?topic=EventStreams-mirroringmonitoring_mirroring).





 Deleting redundant target topics 

To avoid accidental deletion of data in the target instance, topics are not automatically deleted from the target instance when they are deleted from the source. It is the user's responsibility to delete the topics on the target instance. If mirrored topics are frequently deleted and created, more disk and partition allowance can be consumed in the target cluster. The usage can be monitored with the monitoring dashboard in the target cluster, see [Monitoring Event Streams metrics](https://cloud.ibm.com/docs/EventStreams?topic=EventStreams-metrics). You can delete topics that are no longer required by using the UI or admin interfaces.







 IAM access policies for mirroring 

Because applications need access to the source and destination clusters, IAM access policies must be set up on both clusters, and use the API key from the service ID that the policies are attached to. We can use the IAM wildcarding features [Assigning access by using wildcard policies](https://cloud.ibm.com/docs/account?topic=account-wildcard) to simplify the access policies that control access to the mirrored resources.

If you are new to IAM access policies, see [What is IBM Cloud Identity and Access Management?](https://cloud.ibm.com/docs/account?topic=account-iamoverview) and [Managing access to your Event Streams resources](https://cloud.ibm.com/docs/EventStreams?topic=EventStreams-security) for more details.
Deleting an agent using the CLI 

You can delete an agent or uninstall an agent from the Kubernetes cluster by using an [agent delete](https://cloud.ibm.com/docs/schematics?topic=schematics-schematics-cli-reference&interface=clischematics-agent-delete) command. This command requires an AGENT_ID as input argument.

Example

ibmcloud schematics agent delete --id agent-testing-prod-cli-mar-27-5.deA.dc97

Output

Do you really want to delete the agent agent-testing-prod-cli-mar-27-5.deA.dc97? [y/N]> y
Deleting Agent...
Agent agent-testing-prod-cli-mar-27-5.deA.dc97 deleted successfully
OK

When the agent is deleted, you can expect:



* All the agent microservices are uninstalled.
* All the agent related Kubernetes resources, such as Pods, Deployment, Configmap, and Namespaces are destroyed.
* All the credentials that are created as part of the agent deployment, such as HMAC credentials for the Object Storage bucket, trusted profile to communicate with Schematics are destroyed.
* All the information about the agent in the Schematics instance, of your IBM Cloud account are deleted.



When the agent is deleted, the following will not happen:



* The Kubernetes cluster will not be destroyed. The cluster will continue to incur cost until it is deleted.
* The Object Storage instance and the Object Storage bucket will not be destroyed.
* The agent assignment policy for the agent is not deleted.







 Deleting an agent using the API 

Follow the [steps](https://cloud.ibm.com/docs/schematics?topic=schematics-setup-apics_api) to retrieve your IAM access token and authenticate with IBM Cloud Schematics by using the API.

Example
Switch to the disk that you want to partition by using the command select. Replace XXX with your new device name.

select /dev/mapper/XXX
2. Run print to confirm that you are on the right disk.

print
3. Create a GPT partition table.

mklabel gpt
4. Parted can be used to create primary and logical disk partitions, the steps that are involved are the same. To create a partition, parted uses mkpart. You can give it other parameters like primary or logical depending on the partition type that you want to create.

mkpart

The listed units default to megabytes (MB). To create a 10-GB partition, you start from 1 and end at 10000. You can also change the sizing units to terabytes by entering unit TB if you want to.
5. Exit parted with quit.

quit



3. Create a file system on the new partition.

mkfs.ext3 /dev/mapper/XXXp1

It's important to select the right disk and partition when you run this command. Verify the result by printing the partition table. Under file system column, you can see ext3.
4. Create a mount point for the file system and mount it.



* Create a partition name PerfDisk or where you want to mount the file system.



mkdir /PerfDisk



* Mount the storage with the partition name.



mount /dev/mapper/XXXp1 /PerfDisk



* Check that you see your new file system listed.



df -h
5. Add the new file system to the system's /etc/fstab file to enable automatic mounting on boot.



* Append the following line to the end of /etc/fstab (by using the partition name from Step 3).



/dev/mapper/XXXp1 /PerfDisk ext3 defaults,_netdev 0 1
If you are using HPCS, create an IAM service authorization for your KMIP for VMware instance to your HPCS instance. Grant your KMIP for VMware instance both Platform Viewer access and Service VMware KMIP Manager access to your HPCS instance.
7. Configure your KMIP for VMware instance to connect to your Key Protect or HPCS instance and select which CRK to use with KMIP.
8. Within vCenter Server, create a key provider cluster.



1. If you are using Key Protect, configure this cluster with two servers, one for each KMIP for VMware endpoint in your chosen region.
2. If you are using HPCS, configure this cluster to connect to the hostname and port that is uniquely assigned to your KMIP for VMware instance.



9. Select one of VMware methods to generate or install a KMS client certificate in vCenter Server.
10. Export the public version of the certificate and configure it as an allowed client certificate in your KMIP for VMware instance. The key manager instance has a maximum interval of 5 minutes to get the configured client certificates. Therefore, if you are unable to build KMS trust to vCenter Server, wait for 5 minutes and try again.







 Enabling encryption 

To use vSAN encryption, edit the vSAN general settings in your vCenter Server cluster and select the encryption checkbox.

The vSAN health check might send periodic warnings that it is unable to connect to the KMS cluster from one or more of your vSphere hosts. These warnings occur because the vSAN health check connection times out too quickly. You can ignore these warnings. For more information, see [vSAN KMS Health Check intermittently fails with SSL handshake timeout error](https://kb.vmware.com/s/article/67115).

To use vSphere encryption, edit your VM storage policies to require disk encryption.





 Important caveats 

Some VMs require special planning for encryption, especially if they are involved in a possible circular dependency to obtain the key material to operate themselves. Consider the following information:
Provision an instance of [CIS](https://cloud.ibm.com/catalog/services/internet-services) that uses the Enterprise Usage plan.
2. Click Create to provision the service.







 Step 2: Configure CIS TLS Mode 



1. [Register your domain name with CIS](https://cloud.ibm.com/docs/cis?topic=cis-multi-domain-support).
2. Go to Security > TLS set the TLS encryption mode to [End-to-end flexible](https://cloud.ibm.com/docs/cis?topic=cis-cis-tls-optionstls-encryption-modes-end-to-end-flexible). End-to-End CA signed must not be used because it causes the TLS connection to be terminated in CIS.







 Step 3: Configure CIS Global Load Balancer 

When a global load balancer is created in CIS, it is automatically assigned the fully qualified domain name (FQDN) of <global load balancer name>.<domain>. This hostname is registered in public DNS. However, this hostname should not be used for the application because it lacks DDoS protection. Use he hostname that is assigned to the Range application in the next step for the application.



1. Go to Reliability > Global load balancers.
2. Click Create.
3. Set Enable to On.
4. Set Proxy to Off. You must do this to avoid terminating the TLS connection in CIS.
5. Enter a Name for the load balancer. This name is not used externally, but is referenced by the Range application.
6. Set values for TTL and Traffic steering that are appropriate for your application.
7. Click Create.
8. Configure an [origin pool](https://cloud.ibm.com/docs/cis?topic=cis-glb-features-pools) for the new load balancer that contains the BIG-IP endpoints.
9.
Deploying a custom image within a Power Systems Virtual Server 

You can bring your own customized AIX or IBM i operating system (OS) image to deploy within a IBM® Power Systems™ Virtual Server.

You cannot transfer an OS license from an on-premises system to a Power Systems Virtual Server. The license cost is factored into the overall hourly billing rate.

The basic steps that are involved in deploying an instance by using a custom image are:



1. Create the custom image.
2. Store the image in your Cloud Object Storage account.
3. Point the Power Systems Virtual Server console to the image in the Cloud Object Storage and deploy the Virtual Server instance.





 Before you begin 

Before you can use a custom image as the boot volume, review the following information:



* You must have a basic understanding of [IBM Cloud Object Storage](https://cloud.ibm.com/docs/services/cloud-object-storage?topic=cloud-object-storage-about-cloud-object-storage) concepts.
* If you do not have an existing AIX or IBM i image, you can use IBM® PowerVC™ to capture and export an image for use with a Power Systems Virtual Server. For more information, see [Capturing a virtual machine](https://www.ibm.com/docs/en/powervc/2.0.1?topic=images-capturing-virtual-machine) and [Exporting images](https://www.ibm.com/docs/en/powervc/2.0.2?topic=init-installing-configuring-cloud-linux). To capture and export an image by using IBM PowerVC, the PowerVC private environment must contain N_Port ID Virtualization (NPIV) data volumes. The Power Systems Virtual Servers does not support captured images from environment with shared Storage Pools (SSP) vSCSI data volumes.
* Alternatively, if you have already deployed a virtual server instance, you can capture it and redeploy a new virtual server instance. To accomplish this, you can use the [IBM Cloud® CLI](https://cloud.ibm.com/docs/cli?topic=cli-getting-started) to capture a virtual server instance.
Archiving logs to IBM Cloud Object Storage 

You can archive logs from an IBM® Log Analysis instance into a bucket in an IBM Cloud Object Storage (COS) instance.

Data is available for search and analysis for the number of days that your service instance plan indicates. However, you might need to access the data longer for troubleshooting. You might also have to keep the data for longer for compliance, and for corporate or industry regulations. When you need access to data for longer than the number of search days, you must configure archiving.

Archiving is not enabled by default.

You can have 1 or more Log Analysis instances per region. Each IBM Log Analysis instance has its own archiving configuration.

The following figure shows a high-level view of the different components that are involved when archiving logs:

Zoom

![High-level view of archiving logs](https://cloud.ibm.com/docs-content/v1/content/f61dbc5d84bf0c89e477a05cab04c72f429e1b7a/log-analysis/images/Log-Analysis-07-Archiving-Events.svg)

Figure 1. High-level view of archiving logs

The IBM Cloud Object Storage instance is provisioned within the context of a resource group. The IBM Log Analysis instance is also provisioned within the context of a resource group. Both instances can be grouped under the same resource group or in different ones.

IBM Log Analysis uses a service ID to communicate with the IBM Cloud Object Storage service.



* The service ID that you create for an IBM Cloud Object Storage instance is used by IBM Log Analysis to authenticate and access the IBM Cloud Object Storage instance.
* You can assign specific access policies to the service ID that restrict permissions on the IBM Cloud Object Storage instance. Restrict the service ID to only have writing permissions on the bucket where you plan to archive the logs.
* You can also restrict the IP addresses that are allowed to manage the bucket.



You are responsible for configuring and managing the bucket and the data stored in it.
Click the Actions icon ![More Actions icon](https://cloud.ibm.com/docs-content/v1/content/f02b9c9adcbb7328d95a45e105cec371d50f15eb/icons/action-menu-icon.svg) for the membership that you want to delete and select Delete.







 Disabling and enabling auto scale 

If you are using the dynamic method for auto scale, you can temporarily disable dynamic auto scaling for an instance group. You might choose to pause the dynamic scaling method to perform maintenance on an instance group, to save money at the end of a billing cycle, or to create all new instances that use a new instance template. When auto scale is disabled, instances are not automatically added or removed. (You still can manually adjust the membership count of your instance group.)



* In the Scaling method section of the Instance group details page, you can use the Auto scale slider to change from green Enabled to Disabled.
* When auto scale is Disabled, you can change it to Enabled.





 Pausing auto scale to apply a new instance template 

You can temporarily disable dynamic auto scaling for an instance group to create all new instances with a new instance template. Complete the following steps to remove existing instances in the group and create new instances with a new instance template:



1. When the dynamic auto scale scaling method is enabled, move the slider in the Scaling method section from Enabled to change it to Disabled.
2. With Auto scale set to Disabled, change your Membership count for the instance group to 0. All of your existing instances in the group are removed.
3. For the Instance template field, use the pencil icon to edit and select a new instance template to use for creating instances in the instance group.
4. Change the Membership count for the instance group to the number of instances you'd like to provision with the new instance template. For example, you can specify a membership count of 5.
5. When you are ready to start using the dynamic scaling method again, move the slider in the Scaling method section from Disabled to change it to Enabled. The instance group creates 5 new instances that use the new instance template.