vania-janet/multiturn-rag-retrieval-data huggingface dataset:
[Copy normalization](https://cloud.ibm.com/docs-content/v1/content/ded4adc3ea0bd2a81b113c579f2b1183926da211/discovery/images/norm_copy.png)
* When you use the API, add the following object to the normalizations array:

{
"operation" : "copy",
"source_field" : "{original_field_name}",
"destination_field" : "customer_id"
}



3. The next scheduled crawl adds the customer_id field to all documents. To start a crawl immediately, modify the source configuration (Sync settings in the tooling).



See [Information security](https://cloud.ibm.com/docs/discovery?topic=discovery-information-security) for more information and information about deleting based on customer_id.







 Managing collections 

After you create a collection, you can view a crawler status or change the content that you want to crawl, your security credentials to connect to a data source, or a crawler schedule.

When you click Manage data, these tabs are available after collection processing finishes. The tabs contain data that is associated with your collection and options for managing it.

Overview tab:



* The number of documents
* The collection status. While syncing is in progress, the collection status states, Sync in progress. If you recrawl your collection when the sync is in progress, the current crawler stops, and a new full crawling session begins. Unless you want to make a change to your collection immediately, you might want to wait until syncing completes before starting a recrawl. When collection processing completes, you receive a status message that states, Your documents have finished processing! You can now work with your full data set..
* The Next sync scheduled for date and time. Your current crawl schedule settings determine the Next sync scheduled for, which updates if you change your crawl schedule in the Sync settings tab. Also, when your next scheduled crawl begins, the Next sync scheduled for automatically updates.
* A list of warnings and errors
Subscribing to cron events 

With this tutorial, you can learn how to subscribe to cron events by using the IBM Cloud® Code Engine CLI.

Oftentimes in distributed environments you want your applications or jobs to react to messages (events) that are generated from other components, which are usually called event producers. With Code Engine, your applications or jobs can receive events of interest by subscribing to event producers. Event information is received as POST HTTP requests for applications and as environment variables for jobs.

Before you begin



* [Set up your Code Engine CLI environment](https://cloud.ibm.com/docs/codeengine?topic=codeengine-install-cli).
* [Create and work with a project](https://cloud.ibm.com/docs/codeengine?topic=codeengine-manage-project).



All Code Engine users are required to have a Pay-as-you-Go account. Tutorials might incur costs. Use the Cost Estimator to generate a cost estimate based on your projected usage. For more information, see [Code Engine pricing](https://cloud.ibm.com/docs/codeengine?topic=codeengine-pricing).



 Step 1: Determine your cron interval 

The cron event producer generates events at regular intervals. This interval can be scheduled by minute, hour, day, or month or a combination of several different time intervals.

Cron uses a standard crontab to specify interval details, in the format * * * * , which stands for minute, hour, day of month, month, and day of week. For example, to schedule an event for midnight, specify 0 0 * * . To schedule an event for every Friday at midnight, specify 0 0 * * FRI.

For more information about crontab, see [CRONTAB](http://crontab.org/).

You can set your cron interval by using the --schedule option with the subscription cron command, as shown in Step 3. If you do not specify the --schedule option, then by default, the cron event is sent every minute of every day.
If you create multiple clusters in separate zones, you must [set up a global load balancer](https://cloud.ibm.com/docs/containers?topic=containers-ha_clustersmultiple-clusters-glb). When you use a replica set and specify pod anti-affinity, Kubernetes spreads your app pods across the nodes. If your nodes are in multiple zones, the pods are spread across the zones, increasing the availability of your app. If you want to limit your apps to run only in one zone, you can configure pod affinity, or create and label a worker pool in one zone. For more information, see [High availability for multizone clusters](https://cloud.ibm.com/docs/containers?topic=containers-ha_clustersha_clusters).

In a multizone cluster deployment, are my app pods distributed evenly across the nodes?
: The pods are evenly distributed across zones, but not always across nodes. For example, if you have a cluster with one node in each of three zones and deploy a replica set of six pods, then each node gets two pods. However, if you have a cluster with two nodes in each of three zones and deploy a replica set of six pods, each zone schedules two pods, and might schedule one pod per node or might not. For more control over scheduling, you can [set pod affinity](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/).

If a zone goes down, how are pods rescheduled onto the remaining nodes in the other zones?
: It depends on your scheduling policy that you used in the deployment. If you included [node-specific pod affinity](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/), your pods are not rescheduled. If you did not, pods are created on available worker nodes in other zones, but they might not be balanced. For example, the two pods might be spread across the two available nodes, or they might both be scheduled onto one node with available capacity. Similarly, when the unavailable zone returns, pods are not automatically deleted and rebalanced across nodes.
[menu icon](https://cloud.ibm.com/docs-content/v1/content/f02b9c9adcbb7328d95a45e105cec371d50f15eb/icons/icon_hamburger.svg) > VPC Infrastructure > Auto scale > Instance groups.
2. Select the instance group that you want to create a scheduled action for by clicking its name.
3. Click Scheduled actions.
4. In the new screen, click Create
5. Enter an appropriate name for the scheduled action.
6. Select One time, then select the start date and time for your scheduled action.
7. If your instance group is dynamic, enter a minimum and or maximum instance group size to apply when this action runs. If your instance group is static, enter the instance group size to apply when this action runs.
8. Click Create.







 Creating a recurring scheduled action 

To create a recurring scheduled action, use the following steps.



1. In the [IBM Cloud console](https://cloud.ibm.com/login), go to menu icon ![menu icon](https://cloud.ibm.com/docs-content/v1/content/f02b9c9adcbb7328d95a45e105cec371d50f15eb/icons/icon_hamburger.svg) > VPC Infrastructure > Auto scale > Instance groups.
2. Select the instance group that you want to create a scheduled action for by clicking its name.
3. Click Scheduled actions.
4. In the new screen, click Create
5. Enter an appropriate name for the scheduled action.
6. Click Recurring.
7. Select a date and time to run the scheduled action by using the predefined options for each pattern section (Monthly, Days, Hours, Minutes). Or choose a custom schedule by clicking what months, days, hours, and minutes that you want the schedule to run. \n Alternatively, you can select a date and time schedule by entering a cron expression.
To limit the VPN traffic to only workers dedicated to tenant A in this example, you specify the following toleration in the values.yaml file for the tenant A strongSwan Helm chart.

tolerations:
- key: dedicated
operator: "Equal"
value: "tenantA"
effect: "NoSchedule"

This toleration allows the route daemon set to run on the two worker nodes that have the dedicated="tenantA" taint and on the two untainted worker nodes. The strongSwan VPN pods for this deployment run on the two untainted worker nodes.
2. To limit the VPN traffic to only workers dedicated to tenant B in this example, you specify the following toleration in the values.yaml file for the tenant B strongSwan Helm chart.

tolerations:
- key: dedicated
operator: "Equal"
value: "tenantB"
effect: "NoSchedule"

This toleration allows the route daemon set to run on the two worker nodes that have the dedicated="tenantB" taint and on the two untainted worker nodes. The strongSwan VPN pods for this deployment also run on the two untainted worker nodes.









 Upgrading or disabling the strongSwan Helm chart 

Ensure that you consistently upgrade your strongSwan Helm chart for the latest features and security fixes.

Review the supported versions of the strongSwan Helm chart. Typically, a chart version becomes deprecated 6 months after its release date.



* Supported: 2.7.9, 2.7.8, 2.7.7, 2.7.6, 2.7.5, 2.7.4, 2.7.3, 2.7.2
* Deprecated: 2.7.1, 2.7.0, 2.6.9, 2.6.8, 2.6.7
* Unsupported: 2.6.6 and earlier



For release dates and change logs for each strongSwan Helm chart version, run helm show readme iks-charts/strongswan and look for the Version History section.
* To get started with Direct Link, see [Ordering IBM Cloud Direct Link Dedicated](https://cloud.ibm.com/docs/dl?topic=dl-how-to-order-ibm-cloud-dl-dedicated). In step 8, you can create a network connection to your VPC to be attached to the Direct Link gateway.



If you plan to connect your cluster to on-premises networks, check out the following helpful information:



* You might have subnet conflicts with the IBM-provided default 172.30.0.0/16 range for pods and 172.21.0.0/16 range for services. You can avoid subnet conflicts when you [create a cluster from the CLI](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clicli_cluster-create-vpc-gen2) by specifying a custom subnet CIDR for pods in the --pod-subnet option and a custom subnet CIDR for services in the --service-subnet option.
* If your VPN solution preserves the source IP addresses of requests, you can [create custom static routes](https://cloud.ibm.com/docs/containers?topic=containers-static-routes) to ensure that your worker nodes can route responses from your cluster back to your on-premises network.
* Note that the 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16, and 172.20.0.0/16 subnet ranges are prohibited because they are reserved for IBM Cloud Kubernetes Service control plane functionality.





 Communication with resources in other VPCs 

To connect an entire VPC to another VPC in your account, you can use the IBM Cloud VPC VPN or IBM Cloud® Transit Gateway.



* To get started with the IBM Cloud VPC VPN, follow the steps in [Connecting two VPCs using VPN](https://cloud.ibm.com/docs/vpc?topic=vpc-vpn-example) to create a VPC gateway on a subnet in each VPC and create a VPN connection between the two VPC gateways.
Separate multiple names with commas, and use asterisks () and question marks (?) as wildcard characters. Filters are applied when the backup job runs. New databases that match the specified filters are automatically backed up when the job runs.



For example, to back up databases with names that end with “Management” or include the word “database” followed by a single character, enter the following filter: management, database?.
9. To exclude databases from the backup job, do one or more of the following in the Select Databases for Backup box:



* To exclude specific databases from the backup job, select the checkbox for each database, and then click Exclude. The excluded databases appear in the Backup Set box with a minus sign.
* To exclude databases with names that match a filter when the backup job runs, select the checkbox for the SQL Server instance, and then click Exclude. A record with an asterisk () appears in the Backup Set box. In the Database Filter box, enter the names of databases to exclude. Separate multiple names with commas, and use asterisks () and question marks (?) as wildcard characters. For example, to exclude databases if their names begin with “M”, enter the following filter: m.



Filters are applied when the backup job runs. New databases that match the specified filters are automatically excluded when the backup job runs. Filters are not case-sensitive.
10. To remove an inclusion or exclusion record from the Backup Set box, click Delete next to the record.
11. Click Apply Now to consolidate and simplify records in the Backup Set box, if changes need to be applied.
12. Click Create Job. The job is now created, and the View/Add Schedule dialog box appears. Next, you can create a schedule for running the backup. Click Cancel if you don't want to create a schedule now.







 Scheduling the SQL backup job 

After you created a backup job, you can add one or more schedules for running the job automatically. You can create complex schedules for a job by creating multiple schedules.
Using a custom prompt for speech synthesis 

The Tune by Example feature is beta functionality that is supported only for US English custom models and voices.

To use a custom prompt in a speech synthesis request, you include the simple <ibm:prompt> element as the text of the request. This element is an IBM-specific extension to SSML. The element has one attribute, id, which is a string that identifies a predefined prompt:

<ibm:prompt id="{prompt_id}"/>

In addition to the [Rules for creating custom prompts](https://cloud.ibm.com/docs/text-to-speech?topic=text-to-speech-tbe-rulestbe-rules-prompts), the following restrictions apply to the use of a prompt in a speech synthesis request:



* Only a single prompt can be used in a synthesis request. You cannot include two prompts in the same request.
* A prompt must be the only thing that appears in a synthesis request. You cannot include additional text with the prompt.
* A prompt can include only fixed text, not variable data that can change for different uses of the prompt. For example, "Your account balance is $500" contains variable data: "$500." The account balance is variable data that changes depending on a specific user's account. The prompt needs to speak "Your account balance is," and a second synthesis request needs to say the balance.





 Examples of using a custom prompt 

The following examples show speech synthesis requests for the goodbye prompt that was created in [Creating a custom prompt](https://cloud.ibm.com/docs/text-to-speech?topic=text-to-speech-tbe-create). The examples use the en-US_AllisonV3Voice to speak the prompt and accept audio that is in the audio/ogg;codecs=opus audio format. You could use these same calls to evaluate the prompt before using it in a production application.

For the customization_id, substitute the GUID of the custom model that contains the prompt. Note that the speaker ID is specified only when you create a prompt, not when you include the prompt in a synthesis request.
12 - 24 months Workspace creation restricted No Suggested. Upgrade if Terraform fix needed. 
 24 months Workspace execution restricted No Needed 





 Terraform maintenance and fixes 

Schematics supports Terraform releases in line with [Terraform support and end-of-life policy](https://support.hashicorp.com/hc/en-us/articles/360021185113-Support-Period-and-End-of-Life-EOL-Policy). Schematics always supports at least one Terraform release with maintenance and security fix support.

After the end of Terraform maintenance and security fixes, Schematics maintains full operational support for 24 months from release GA. If an issue is identified in Terraform that requires a fix, the user is required to update to a release with current maintenance and security fixes.

After end of Terraform maintenance Schematics moves to supporting operations with the final point (fix pack) Terraform release.

The deprecation and use of each Terraform version in Schematics follows the following phases.





 Restrict workspace creation 

After 12 months from GA, users cannot create new Schematics workspaces with this release. Existing workspaces and resources by using the release can continue to be managed by using the release. It is suggested to update to the current supported Terraform release.

During this time Schematics supports only operations with the final point (fix pack) Terraform release.





 Restrict workspace execution 

After 24 months from GA, users no longer be able to manage IBM Cloud resources with IBM Cloud Schematics workspaces by using this release. The workspace must first be updated to use a release of Terraform with HCL provided maintenance and security fixes. The content of the workspaces remains accessible and the Terraform release can be updated in Schematics to re-enable operations.

If you choose not to upgrade to the current version of Terraform beyond the restrict workspace execution date:



* Your Schematics workspace data continues to stay in Schematics until you delete these workspaces.
* You cannot do operations on, or destroy the IBM Cloud resources by using Schematics. The resources can still be deleted through the IBM Cloud console or CLI.
As shown in [Creating root keys in the console](https://cloud.ibm.com/docs/key-protect?topic=key-protect-create-root-keyscreate-root-key-gui), to create a key, navigate to the Keys page in your instance and click Add to open the key creation side panel. Then, open the Advanced options tab to reveal the Key alias, Key ring, and Rotation policy options.

If you do not see the Rotation policy option, check your level of permissions to ensure you are a Manager.

If an instance-level rotation policy exists, the rotation policy button shows as Enabled. The rotation interval enabled on the instance (in months) is visible. If this rotation interval is appropriate for this key, not other action needs to be taken other than to click Create to create the key. If you want to change the rotation interval, click Edit and set the interval you want. Then click Save. Then you can click Create to create the key.







 Set a rotation policy after the key has been created 



1. [Log in to the IBM Cloud console](https://cloud.ibm.com/login/).
2. Go to Menu > Resource List to view a list of your resources.
3. From your IBM Cloud resource list, select your provisioned instance of Key Protect.
4. On the application details page, use the Keys table to browse the keys in your service. If you have many keys, you can narrow your search by using the search bars to only search for enabled keys (since other kinds of keys cannot be rotated), keys in a particular key ring, and keys with a particular alias.
5. Once the key has been found, click the ⋯ icon to open a list of options for the key that you want to rotate.
6. From the options menu, click Rotate to open the Rotation side panel.
7. If your rotation policy is Enabled, you can edit this policy by changing the number of months selected. This will set the 30-day interval for your root key.
If you have many keys, you can narrow your search by using the search bars to only search for enabled keys (since other kinds of keys cannot be rotated), keys in a particular key ring, and keys with a particular alias.
5. Once the key has been found, click the ⋯ icon to open a list of options for the key that you want to rotate.
6. From the options menu, click Rotate to open the Rotation side panel.
7. Under Manage rotation policy, select the 30-day intervals for key rotation you want. If a key is set to be rotated every 2 months, for example, it will be rotated every 60 days, regardless of the number of days in a particular month.
8. Click Set policy to establish this policy. If you want to rotate the key immediately, click Rotate key. Note: these actions are not mutually exclusive.



For imported root keys only, you must add base64 encoded key material that you want to store and manage in the service. Ensure that the key material is in 128, 192, or 256 bits and that the bytes of data (for example, 32 bytes for 256 bits) are encoded by using base64 encoding.





 Rotating root keys with the API 

You can rotate a root key by making a POST call to the following endpoint.

https://<region>.kms.cloud.ibm.com/api/v2/keys/<keyID_or_alias>/actions/rotate



1. [Retrieve authentication credentials to work with keys in the service.](https://cloud.ibm.com/docs/key-protect?topic=key-protect-set-up-api)
2. Copy the ID of the root key that you want to rotate.

You can find the ID for a key in your Key Protect instance by [retrieving a list of your keys](https://cloud.ibm.com/docs/key-protect?topic=key-protect-view-keys), or by accessing the Key Protect dashboard.
3. Replace the key with new key material by running the following curl command.
Troubleshooting Block Storage for VPC 

When you create or manage Block Storage for VPC, you might encounter issues. Often, you can recover by following a few steps. Issues, symptoms, likely causes, and resolutions are described in the following sections.



 Cannot retrieve a volume in a specified region 

 What’s happening 

Information about a block storage volume or volumes can't be retrieved for a region.

 Why it’s happening 

Any of the following causes might apply:



* The volume name and information is missing in either the UI or CLI.
* You might also be attempting to access a volume in a region other than your region.
* You might be trying to access an obsolete volume that was created on a deprecated VPC infrastructure.



 How to fix it 

Verify that the volume wasn't detached from a virtual server instance and deleted. Search for the instance to which you last attached the volume from the list of all virtual server instances:



1. In the [IBM Cloud console)](https://cloud.ibm.com/login), go to menu icon ![menu icon](https://cloud.ibm.com/docs-content/v1/content/icons/icon_hamburger.svg) > VPC Infrastructure > Compute > Virtual server instances.
2. Select a virtual server instance from the list of all virtual servers.



If the volume is not attached as expected and does not appear in the list of volumes, it was probably deleted. Because deleting a volume completely removes its data, it cannot be restored.

If you use the CLI, verify that you entered the correct command syntax for viewing volumes. See [View all block storage volumes from the CLI](https://cloud.ibm.com/docs/vpc?topic=vpc-viewing-block-storage-cli). Verify that you specified the correct resource group or zone.





 Cannot update a volume name by using the API or CLI 

 What’s happening 

You receive an error message when you attempt to rename an existing volume.

This condition might appear in the API or CLI in the following scenarios.
You can avoid subnet conflicts when you [create a cluster from the CLI](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clicli_cluster-create-vpc-gen2) by specifying a custom subnet CIDR for pods in the --pod-subnet option and a custom subnet CIDR for services in the --service-subnet option.
* If your VPN solution preserves the source IP addresses of requests, you can [create custom static routes](https://cloud.ibm.com/docs/openshift?topic=openshift-static-routes) to ensure that your worker nodes can route responses from your cluster back to your on-premises network.
* Note that the 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16, and 172.20.0.0/16 subnet ranges are prohibited because they are reserved for Red Hat OpenShift on IBM Cloud control plane functionality.





 Communication with resources in other VPCs 

To connect an entire VPC to another VPC in your account, you can use the IBM Cloud VPC VPN or IBM Cloud® Transit Gateway.



* To get started with the IBM Cloud VPC VPN, follow the steps in [Connecting two VPCs using VPN](https://cloud.ibm.com/docs/vpc?topic=vpc-vpn-example) to create a VPC gateway on a subnet in each VPC and create a VPN connection between the two VPC gateways. Note that if you use [access control lists (ACLs)](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-network-policy) for your VPC subnets, you must create inbound or outbound rules to allow your worker nodes to communicate with the subnets in other VPCs.
* To get started with IBM Cloud Transit Gateway, see the [Transit Gateway documentation](https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-getting-started).