vania-janet/multiturn-rag-retrieval-data huggingface dataset:
resource "local_file" "output" {
content = <<EOF
ACCOUNT_ID=${data.ibm_iam_account_settings.iam_account_settings.account_id}
REGION=${var.region}
EOF
filename = "../outputs/global.env"
}





 Individual Environments 

There are different approaches to manage multiple environments with Terraform. You could duplicate the Terraform files under separate directories, one directory per environment. With [Terraform modules](https://www.terraform.io/docs/modules/index.html), you could put together common configurations as a group and reuse modules across environments - reducing the code duplication. Separate directories mean you can modify the development environment to validate changes and then propagate the changes to other environments. It is common in this case to also have the Terraform modules in their own source code repository, so that you can reference a specific version of a module in your environment files.

Given the environments are rather simple and similar, you are going to use another Terraform concept called [workspaces](https://www.terraform.io/docs/state/workspaces.htmlwhen-to-use-multiple-workspaces). Workspaces allow you to use the same terraform files (.tf) with different environments. In the example, development, testing and production are workspaces. They will use the same Terraform definitions but with different configuration variables (different names, different capacities).

Each environment requires:



* a dedicated resource group
* a vpc and subnet
* a virtual server with floating IP address
* a database
* a file storage



To access information from the global configuration, you can utilize [Terraform remote state](https://www.terraform.io/docs/state/remote.html). It allows the reference of an existing Terraform state in read-only mode. This is a very useful construct to split your Terraform configuration in smaller pieces, leaving the responsibility of individual parts to different teams.
Resolving problems when using data from CSV files in Cognos Dashboard Embedded 

You import a data asset based on a comma-separated values (CSV) file that contains dates or times, however the visualization results in IBM® Cognos Dashboard Embedded are not what you expected.



 What's happening 

When you create a visualization in a dashboard that displays dates or that is filtered by dates, the results are not what you expect. For example, you have a data asset that contains one row of data for each month. However, a visualization displays only dates from January for each year. Or, you have data from one month, but the visualization displays dates for a year. The following image explains the situation.

![UnexpectedresultwhenusingdatesinCSVfile](https://cloud.ibm.com/docs-content/v1/content/2781097afe16f2d329d7a606ddd260fb1a3e355c/services/cognos-dashboard-embedded/images/csvfile_explained.svg)





 Why it's happening 

The problems that you see might be caused by the format of the dates in your data, if the source for your data was a CSV file. For example, you have the following dates:



* 1-1-2015
* 1-2-2015
* 1-3-2015
* 1-4-2015
* 1-5-2015
* 1-6-2015



When your data is imported, Cognos Dashboard Embedded tries to determine the appropriate format to use for dates. However, you might get unexpected results. The first number in each date might be interpreted either as January or as the day, leading to different results. The date 1-2-2015 is interpreted as either January 2 or February 1.

To determine whether the format of dates is the potential cause of the problem, open your original CSV data file and review the format of the dates.





 How to fix it 

If you have dates that represent a day, month, and year, change the format to be one that is supported by Cognos Dashboard Embedded.
* UI
* API







 Suspending your product from the IBM Cloud catalog 

If you need to remove a product from the IBM Cloud® catalog without permanently deleting or deprecating it, you can suspend it for up to 7 days. Suspending a product can be useful if, for example, you discover a bug or a vulnerability in your product that must be investigated before more customers install it.

Suspending your product will not permanently delete it from the IBM Cloud catalog. If you need to permanently delete your product, deprecate it instead.



 Suspending your product from the IBM Cloud catalog by using the console 

Complete the following steps to suspend your product:



1. In the IBM Cloud console, click the Navigation Menu icon ![Navigation Menu icon](https://cloud.ibm.com/docs-content/v1/content/ff5860bfede49db3197c4bbba7f7123769bdc068/icons/icon_hamburger.svg) > Partner Center > Sell > My products.
2. Click the Actions icon ![Actions icon](https://cloud.ibm.com/docs-content/v1/content/ff5860bfede49db3197c4bbba7f7123769bdc068/icons/actions-icon-vertical.svg) for the product that you want to suspend, and select Suspend.
3. Explain why you want to suspend your product.
4. Click Suspend.



After you suspend your product, you must request approval to publish it again within 7 days, or your product will be deprecated. Deprecated products are removed after 90 days. For more information, see [Publishing your software to the IBM Cloud catalog](https://cloud.ibm.com/docs/sell?topic=sell-sw-publish).

IBM Cloud can suspend your product if there's an issue that you need to address. Any updates that you need to make are shared by email.





 Suspending your product from the IBM Cloud catalog by using the API
Box 

Crawl documents that are stored in a Box data source.

IBM Cloud

IBM Cloud only

This information applies only to managed deployments. For more information about connecting to Box from an installed deployment, see [Box](https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-connector-box-cp4d).



 What documents are crawled 

During the initial crawl of the content, documents from all of the folders that can be accessed from your Box application are crawled and added to your collection. Box notes are stored in JSON format, so Discovery also ingests any Box notes in the specified folders.

The following table illustrates the objects that Discovery can crawl.



Table 1. Data sources crawling support

 Data source Supports scheduled document refreshes? Objects that are crawled 

 Box (App access) No Files, folders that you share explicitly 
 Box (Enterprise access) Yes (New and modified documents only) Files, folders 



When you configure Box with App access only, you must create App Users and share the files that you want to crawl with these users. You cannot crawl Box files that are shared only by the Service Account.

For more information about access, see these Box documentation help topics:



* [App Users](https://developer.box.com/guides/getting-started/user-types/app-users/)
* [Service Accounts](https://developer.box.com/guides/getting-started/user-types/service-account/)



Documents that are deleted from Box are not deleted from the collection.

All Discovery data source connectors are read-only. Regardless of the permissions that are granted to the crawl account, Discovery never writes, updates, or deletes any content in the original data source.





 Data source requirements 

In addition to the [data source requirements](https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-sourcespublic-requirements) for all managed deployments, your Box data source must meet the following requirement:

You must obtain any required service licenses for the data source that you want to connect to.
For a list of new features and bug fixes, see [What's new and changed in Watson Discovery](https://www.ibm.com/docs/SSQNUZ_4.6.x/fixlist/discovery-fixlist.html)

Manage the data in a collection from the new Manage data page
: You can now access a Manage data page for a collection. From the new page, you can see a list of the documents in your collection and get a quick view of information about the documents. You can also delete documents from a collection with just a few clicks. For more information, see [Excluding content from query results](https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-hide-data).

You have more control over the data that is crawled by the database connector
: When you connect to a database as an external data source, you can now specify the column from which to extract data. If you don't specify the column, a column with text or with a single large object is chosen to be crawled. You can also specify the MIME type of the data in the column that you want to crawl.

Features that are not available in this release
: The following features are generally available from managed IBM Cloud deployments at the time of this release, but not from installed deployments:



* Answer finding
* Optical Character Recognition v2







 4.6.4 release, 29 March 2023 

IBM Watson® Discovery Cartridge for IBM Cloud Pak® for Data was not refreshed as part of 4.6.4. You can use Discovery 4.6.3 with IBM Cloud Pak for Data 4.6.4 on Red Hat OpenShift Container Platform versions 4.10 or 4.12.





 4.6.3 release, 23 february 2023 

IBM Watson® Discovery Cartridge for IBM Cloud Pak® for Data 4.6.3 is available.

For a list of new features and bug fixes, see [What's new and changed in Watson Discovery](https://www.ibm.com/docs/SSQNUZ_4.6.x/fixlist/discovery-fixlist.html)

Features that are not available in this release
To fix either issue (resource failing due to authentication error or the timeout error), destroy the resources from the Schematics workspace and retry deploying the resources.





 Limitation of available profiles for dedicated hosts 

The offering automatically selects instance profiles for dedicated hosts to be the same prefix (for example, bx2 and cx2) as ones for worker instances (worker_node_instance_type). However, available instance prefixes can be limited, depending on your target region. If you use dedicated hosts, check ibmcloud target -r {region_name} and ibmcloud is dedicated-host-profiles to see whether your worker_node_instance_type has the available prefix for your target region.





 Why am I receiving an error with the provided ssh_key_name value? 

 What’s happening 

You are receiving the following error when you try to generate or apply a plan on Schematics workspace: failed due to "Error: No SSH Key found with name <KEY_NAME>".

 Why it’s happening 

Terraform could not find the given SSH key names that are provided by you.

 How to fix it 



1. Check whether the given SSH key is present in the current region where the cluster is being provisioned. If the given SSH key is not present, create the SSH key in the current region.
2. While configuring multiple SSH keys, ensure that there is no white space added before or after the SSH key names.
3. If you are using multiple SSH keys, check whether a comma (,) is used as a delimiter between the SSH keys and that there is no white space added before or after the SSH key.
* Set the password for the Informix user.
* Create a new operating system user.
* Configure Informix to authenticate through a PAM service.
* [Create a mapped user](http://www.ibm.com/support/knowledgecenter/SSGU8G_14.1.0/com.ibm.sec.doc/ids_am_037.htm).







 Connecting to your Informix on Cloud server 

You can use any application that can access the internet to connect to your IBM Informix on Cloud for IBM Cloud server. The application can be in your data center or be hosted in IBM Cloud. The Informix on Cloud server is configured with a self-signed SSL certificate, located on the machine at /home/informix/client_ssl/selfsigned_ssl.cert. By default the Informix on Cloud server accepts only SSL-enabled connections, so you must first configure a client for SSL.

The following steps explain how to configure a SQLI-based IBM Informix client driver for establishing an SSL connection with the server. All these steps are performed on the machine where the client runs.



1. Ensure that the IBM Informix Client Software Development Kit (CSDK) and GSKit are installed.
2. Identify a directory to create the client's keystore> For example: the /opt/ifx/mykeystores directory. Change to that directory.
3. Copy the SSL certificate from the Informix on Cloud server in the /home/informix/client_ssl/selfsigned_ssl.cert path to the local directory. You can do this by using the scp command.
4. Create a new keystore:

gsk8capicmd_64 -keydb -create -db mydbclient.kdb -pw MyPassword -type cms -stash

The above command creates a key database called mydbclient.kdb and a stash file called mydbclient.sth. The -stash option creates a stash file at the same path as the key database, with a file extension of .sth.
Are you getting an "access denied" error when trying to create a COS target? 

When creating an IBM Cloud Object Storage target using service-to-service authorization, the message Your request to test a target has failed because the target details are not valid. The service could not write to the Cloud Object Storage bucket that is configured. {'error_code':'403','error_message':'Access Denied'} is returned.

  What’s happening 

Your request fails with an error message that indicates access to the IBM Cloud Object Storage bucket was denied.

  Why it’s happening 

You define a bucket in an account but have not set up [service-to-service authorization](https://cloud.ibm.com/docs/atracker?topic=atracker-target_v2_cos&interface=clicos_s2s) to that bucket. Then you attempt to create an IBM Cloud Object Storage target pointing to the bucket using service-to-service authorization (--service-to-service-enabled TRUE), instead of using the [COS bucket API key.](https://cloud.ibm.com/docs/atracker?topic=atracker-target_v2_cos&interface=clicos_apikey).

  How to fix it 

Either setup [service-to-service authorization to the bucket](https://cloud.ibm.com/docs/atracker?topic=atracker-target_v2_cos&interface=clicos_s2s) and retry the target create request, or use the [COS bucket API key](https://cloud.ibm.com/docs/atracker?topic=atracker-target_v2_cos&interface=clicos_apikey) on the create request.
"moreInformation": "https://example.com",
"queueManagerLocation": "qm.us-south.mq.appdomain.cloud",
"queueManagers": [{
"hostname": "qm1-abcd.qm.us-south.mq.appdomain.cloud",
"name": "QM1"
}, {
"hostname": "qm2-abcd.qm.us-south.mq.appdomain.cloud",
"name": "QM2"
}],
"region": "us-south",
"serviceInstance": "crn:v1:staging:public:mqcloud:region:a/ab90cde12f345:ab5c678d-e90a-b5678c9::"
}
Show more

The notification will contain the following keys:



* datestamp: the date and time the notification was sent
* description: an explanation of the problem and what action was taken
* moreInformation: this may contain an external link to further explain the cause behind the DR
* queueManagerLocation: the location of the cluster on which the queue manager is deployed
* queueManagers: a list of hostnames and names of all affected queue managers
* region: the physical location of your service instance
* serviceInstance: the unique CRN of the containing service instance







 How to implement the endpoint handler 

The instructions below demonstrate some sample code to implement an endpoint handler to send notifications via PagerDuty in an IBM Cloud Function, but you could also adapt this code to run in a location of your choice

Note: the below function is written in Node.js

const https = require('https');

function main(params) {

return new Promise((resolve, reject) => {

// Replace the string "R4nd0m5tr1ng0fCh4r4ct3r5" with your own value to secure access to your own specific endpoint
Set the context for your cluster.](https://cloud.ibm.com/docs/containers?topic=containers-access_cluster).



1. Identify what user credentials are used for the region and resource group's infrastructure permissions.



1. Check the API key for a region and resource group of the cluster.

ibmcloud oc api-key info --cluster <cluster_name_or_ID>

Example output

Getting information about the API key owner for cluster <cluster_name>...
OK
Name Email
<user_name> <name@email.com>
2. Check if the classic infrastructure account for the region and resource group is manually set to use a different IBM Cloud infrastructure account.

ibmcloud oc credential get --region <us-south>

Example output if credentials are set to use a different classic account. In this case, the user's infrastructure credentials are used for the region and resource group that you targeted, even if a different user's credentials are stored in the API key that you retrieved in the previous step.

OK
Infrastructure credentials for user name <1234567_name@email.com> set for resource group <resource_group_name>.

Example output if credentials are not set to use a different classic account. In this case, the API key owner that you retrieved in the previous step has the infrastructure credentials that are used for the region and resource group.

FAILED
No credentials set for resource group <resource_group_name>.: The user credentials could not be found. (E0051)



2. Validate the infrastructure permissions that the user has.



1. List the suggested and required infrastructure permissions for the region and resource group.

ibmcloud oc infra-permissions get --region <region>

For console and CLI commands to assign these permissions, see [Classic infrastructure roles](https://cloud.ibm.com/docs/openshift?topic=openshift-classic-roles).
2.
No custom VPC routes are needed in IBM VPC custom routing table.



* Destination - 166.8.0.0/14 for IBM Cloud service endpoints, next hop: VPN tunnel interface
* Destination - 161.26.0.0/16 for IaaS endpoints, next hop: VPN tunnel interface







You can narrow the range of the destination CIDR instead of using 166.8.0.0/14 or 161.26.0.0/16. For example, if you need to access only IBM DNS IP 161.26.0.10 and 161.26.0.11, you could choose 161.26.0.10/30 as the destination instead of using 161.26.0.0/16.

For some on-premises VPN gateways, the next hop must be an IP address instead of a tunnel interface name. You should assign an IP address from a CIDR with a 30-bit mask to a tunnel interface on the on-premises VPN gateway, and use the another IP address in the same CIDR as the route's next hop. For example, you could assign 169.254.0.1/30 as the tunnel interface IP address on the on-premises VPN gateway, and use 169.254.0.2/30 as the route's next hop.
Expand the tutorial 



1. In this tutorial only two virtual servers are initially provisioned as the app tier, more servers could be added automatically to handle additional load. [Auto Scale](https://cloud.ibm.com/docs/virtual-servers?topic=virtual-servers-about-auto-scale) provides you with the ability to automate the manual scaling process associated with adding or removing virtual servers to support your business applications.
2. Separately protect user data by adding a second private VLAN and IP subnet to the VRA to create a DATA zone for hosting the MySQL database server. Configure firewall rules to only allow only MySQL IP traffic on port 3306 inbound from the APP zone to the DATA zone.
Microsoft SharePoint Online 

Crawl documents that are stored in a Microsoft SharePoint Online data source.

IBM Cloud

IBM Cloud only

This information applies only to managed deployments. For more information about connecting to SharePoint Online from an installed deployment, see [SharePoint Online](https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-connector-sharepoint-online-cp4d).



 What documents are crawled 

During the initial crawl of the content, documents from all of the objects that can be accessed from the site collection path that you specify are crawled and added to your collection. You cannot limit the crawl to one library within a site collection, for example. All objects in the specified Site collection path are crawled. Custom metadata that is associated with the SharePoint content is crawled also. You can crawl one site collection path per collection. You cannot crawl Personal SiteCollections.

During subsequent scheduled recrawls, only new and modified documents are crawled and any changes are reflected in your collection. Documents that are deleted from the external data source are not deleted from the collection.

All Discovery data source connectors are read-only. Regardless of the permissions that are granted to the crawl account, Discovery never writes, updates, or deletes any content in the original data source.

Discovery can crawl the following objects:



* SiteCollections
* Sites
* SubSites
* Lists
* List Items
* Document Libraries
* List Item Attachments







 Data source requirements 

In addition to the [data source requirements](https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-sourcespublic-requirements) for all managed deployments, your SharePoint Online data source must meet the following requirements:



* The Site Collection that you connect to must be one that was created with an Enterprise plan. It cannot be a collection that was created with a frontline worker plan.
* You must have an Azure Active Directory user ID with permission to read all of the objects that you want to crawl. For example, <admin_user>@.onmicrosoft.com. The user ID does not need SiteCollection Administrator permission.
Classic: Why can't I add worker nodes with an invalid VLAN ID? 

Classic infrastructure

 What’s happening 

Your IBM Cloud account was suspended, or all worker nodes in your cluster were deleted. After the account is reactivated, you can't add worker nodes when you try to resize or rebalance your worker pool. You see an error message similar to the following:

SoftLayerAPIError(SoftLayer_Exception_Public): Could not obtain network VLAN with id 123456.

 Why it’s happening 

When an account is suspended, the worker nodes within the account are deleted. If a cluster has no worker nodes, IBM Cloud infrastructure reclaims the associated public and private VLANs. However, the cluster worker pool still has the previous VLAN IDs in its metadata and uses these unavailable IDs when you rebalance or resize the pool. The nodes fail to create because the VLANs are no longer associated with the cluster.

 How to fix it 

You can [delete your existing worker pool](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_worker_pool_rm), then [create a new worker pool](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_worker_pool_create).

Alternatively, you can keep your existing worker pool by ordering new VLANs and using these to create new worker nodes in the pool.

Before you begin: [Log in to your account. If applicable, target the appropriate resource group. Set the context for your cluster.](https://cloud.ibm.com/docs/containers?topic=containers-access_cluster)



1. To get the zones that you need new VLAN IDs for, note the Location in the following command output. Note: If your cluster is a multizone, you need VLAN IDs for each zone.

ibmcloud ks cluster ls
2.