vania-janet/multiturn-rag-retrieval-data huggingface dataset:
* UI
* CLI
* API







 Allowlisting 

Cloud Databases now supports context-based restrictions, which give account owners and administrators the ability to define and enforce access restrictions for IBM Cloud® resources based on the context of access requests. Access to Cloud Databases resources can be controlled with context-based restrictions and identity and access management (IAM) policies. Context-based restrictions check that an access request comes from an allowed context that you configure. Since both IAM access and context-based restrictions enforce access, context-based restrictions offer protection even in the face of compromised or mismanaged credentials. For more information, see [Protecting Cloud Databases resources with context-based restrictions](https://cloud.ibm.com/docs/cloud-databases?topic=cloud-databases-cbr).

To restrict access to your databases, allowlist specific IP addresses or ranges of IP addresses on your deployment.

If you use allowlists in your environment, allowlist our services by using the list of subnets for each region.

While IBM values the use of inclusive language, terms that are outside of IBM's direct influence are sometimes required for the sake of maintaining user understanding. As other industry leaders join IBM in embracing the use of inclusive language, IBM continues to update terminology to reflect those changes. We updated documentation to reflect changes in terminology from whitelist to allowlist. You might encounter continued references to this former terminology while we work to implement these deeper changes to code, API, and CLI commands.



 Using IP allowlists on your Deployment 

When you create an allowlist, only IP addresses that match the allowlist or are in the range of IP addresses in the allowlist can connect to your deployment. Allowlists can be enabled for both public endpoints and private endpoints. When no IP addresses are in the allowlist, the allowlist is disabled and the deployment accepts connections from any IP address.

Each deployment is limited to 100 allowlist entries.

Even if not explicitly allowlisted, IBM Cloud management services are still able to connect.



 Setting an allowlist in the UI 

The UI for managing allowlists is on the Settings tab of your Deployment Overview.



 IP addresses 

The IP field can take a single complete IPv4 address with or without a netmask.
hyperp-dbaas-postgresql.cluster.create Create a database cluster 
 hyperp-dbaas-postgresql.cluster.delete Delete a database cluster 
 hyperp-dbaas-postgresql.log.get Download a log file 
 hyperp-dbaas-postgresql.logging.enable Enable logging for the cluster 
 hyperp-dbaas-postgresql.monitoring.enable Enable monitoring for the cluster 
 hyperp-dbaas-postgresql.cluster.resource.scale Scale cluster resources 
 hyperp-dbaas-postgresql.configuration.update Update PosgreSQL configuration settings 
 hyperp-dbaas-postgresql.database.restore Restore databases by SRE as delegated by service instance owner 
 hyperp-dbaas-postgresql.backups.cos.enable Enable backups to IBM Cloud Object Storage 
 hyperp-dbaas-postgresql.backups.cos.disable Disable Backups to IBM Cloud Object Storage 
 hyperp-dbaas-postgresql.backups.restore Restore databases from backup 
 hyperp-dbaas-postgresql.database.backup.cos Back up databases to IBM Cloud Object Storage 



For the events of hyperp-dbaas-postgresql.cluster.create and hyperp-dbaas-postgresql.cluster.delete, the Activity Tracker service doesn't record the account name and IP address of the user who performs the action. The values of initiator.name and host.address in the log indicate the service ID of Cloud Broker and the IP address of Cloud Broker.
Conflicts 

In distributed databases, copies of data might be stored in more than one location. The natural network and system characteristics of the network might mean that changes made to a document stored in one location can't instantly update or replicate to other parts of the database.

In other words, independent updates can be made to different copies of documents. The effect of these updates might be to introduce disagreement or "conflicts" as to what is the correct, definitive content for the document.

IBM® Cloudant® for IBM Cloud® tries to help you avoid conflicts by warning you of potential problems. It warns you by returning a [409 response](https://cloud.ibm.com/apidocs/cloudantlist-of-http-codes) to a problematic update request. However, a 409 response might not be received if the database update is requested on a system that isn't currently connected to the network. For example, the database might be on a mobile device that is temporarily disconnected from the Internet, which makes it impossible to check whether other potentially conflicting updates were made.

If you request a document that is in a conflict situation, IBM Cloudant returns the document as expected. However, an internal algorithm considers a number of factors before it determines which document version to return. You must not assume that the returned document is the most recent version.

For example, if you don't check for conflicts, or fail to address them, your IBM Cloudant database can exhibit the following behaviors:



* Increasing inconsistencies in document content because more conflicting documents occur.
* Increasing database size because all conflicting documents must be kept until the conflict is resolved.
* Decreasing performance because IBM Cloudant must work harder in response to each request as it tries to identify the "best possible" version of a conflicted document.



The following suggested practices might help you decide when to check for, and resolve, conflicts:



Table 1. Suggested practices

 Application characteristic Frequency of document update Check for conflicts at retrieval? Check for conflicts at update? 

 Always connected to the network, for example, a server. Often Y <br><br> * <br><br><br> 
 Always connected to the network. Occasionally <br><br> * <br><br><br> Y
To ensure that the rebuild happens, a 'fingerprint' of the view definition is created whenever the design document is updated. If the fingerprint changes, then the view indexes are rebuilt.

View index rebuilds occur when you change any one view from all the views that are defined in the design document. For example, if you have a design document with three views, and you update the design document, all three view indexes within the design document are rebuilt. If you want to change a design document for a larger database, have a look at the [Design document management guide](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-design-document-managementmanaging-changes-to-a-design-document).

If the database was updated recently, the results might be delayed when the view is accessed. The delay is affected by the number of changes to the database, and whether the view index isn't current because the database content was modified.

It isn't possible to eliminate these delays. For newly created databases, you might reduce the delays by creating the view definition in the design document in your database before you insert or update documents. Creating the view definition in the design document causes incremental updates to the index when the documents are inserted.

If speed of response is more important than having up-to-date data, an alternative is to allow users to access an old version of the view index. To allow access to an old version of the view index, use the update query string parameter when you make a view query.

If you want to save old index versions without incurring indexing processor usage, you can stop all indexes from building by setting "autoupdate": {"indexes": false}. Or you can stop views from auto-updating by adding one of the following options to a design document. You can stop all index types from indexing if you set "autoupdate": false.

See the following examples:

{
"_id": "_design/lookup",
"autoupdate": false,
"views": {
"view": {
"map": "function(doc)..."
}
}
}
(https://cloud.ibm.com/docs/openshift?topic=openshift-faqssecure_cluster)
* [What access policies do I give my cluster users?](https://cloud.ibm.com/docs/openshift?topic=openshift-faqsfaq_access)
* [Where can I find a list of security bulletins that affect my cluster?](https://cloud.ibm.com/docs/openshift?topic=openshift-faqsfaq_security_bulletins)
* [Does the service offer support for bare metal and GPU?](https://cloud.ibm.com/docs/openshift?topic=openshift-faqsbare_metal_gpu)
* [What is the smallest size cluster that I can make?](https://cloud.ibm.com/docs/openshift?topic=openshift-faqssmallest_cluster)
* [Which Red Hat OpenShift versions does the service support?](https://cloud.ibm.com/docs/openshift?topic=openshift-faqssupported_kube_versions)
* [Which worker node operating systems does the service support?](https://cloud.ibm.com/docs/openshift?topic=openshift-faqssupported_os_versions)
* [Where is the service available?](https://cloud.ibm.com/docs/openshift?topic=openshift-faqssupported_regions)
* [Is the service highly available?](https://cloud.ibm.com/docs/openshift?topic=openshift-faqsha_sla)
* [What compliance standards does the service meet?](https://cloud.ibm.com/docs/openshift?topic=openshift-faqsstandards)
* [Can I use IBM Cloud and other services with my cluster?]
The following tutorials offer an overview of the capabilities of API Connect:



* [Creating an API](https://cloud.ibm.com/docs/apiconnect/tutorials?topic=apiconnect-tut_create_api_node)
* [Managing an API](https://cloud.ibm.com/docs/apiconnect/tutorials?topic=apiconnect-tut_rest_landing)
* [Discovering APIs](https://cloud.ibm.com/docs/apiconnect/tutorials?topic=apiconnect-tut_discover_apis)
* [Configuring a Developer Portal](https://cloud.ibm.com/docs/apiconnect/tutorials?topic=apiconnect-tut_config_dev_portal)







 About your personal data 

The API Connect service processes but doesn't store user data. You don't need to take any action to manage or delete your data.
Catalog Restricting available services in an account by utilizing [private catalogs and restricting the public catalog](https://cloud.ibm.com/docs/account?topic=account-filter-account) 
 Databases 
 IBM Cloudant [Data replication across accounts](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-replication-guidehow-to-run-replication-across-different-ibm-cloudant-accounts) 
 Cloud Databases [Restore backups across accounts](https://cloud.ibm.com/docs/cloud-databases?topic=cloud-databases-dashboard-backups) 



You can find code examples on how to set up resource sharing for some of these service in the GitHub repository [cross-account-resource-sharing](https://github.com/IBM-Cloud/cross-account-resource-sharing).





 Related resources 

The following document provides details on some cross-account scenarios:



* [IBM Cloud API keys for a user may have a scope across multiple accounts](https://cloud.ibm.com/docs/account?topic=account-manapikeyibm-cloud-api-keys)



Blog posts related to sharing resource across multiple accounts:



* [Terraform multi-account setup for IBM Cloud](https://blog.4loeser.net/2022/09/terraform-setup-multi-account-ibm-cloud.html)
* [Tips and Tricks for Using the IBM Cloud CLI](https://www.ibm.com/cloud/blog/tips-and-tricks-for-using-the-ibm-cloud-cli) discusses [IBMCLOUD_HOME](https://cloud.ibm.com/docs/cli?topic=cli-ibmcloud_env_varIBMCLOUD_PATH_TO_DIR) which can be used to work with multiple accounts from the CLI.
* UI
* CLI
* API







 s390x instance profiles 

You can use s390x instance profiles to provision virtual server instances and you can select from three families of profiles: Balanced, Compute, and Memory. IBM Z or LinuxONE (s390x processor architecture) is a uniquely secure and scalable architecture that provides dedicated CPU core, memory, and I/O channel to better manage your high-performance workloads.

A profile is a combination of instance attributes, such as the number of vCPUs, amount of RAM, network bandwidth, and default bandwidth allocation. The attributes define the size and capabilities of the virtual server instance that is provisioned. In the IBM Cloud console, you can select the most recently used profile or click View All Profiles to choose the profile that best fits your needs.

The secure execution profiles that become available when you enable confidential computing and select IBM Hyper Protect as the operating system for your virtual instance, can be identified by the fourth character of the profile name which is an "e", such as bz2e.

For information about profiles for x86 processor architecture, see [x86 instance profiles](https://cloud.ibm.com/docs/vpc?topic=vpc-profiles). For more information about confidential computing, see [Confidential computing with LinuxONE](https://cloud.ibm.com/docs/vpc?topic=vpc-about-se).

The following profile families are available:



Table 1. Virtual server family selections

 Families Description 

 [Balanced](https://cloud.ibm.com/docs/vpc?topic=vpc-vs-profilesvs-balanced) Balanced profiles offer a core to RAM ratio 1 vCPU to 4 GiB of RAM ratio and are best for midsize databases and common cloud applications with moderate traffic. 
 [Compute](https://cloud.ibm.com/docs/vpc?topic=vpc-vs-profilesvs-compute) Compute profiles offer a core to RAM ratio 1 vCPU to 2 GiB of RAM ratio and are best for moderate to high web traffic workloads.
This field includes the following values:



Table 1. Values for the options.partitioned field

 Value Description Notes 

 true Create the index as partitioned. Can be used only in a partitioned database. 
 false Create the index as global. Can be used in any database. 



The default follows the partitioned setting for the database:



Table 2. Partition settings

 Database is partitioned? Default partitioned value Allowed values 

 Yes true true, false 
 No false false 









 Copying a design document 

You can copy the latest version of a design document to a new document by specifying the base document and target document. The copy is requested by using the COPY request method.

COPY is a nonstandard HTTP command.

The following example requests that IBM Cloudant copy the design document allusers to the new design document copyOfAllusers, and produces a response that includes the ID and revision of the new document.

Copying a design document doesn't automatically reconstruct the view indexes. Like other views, these views are re-created the first time that you access the new view.

See the following example command to copy a design document by using HTTP:

COPY $SERVICE_URL/$DATABASE/_design/$DDOC HTTP/1.1
Content-Type: application/json
Destination: _design/$COPY_OF_DDOC

See the following example command to copy a design document:

The IBM Cloudant SDKs currently do not support the HTTP COPY method.

curl "$SERVICE_URL/users/_design/allusers" 	-X COPY 	-H "Content-Type: application/json" 	-H "Destination: _design/copyOfAllusers"

See the following example response to the copy request:

{
"ok": true,
"id": "_design/copyOfAllusers",
"rev": "1-9c65296036141e575d32ba9c034dd3ee"
}



 The structure of the copy command 

Method
: COPY /$DATABASE/_design/$DDOC

Request
: None.
From the navigation pane, open the Manage collections page, and then click a collection to open it.
2. Click the Manage data tab.

A list of information from each document in the collection is displayed. If the information that is displayed doesn't help you identify the document that you want to delete, you can change what is displayed.



* Click the Settings icon in the table header.
* Choose fields from which you want to fetch data to display in the first and second columns. You can choose fields such as extracted_metadata.filename to show the document file name, or document_id, for example.



You can page through the documents in the collection by using the controls in the table footer.
3. After you identify the document that you want to delete, select the checkbox that is associated with the document, and then click Delete. Confirm the deletion.

Documents that are added to a collection from an external data source will be added back to the collection with the next scheduled crawl of the data source. The delete function removes the document from the index of the collection, not from the external data source.

Some file types, such as CSV or JSON files, generate subdocuments when they are added to a collection. Splitting a document turns one document into multiple document segments. If you delete one of these generated documents, and then repeat the action that created it, the deleted document is added back in to your collection.



IBM Cloud Pak for Data

IBM Cloud Pak for Data releases before 4.6.5

The Manage data page is not available in installed deployments before the 4.6.5 release. You must use the [Discovery API](https://cloud.ibm.com/apidocs/discovery-datadeletedocument) to delete a document. And you must know the document ID of the document that you want to delete. To get the document ID, use the [List documents](https://cloud.ibm.com/apidocs/discovery-datalistdocuments) API method.
This state occurs because of the [eventual consistency](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-cap-theorem) model used by IBM Cloudant. Using the default R value helps mitigate this effect.

The default value for R is 2. This value corresponds to most of the replicas for a typical database that uses three shard replicas. If the database has multiple replicas that are greater than or less than 3, the default value for R changes correspondingly.





 What is W? 

W can be specified on single document write requests only.

W is similar to R because it affects how many responses must be received by the coordinator before it replies to the client.

W does not affect the actual write behavior in any way.

The value of W does not affect whether the document is written within the database or not. By specifying a W value, the client can inspect the HTTP status code in the response to determine whether W replicas responded to the coordinator. The coordinator waits until a pre-determined timeout for W responses from nodes that host copies of the document before it returns the response to the client.
Excluding content from query results 

Prevent content that you don't want customers to see from being included in query results.

You can prevent content from being included in query results in the following ways:



* Delete an entire collection.

For more information, see [Deleting collections](https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-manage-collectionscollection-delete).
* Remove a field from the index that contains data that you don't want to share with customers.

You can control which fields are indexed. If you want to prevent a field from being indexed, you can set it to be excluded. For example, if your PDF files contain a running header or footer that does not contain useful information, you can exclude the header and footer fields from the index.

To manage the fields to index, complete the following steps:



1. From the navigation pane, open the Manage collections page, and then click a collection to open it.
2. Click the Manage fields tab.

A list of the identified fields is displayed. You can see which fields are included in the index and which are not.
3. To remove a field from the index, set the Include switch to off.



* Delete a single document.

If you use the Smart Document Understanding tool to annotate a document, and then decide that you want to delete the document and its associated SDU annotations, you must remove the annotations before you delete the document. To remove the annotations, annotate the document again. This time, label all of the content as text.

To delete a document, complete the following steps:



1. From the navigation pane, open the Manage collections page, and then click a collection to open it.
2. Click the Manage data tab.

A list of information from each document in the collection is displayed. If the information that is displayed doesn't help you identify the document that you want to delete, you can change what is displayed.



* Click the Settings icon in the table header.
* Choose fields from which you want to fetch data to display in the first and second columns.
Hyper Protect Crypto Services Integration 

The data that you store in IBM Cloud® Databases is encrypted by default by using randomly generated keys. If you need to control the encryption keys, you can Bring Your Own Key (BYOK) through [Hyper Protect Crypto Services](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-get-started), and use one of your own keys to encrypt your databases. Take note that Hyper Protect Crypto Services for IBM Cloud® Databases backups is not currently supported.

This document covers the integration of Hyper Protect Crypto Services (HPCS) with Db2 on Cloud

To get started, you need [Hyper Protect Crypto Services](https://cloud.ibm.com/catalog/services/hyper-protect-crypto-services) provisioned on your IBM Cloud account.



 Creating or adding a key in Hyper Protect Crypto Services 

Navigate to your instance of Hyper Protect Crypto Services and [generate or enter a key](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-get-started).





 Granting service authorization 

Authorize Hyper Protect Crypto Services for use with Cloud Databases deployments:



1. Open your IBM Cloud dashboard.
2. From the menu bar, click Manage > Access (IAM).
3. In the side navigation, click Authorizations.
4. Click Create.
5. In the Source service menu, select Db2.
6. In the Source service instance menu, select All instances.
7. In the Target service menu, select HPCS.
8. Select or retain the default value Account as the resource group for the Target Service
9. In the Target service Instance ID menu, select the service instances to authorize.
10. Enable the Reader role.
11. Click Authorize.



If the service authorization is not present before provisioning your deployment with a key, the provision fails.





 Using the HPCS Key
* The construction of an index happens asynchronously. IBM Cloudant confirms that the design document was saved. To check on the progress of the construction of the index, you must poll IBM Cloudant's [_active_tasks](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-active-tasksactive-tasks) endpoint.
* The more data that you have, the longer it takes before the index is ready.
* While the initial index build is in progress, any queries made against the index are blocked.
* Querying a view triggers the 'mapping' of any documents that aren't incrementally indexed. This practice ensures that you get an up-to-date view of the data. See the following [stale parameter](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-design-document-managementthe-stale-parameter) discussion for exceptions to this rule.





 Multiple views in the same design document 

If you define several views in the same design document, then they're built efficiently at the same time. Each document is read only once, and passed through each view's Map function. If you use this approach, keep in mind that modifying a design document invalidates all of the existing MapReduce views that are defined in the document. This process invalidates MapReduce views even if some of the views stay unaltered.

If MapReduce views must be altered independently of each other, place their definitions in separate design documents.

This behavior doesn't apply to Lucene search indexes. They can be altered within the same design document without invalidating other unchanged indexes in the same document.

Zoom

![A database is created with 1000 documents. A design document is added which triggers the building of 2 views and 2 search indexes. The view builds asynchronously until it is complete. The arrival of a second version of the design document invalidates all MapReduce views and any changed search indexes in the document.]