vania-janet/multiturn-rag-retrieval-data huggingface dataset:
: This build introduces a new feature, [partition query](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-database-partitioningdatabase-partitioning).

limit
: Allow limit when you use POST for search.

View requests
: Previously, view requests that use a limit parameter greater than 268435456 would have the limit that is silently reduced to 268435456. Now, requests with the limit parameter greater than 268435456 are rejected with a 400 Bad Request error.





 1 January 2019 

The following changes were made in build 7631:

Improvements
: Internal changes and bug fixes.







 December 2018 



 1 December 2018 

The following changes were made in build 7544:

Replicator statistics
: Fixed a problem where the replicator would sometimes reset statistics during replications. The reset would affect values in the [replication status information](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-advanced-replicationadvanced-replication). See [PR](https://github.com/apache/couchdb/pull/1722).

IBM Cloudant Query and _find request
: Fixed an issue with IBM Cloudant Query. After you delete a document, if you issue a _find request to a text index with update=false, it might return a 500 response. See [PR](https://github.com/apache/couchdb/pull/1709).

_bulk_get
: You can now use multipart/mixed and multipart/related when you use _bulk_get. See [PR](https://github.com/apache/couchdb/pull/1195).

_design_docs handler
: Fix a bug with total row count in the _design_docs handler. See [PR](https://github.com/apache/couchdb/pull/1744).

Replication filters
: Optimizations to the _doc_id and _design_docs replication filters.
This file size limit does not apply for the allowed image files.
* The folder name starts with a (period) . is treated as vulnerable.



The allowed extension list is continuously monitored and updated in every release. You can raise a [support ticket](https://cloud.ibm.com/docs/schematics?topic=schematics-schematics-help) with the justification to add a file extension to the list.





 How do I save files between operations? 

it keeps whatever files you write to this path /tmp/.schematics and restores to the same path when you run your next activity.





 How do I update the Terraform version 

IBM Cloud Schematics deprecates older version of Terraform. For more information, see [Deprecating older version of Terraform process in IBM Cloud Schematics](https://cloud.ibm.com/docs/schematics?topic=schematics-deprecate-tf-version).

You can follow the topics to upgrade from one Terraform version to another version



* [Upgrading the Terraform template version](https://cloud.ibm.com/docs/schematics?topic=schematics-migrating-terraform-version)
* [Updating the Workspace Terraform 1.x version](https://cloud.ibm.com/docs/schematics?topic=schematics-migrating-terraform-versionterraform-version-upgrade1x-process)
* [Upgrade Terraform template from v0.13 and higher to v1.0](https://cloud.ibm.com/docs/schematics?topic=schematics-migrating-terraform-versionupgrade-13-to10)
* [Upgrading a Terraform v0.12 Workspace to v0.13 ](https://cloud.ibm.com/docs/schematics?topic=schematics-migrating-terraform-versionmigrate-steps12)







 Why are jobs waiting to be run placed in a queue? 

IBM Cloud Schematics queues all the users jobs into a single queue.
Verify that your application can handle a 429: too many requests HTTP response.



The following table provides more information about these HTTP responses:



Table 1. HTTP responses

 HTTP response Issue 

 429: too many requests Retrying requests that get a 429 response is acceptable for occasional traffic spikes that exceed your plan's capacity. If your application traffic is routinely generating 429 responses, you probably need to upgrade to a larger plan. 
 413: request entity too large The maximum individual document size is 1 MB on IBM Cloudant. You receive a 413 message if the limit is exceeded. For more information, see [request and document size limits](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-ibm-cloud-publicrequest-and-document-size-limits). 







 Step 4: Migrate data from the old service to the new service 



1. Set up continuous replications from your existing service to your IBM Cloudant account.

For more information, see the [Replication guide](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-replication-api) and [Using IBM Cloudant](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-ibm-cloudant-basics) about how to set up and monitor replication tasks.
2. Alternatively, use the [couchreplicate](https://www.npmjs.com/package/couchreplicate) tool to coordinate the transfer of data from one IBM Cloudant account to another.

The couchreplicate tool sets up multiple replication jobs between the source and target accounts, ensuring that only so many replication jobs proceed at one time. If you need to migrate hundreds of databases, then couchreplicate can help coordinate the replication jobs.

Your browser does not support the video tag.
3. Verify that all your data replicates to the new service and that indexes are built.







 Step 5: Test your application 



1. Conduct load and functional testing on your application.
2. Ensure that no issues exist before you migrate to production.







 Step 6: Move to the new instance 



1.
If you use the most recent versions of the [client libraries](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-client-libraries) that IBM Cloudant supports, you can set up your applications to handle 429 responses. This step is important because most client libraries don't automatically attempt to retry a request when a 429 response occurs. You need to verify that your application handles 429 responses correctly because IBM Cloudant limits the number of retries. Regularly exceeding the number of requests indicates that you need to move to a different plan.



* How is provisioned throughput capacity calculated?

IBM Cloudant calculates provisioned throughput capacity by totaling the usage for each request class per second, where 1 second is a sliding window. When an account exceeds the total number of a request class that is allotted by its plan, IBM Cloudant rejects subsequent requests of that request class. No new requests are accepted until the usage of that request class inside the sliding window falls under the allowed limit. The sliding 1-second window is any consecutive period of 1,000 milliseconds.

For example, the Standard plan instance limits you to 200 reads per second. When you exceed 200 read requests, IBM Cloudant rejects future read requests made during the sliding 1,000-millisecond window. Read requests resume when the number of read requests for that time period is less than 200.

Request class units do not necessarily have a one-to-one mapping with HTTP requests. A single HTTP request can consume multiple units of a request class or classes if, for example, it reads multiple documents or both reads and writes.
* What happens when I exceed the provisioned throughput capacity limit?

When you exceed the number of allowed events, IBM Cloudant generates a [429 Too Many Requests](https://cloud.ibm.com/apidocs/cloudantlist-of-http-codes) response. You must make sure ahead of time that your applications can handle 429 responses.

If you use the most recent versions of the [client libraries](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-client-libraries) that IBM Cloudant supports, you can set up your applications to handle 429 responses.
System details and limits 

The following sections provide technical details about the IBM Cloud® Functions system and limit settings.



 Action limits 

Cloud Functions has a few system limits, including how much memory an action can use and how many action invocations are allowed per minute.

The following table lists the default limits for actions.



Table 1. Default limits for actions

 Limit Description Default Min Max 

 codeSize The maximum code size for an action is 48 MB. You can use [custom Docker images](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-prepprep_docker) as a workaround for large dependencies; however, the maximum code size for your action is still 48 MB. For JavaScript actions, use a tool to concatenate all source code, which includes dependencies, into a single bundled file. This limit is fixed and cannot be changed. Note that binary code is base64 encoded, which increases the size by approximately 33%. In this case, the actual limit is reduced to 36 MB. 48 1 48 
 concurrent The number of activations that are either executing or queued for execution for a namespace cannot exceed 1000. This limit value is fixed, but can be increased if a business case can justify higher safety limit values. See [Increasing fixed limits](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-limitslimits_fixed) for instructions on how to increase this limit. 1000 1 1000 
 logs The log limit N is in the range [0 MB..10 MB] and is set per action. A user can change the action log limit when an action is created or updated. Logs that exceed the set limit are truncated, so any new log entries are ignored, and a warning is added as the last output of the activation to indicate that the activation exceeded the set log limit. 10 0 10 
 memory The memory limit M is in the range from [128 MB..2048 MB] and is set per action in MB. A user can change the memory limit when an action is created. A container cannot use more memory than is allocated by the limit. 256 128 2048
Enter a larger file share size, based on the maximum allowed for the [file share profile](https://cloud.ibm.com/docs/vpc?topic=vpc-file-storage-profiles). The default is the current size + 1 GB.
6. Review the estimated monthly order summary for your geography and new pricing.
7. If you're satisfied, click Save and continue.



Your new file storage allocation is available in a few minutes. If your requirements change, you can increase capacity again after the file share size is increased and when it's in stable state.

Note: You can't change the file share to a smaller size after you expand its capacity.





 Expand file shares from the CLI 

From the CLI, use the share-update command with the --size option to indicate the new size of the file share in GBs.

ibmcloud is share-update SHARE_ID --size SIZE_GB

This example expands the capacity of a file share that is created from a 5 IOPS/GB tier profile to the maximum size for that profile. To get the maximum IOPS of 48,000, you would need to restart the instance.

$ ibmcloud is share-update 933c8781-f7f5-4a8f-8a2d-3bfc711788ee --size 9600
Updating share 933c8781-f7f5-4a8f-8a2d-3bfc711788ee under account MyAccount 01 as user user1@mycompany.com...

ID 0738-933c8781-f7f5-4a8f-8a2d-3bfc711788ee
Name demo-share-update
CRN crn:v1:staging:public:is:us-south-3:a/c16d1edde3fd4a71a0130aed371405a0::share:0738-933c8781-f7f5-4a8f-8a2d-3bfc711788ee
r014-dee9736d-08ee-4992-ba8d-3b64a4f0baac demo-volume-update

Status attached
Bandwidth(Mbps) 393
Type data
Device 0757-6757e676-0bf5-4b79-9a5b-29c24e17420c-bxsh7
Auto delete true
Created 2023-06-29T18:14:57+00:00

For more information about available command options, see [ibmcloud is instance-volume-attachment](https://cloud.ibm.com/docs/cli?topic=cli-vpc-referenceinstance-volume-attachment).





 List all volume attachments of a server instance 

Use the instance-volume-attachments command and specify the instance ID or name to see all volume attachments for an instance.

ibmcloud is instance-volume-attachments INSTANCE [--json]

See the following example.

ibmcloud is instance-volume-attachments kj-test-ro
Listing volume attachments of instance kj-test-ro under account Test Account as user test.user@ibm.com...
ID Name Volume Status Type Device Auto delete
0757-6757e676-0bf5-4b79-9a5b-29c24e17420c otp1 demo-volume-update attached data 0757-6757e676-0bf5-4b79-9a5b-29c24e17420c-bxsh7 true
0757-af470ade-9d5c-491e-97b2-f000ed4ee49b scheming-tipper-shivering-decrease kj-test-ro-boot-1629867631000 attached boot 0757-af470ade-9d5c-491e-97b2-f000ed4ee49b-fc4tl true
The data storage that is measured for billable purposes for an IBM Cloudant instance is inclusive of both JSON data, indexes, and attachments.



 Data storage included 

This value is the storage capacity that is included in the plan. The Lite plan has a hard limit of 1 GB allowed. The paid Standard plan includes 20 GB for free and any additional data that is stored is metered for billing.





 Data overage 

All Lite and Standard plans are monitored for disk space used. When you use more data than the plan allocates, you can expect the conditions that are described in the following sections to apply:



 Lite plan 



* Disk usage is capped on the Lite plan at 1 GB.
* After you reach the cap, you receive a warning on the IBM Cloudant Dashboard and can't write new data. If you try to write new data, a 402: payment required response occurs.
* To write new data, you must either upgrade to the Standard plan or delete data, and wait until the next check runs for your account to be reactivated.







 Standard plan 



* If the account uses more than the 20 GB of storage that is included in the Standard plan, the excess is considered "disk overage". Overage causes the account to be billed at the indicated price for each extra GB used beyond the plan allocation.
* The cost for the amount of disk overage is calculated on an hourly basis.



For example, assume your Standard plan increases disk usage to 107 GB for half a day (12 hours). This change means that your instance caused overflow of 87 GB more than the 20 GB plan allocation, for 12 hours. As the result, you're billed an overage charge based on 87 GB x 12 hours = 1044 GB hours for that extra space.

Overage is calculated by using the maximum number of GB more than the plan allocation during a particular hour within the billing cycle.







 Disk overage example 

Assume that you start a month of 30 days with a Standard plan service instance that uses 9 GB of storage. Next, your storage increases to 21.5 GB for 15 minutes during the hour beginning at 02:00 of day 3.
For more information about the arguments and attributes, see [ibm_storage_file](https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/storage_file).

By default, you can provision a combined total of 700 File Storage for Classic volumes. To increase the number of your volumes, contact your sales representative. Read about increasing limits [here](https://cloud.ibm.com/docs/FileStorage?topic=FileStorage-managinglimits). For more information about the limit on simultaneous authorizations, see the [FAQs](https://cloud.ibm.com/docs/FileStorage?topic=FileStorage-file-storage-faqsauthlimit).







 Connecting your new storage 

When your provisioning request is complete, authorize your hosts to access the new storage and configure your connection. Depending on your host's operating system, follow the appropriate link.



* [Mounting File Storage for Classic on Red Hat Linux®](https://cloud.ibm.com/docs/FileStorage?topic=FileStorage-mountingLinux)
* [Mounting File Storage for Classic in CentOS](https://cloud.ibm.com/docs/FileStorage?topic=FileStorage-mountingCentOS)
* [Mounting File Storage for Classic on Ubuntu](https://cloud.ibm.com/docs/FileStorage?topic=FileStorage-mountingUbuntu)
* [Mounting File Storage for Classic as a VMware® datastore on ESXi hosts](https://cloud.ibm.com/docs/FileStorage?topic=FileStorage-architectureguide)
* [Configuring File Storage for Classic for backup with cPanel](https://cloud.ibm.com/docs/FileStorage?topic=FileStorage-cPanelBackups)
* [Configuring File Storage for Classic for backup with Plesk](https://cloud.ibm.com/docs/FileStorage?topic=FileStorage-PleskBackup)







 Disaster recovery considerations
* If your documents contain attachments, you might want to consider reducing the batch_size and increasing the worker_processes, to accommodate larger documents in smaller batches.
* If you have many tiny documents, then you might consider increasing the [worker_process](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-advanced-replicationperformance-related-options) and [http_connections](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-advanced-replicationperformance-related-options) values.
* If you want to run replication with minimal impact, setting worker_processes and http_connections to 1 might be appropriate.
* For more information, see [Consumption of Read and Write Operations by Replication](https://cloud.ibm.com/docs/Cloudant?topic=Cloudant-ibm-cloud-publicconsumption-of-read-and-write-operations-by-replication).



For further assistance about the best configuration for your use case, go to the [IBM Cloud Support portal](https://www.ibm.com/cloud/support).

Replication performance can be improved by enabling the "use_bulk_get": true" replication option. In that case, the replicator fetches documents from the source in batches rather than individually.

{
"_id": "rep_doc_id",
"source": "https://account1.cloudant.com/db1",
"target": "https://account2.cloudant.com/db2",
"use_bulk_get": true
}

The increased replication rate might consume the available read or write rate capacity on the source and target endpoint accounts.





 Removing conflicting document revisions with replication 

One way to remove conflicted document revisions via replication is by enabling the "winning_revs_only": true option. This option only replicates the winning document revisions. That is the revision returned by default by a GET $SERVICE_URL/$DATABASE/$DOCID request. This option is an advanced option, as it discards conflicted document revisions. Use this option with care.
For example, you might scale from 256 - 1256 MB by changing the memory quota on the app details page. However, because the disk quota remained the same, you didn't get more disk space.

 Why it’s happening 

The default disk quota that is allocated for an app is 1 GB. If you need more disk space, you must manually specify the disk quota.

 How to fix it 

Use one of the following methods to specify your disk quota. The maximum disk quota that you can specify is 2 GB. If 2 GB is still not enough, try an external service such as [Cloud Object Storage](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-getting-started-cloud-object-storage).



* In the manifest.yml file, add the following item:

disk_quota: <disk_quota>
* Use the -k option with the ibmcloud cf push command when you push your app to IBM Cloud:

ibmcloud cf push appname -p app_path -k <disk_quota>







 Org's services limit is exceeded 

If you are a Lite account user, you might be unable to create an app in IBM Cloud if you exceeded your organization's services limit.

 What’s happening 

When you try to create an app in IBM Cloud, the following error message is displayed:

BXNUI2032E: The <service_instances> resource wasn't created. While Cloud Foundry was being contacted to create the resource, an error occurred. Cloud Foundry message: "You have exceeded your organization's services limit."

 Why it’s happening 

This error occurs when you exceed the limit on the number of service instances that you can have for your account.

 How to fix it 

Delete any services instances that aren't needed, or remove the limit on the number of service instances that you can have.



* To delete a services instance, you can use the IBM Cloud console or the command line interface.

To use the IBM Cloud console to delete a service instance, complete the following steps: 1. In the resource list, click the Actions menu for the service that you want to delete. 2.
Storing large objects 

IBM Cloud® Object Storage can support single objects as large as 10 TB when using multipart uploads.

Large objects can also be uploaded [by using the console with Aspera high-speed-transfer enabled](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-aspera). Under most scenarios, Aspera high-speed transfer results in significantly increased performance for transferring data, especially across long distances or under unstable network conditions.



 Uploading objects in multiple parts 

Multipart upload operations are recommended to write larger objects into Object Storage. An upload of a single object is performed as a set of parts and these parts can be uploaded independently in any order and in parallel. Upon upload completion, Object Storage then presents all parts as a single object. This provides many benefits: network interruptions do not cause large uploads to fail, uploads can be paused and restarted over time, and objects can be uploaded as they are being created.

Multipart uploads are only available for objects larger than 5 MB. For objects smaller than 50 GB, a part size of 20 MB to 100 MB is recommended for optimum performance. For larger objects, part size can be increased without significant performance impact. Multipart uploads are limited to no more than 10,000 parts of 5 GB each up to a maximum object size of 10 TB.

Due to the complexity involved in managing and optimizing parallelized uploads, many developers use libraries that provide multipart upload support.

Most tools, such as the CLIs or the IBM Cloud Console, as well as most compatible libraries and SDKs, will automatically transfer objects in multipart uploads.





 Using the REST API or SDKs 

Incomplete multipart uploads do persist until the object is deleted or the multipart upload is aborted. If an incomplete multipart upload is not aborted, the partial upload continues to use resources. Interfaces should be designed with this point in mind, and clean up incomplete multipart uploads.

There are three phases to uploading an object in multiple parts:



1.
Attachment state unattached
Capacity 100
IOPS 3000
Bandwidth(Mbps) 393
Profile general-purpose
Encryption key -
Encryption provider_managed
Resource group defaults
Created 2023-06-29T16:14:59+00:00
Zone us-east-1
Health State ok
Volume Attachment Instance Reference -
Active false
Unattached capacity update supported false
Unattached iops update supported false
Busy false
Tags -





 Updating a volume attachment from the CLI 

You can update the volume attachment name and change the default auto delete setting with the instance-volume-attachment-update command.

ibmcloud is instance-volume-attachment-update INSTANCE_ID VOLUME_ATTACHMENT_ID [--name NEW_NAME] [--auto-delete true | false] [--json]

Use the --name option and specify a new name for the volume attachment. Specify --auto-delete true to automatically delete a volume that is attached to an instance, when you delete the instance. specify --auto-delete false, if you want to keep the volume as a stand-alone volume after the instance is deleted.

$ ibmcloud is instance-volume-attachment-update kj-test-ro otp1 --name one-true-pairing --auto-delete false
Updating volume attachment otp1 of instance kj-test-ro under account Test Account as user test.user@ibm.com...

ID 0757-6757e676-0bf5-4b79-9a5b-29c24e17420c
Name one-true-pairing
Volume ID Name
r014-dee9736d-08ee-4992-ba8d-3b64a4f0baac demo-volume-update

Status attached
Bandwidth(Mbps) 393
Type data
Device 0757-6757e676-0bf5-4b79-9a5b-29c24e17420c-bxsh7
Auto delete false