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







 Ordering Snapshots 

To create snapshots of your storage volume, either automated or manually, you need to purchase space to hold them. You can purchase snapshot capacity during the initial volume purchase or later by using these steps.



 Determining how much snapshot space to order 

Generically speaking, snapshot space is used by snapshots based on two key factors:



* How much your active file system changes over time,
* How long you plan to retain snapshots.



The way to calculate the amount of space that you need is (Rate of Change) x (number of hours/days/weeks/months data is retained).

The first snapshot uses a negligible amount of space as it's just a copy of the metadata (pointers) that indicates the active file system blocks.

A volume with numerous changes and a lengthy retention period needs more space than a volume with moderate change and a moderate retention schedule. An example for the first type is a high change rate database. An example for the second type is a VMware® datastore.

If you take 12 hourly snapshots of 500 GB of actual data, and the change rate is 1 percent between each snapshot, you end up with 60 GB for snapshots.

(5-GB Rate of Change) x (12 hourly snapshots) = (60 GB of used space)

Conversely, if that 500 GB of actual data, with 12 hourly snapshots, saw 10 percent of change every hour, the snapshot space that is used is 600 GB.

(50-GB Rate of Change) x (12 hourly snapshots) = (600 GB of used space)

So when you determine how much Snapshot space you need, consider the rate of change carefully. It's a huge influence on how much snapshot space you need. A bigger volume is more likely to change more often. However, a 500-GB volume with 5 GB of change and a 10-TB volume with 5 GB of change use the same amount of snapshot space.

Additionally, for most workloads, the larger a volume is the less space needs to be set aside initially.
For more information, see the [FAQs](https://cloud.ibm.com/docs/FileStorage?topic=FileStorage-file-storage-faqsdeleted).

Customers with special requirements for compliance such as NIST 800-88 Guidelines for Media Sanitization can perform the data sanitization procedure before they delete their storage.

To cancel a storage volume, you need to revoke access from any hosts first. Active replicas and dependent duplicates can also block reclamation of the Storage volume. Make sure that the volume is no longer mounted, host authorizations are revoked, replication is canceled, and no dependent duplicates exist before you attempt to cancel the original volume.



1. Go to the [IBM Cloud® console](https://cloud.ibm.com/login). From the menu, select Classic Infrastructure![Classic icon](https://cloud.ibm.com/docs-content/v1/content/04e9937a86546143babfc65ea21fdd4ea2d12d13/icons/classic.svg).
2. Click Storage > File Storage for Classic.
3. Click Actions![Actions icon](https://cloud.ibm.com/docs-content/v1/content/04e9937a86546143babfc65ea21fdd4ea2d12d13/icons/action-menu-icon.svg) for the volume to be canceled, and select Delete File Storage for Classic.
4. Confirm if want to cancel the volume immediately or on the anniversary date of when the volume was provisioned.

If you select the option to cancel the volume on its anniversary date, you can void the cancellation request before its anniversary date.
5. Click Continue.
6. Click the acknowledgment checkbox, and click Confirm.



When the volume is deleted, the request is followed by a 24-hour reclaim wait period. You can still see the volume in the console during those 24 hours. When the reclaim-period expires, the data is destroyed and the volume is removed from the console, too.
reclaimPolicy: "Delete"

Example for Performance block storage.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: ibmc-block-custom-xfs
labels:
addonmanager.kubernetes.io/mode: Reconcile
provisioner: ibm.io/ibmc-block
parameters:
classVersion: "2"
type: "Performance"
sizeIOPSRange: |-
[20-39]Gi:[100-1000]
[40-79]Gi:[100-2000]
[80-99]Gi:[100-4000]
[100-499]Gi:[100-6000]
[500-999]Gi:[100-10000]
[1000-1999]Gi:[100-20000]
[2000-2999]Gi:[200-40000]
[3000-3999]Gi:[200-48000]
[4000-7999]Gi:[300-48000]
[8000-9999]Gi:[500-48000]
[10000-12000]Gi:[1000-48000]
fsType: "xfs"
reclaimPolicy: "Delete"
Show more







 Removing persistent storage from a cluster 

When you set up persistent storage in your cluster, you have three main components: the Kubernetes persistent volume claim (PVC) that requests storage, the Kubernetes persistent volume (PV) that is mounted to a pod and described in the PVC, and the IBM Cloud infrastructure instance, such as classic file or block storage. Depending on how you created your storage, you might need to delete all three components separately.



 Understanding your storage removal options 

Removing persistent storage from your IBM Cloud account varies depending on how you provisioned the storage and what components you already removed.

Is my persistent storage deleted when I delete my cluster?
: During cluster deletion, you have the option to remove your persistent storage. However, depending on how your storage was provisioned, the removal of your storage might not include all storage components.
The RAM provisioned to your deployment remains for your future needs, or until you scale down your deployment manually. The disk provisioned to your deployment remains because disk cannot be scaled down.
* If you just need to add resources to your deployment occasionally or rarely, you can [manually scale](https://cloud.ibm.com/docs/databases-for-mongodb?topic=databases-for-mongodb-resources-scaling) your deployment.







 Configuring Autoscaling in the UI 

The Autoscaling panel is on the Resources tab of your deployment's Manage page. To enable scaling, enter your parameters. Then, check the boxes to enable the parameters you are using. Be sure to click Save Changes for your configuration to be saved and your changes to take effect.

To disable autoscaling, clear the boxes for the parameters that you no longer want to use. If you clear all the boxes, autoscaling is disabled. Click Save Changes to save the configuration.





 Configuring Autoscaling in the CLI 

You can get the autoscaling parameters for your deployment through the CLI by using the [cdb deployment-autoscaling](https://cloud.ibm.com/docs/databases-cli-plugin?topic=databases-cli-plugin-cdb-reference-ibmcloud-cdb-deployment-autoscaling-) command.

ibmcloud cdb deployment-autoscaling <deployment name or CRN> member

To enable and set autoscaling parameters through the CLI, use a JSON object or file with the [cdb deployment-autoscaling-set](https://cloud.ibm.com/docs/databases-cli-plugin?topic=databases-cli-plugin-cdb-reference-ibmcloud-cdb-deployment-autoscaling-set-) command.
Adding a disk For more information about adding a disk to an existing VM, see [Add a hard disk to a virtual machine](https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.vm_admin.doc/GUID-79116E5D-22B3-4E84-86DF-49A8D16E7AF2.html). 
 Shrinking a disk For more information about shrinking a disk to an existing VM, see [Growing, thinning, and shrinking virtual disks for VMware ESX and ESXi](https://kb.vmware.com/s/article/1002019). 
 Expanding a disk For more information about expanding the size of an existing disk for a VM, see [Change the virtual disk configuration](https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.vm_admin.doc/GUID-E1D541D1-DF96-467A-89B7-E84F83B2563D.html). 
 Hot migrate For more information about how to vMotion a VM between vSphere hosts in the same cluster, see [Managing virtual machines](https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.vm_admin.doc/GUID-B7023DD7-F790-4DF8-89B4-FF09DA3DBFB1.html?hWord=N4IghgNiBcIBYHsAuACAtgSwOYCcxIFMUA3NEAXyA).
Autoscaling configurations based on memory usage are currently not available.

Disk - Disk autoscaling can scale when either disk usage reaches a certain threshold, Disk I/O utilization reach a certain threshold, or both. (The "or" in the UI operates as an inclusive or, |, v.) The amount of IOPS available to your deployment increases with disk size at a ratio of 10 IOPS for each GB.

The resource numbers refer to each database node in a deployment. For example, there are three data members in a Databases for EnterpriseDB deployment and if the deployment is scaled with 20 GB of disk and 1 GB of RAM, that means each member gets 20 GB of disk and 1 GB of RAM. The total resources added to your deployment is 60 GB of disk and 3 GB of RAM.



 Autoscaling Considerations 



* Scaling your deployment up might cause your databases to restart. If your scaled deployment needs to be moved to a host with more capacity, then the databases are restarted as part of the move.
* Disk cannot be scaled down.
* A few scaling operations can be more long running than others. Drastically increasing RAM or Disk can take longer than smaller increases to account for provisioning more underlying hardware resources.
* Autoscaling operations are logged in [IBM Cloud® Activity Tracker](https://cloud.ibm.com/docs/databases-for-enterprisedb?topic=cloud-databases-activity-tracker-integration).
* Limits



* can't set anything to scale in an interval less than 60 seconds.
* Maximum Disk = 4 TB per member
* Maximum RAM = 112 GB per member



* Autoscaling does not scale down deployments where disk or memory usage shrunk. The RAM provisioned to your deployment remains for your future needs, or until you scale down your deployment manually. The disk provisioned to your deployment remains because disk cannot be scaled down.
* If you need to add resources to your deployment occasionally or rarely, you can [manually scale](https://cloud.ibm.com/docs/databases-for-enterprisedb?topic=databases-for-enterprisedb-resources-scaling) your deployment.







 Configuring Autoscaling in the UI
* Identify if you need to enforce boundaries for different users groups.

For example, your developers cannot develop the app and test it. You require a different set of users to test the app. In this scenario, you create two spaces, one for developers of the app and one for testers of the app. Then, grant each set of users access to the correct space.

When you implement a multi-organization architecture, you can separate each organization by the LOB, the delivery lifecycle, or both. You can then define multiple spaces, which are based on the number of apps or projects that are delivered by the same department in the company. Consider the following guidance when you plan the spaces in an organization:
* Define a space to host a service that requires provisioning and configuring only once in the organization.
* Define a space per app, per group of related apps, or for a specific project.
* If you need to enforce boundaries for different users, define a space for each set of users. When a user is granted a developer role in a space, that user has full access to any resources and IBM Cloud services) that are provisioned and running in that space. When you need to enforce tighter security to prevent users controlling every resource, consider defining different spaces. Within any of these spaces, you can provision IBM Cloud services that are used by the apps running in that space.







 Space naming, restrictions, and management 

To define the different spaces for your cloud organization, consider the following guidance:



* Define and enforce a naming convention. For example, define a naming convention where the space name includes information about where the organization is located and the type of cloud. You can change the name of a space after it is created. If a space name is altered, notify all of the space team members about the change.
* Define the restrictions that apply to the space. For example, define the type of apps that can be developed, managed, and deployed in each space.
* Identify the manager of the space. You might want to delegate the space administration to more than one person.
Orgs can't be deleted after you add them.



1. In the IBM Cloud console, go to Manage > Account, and select Account resources > Cloud Foundry orgs. Click Create.
2. Enter an org name. The name must be unique in IBM Cloud.

If the org name is already in use by another IBM Cloud Public, Dedicated, or Local user, you must specify a different name.
3. Click Add.



After you add the org, you're automatically assigned the Organization Manager permission, so you can edit the org name, add users, and create or delete spaces in the org.

You can assign the following [Cloud Foundry roles](https://cloud.ibm.com/docs/account?topic=account-mngcfcfroles) to users in an org. All users who are invited to the account are assigned the auditor role by default.



* Organization manager
* Organization billing manager
* Organization auditor







 Creating spaces in the console 

Within an organization, you can use spaces to group a set of applications, services, and users. Spaces are defined within a single IBM Cloud region. You can create spaces in an org based on the delivery lifecycle. For example, you can create a dev space as a development environment, a test space as a testing environment, and a production space as a production environment. Then, you can associate your apps with spaces.

To add a space to an org, complete the following steps.



1. On the Cloud Foundry Orgs page in the console, click the name of the org that you want to add a space to.
2. Click Add a space.
3. Select a region and enter a name.
4. Click Save.



After you add users to an org, you can grant them permissions to the spaces. Similar to orgs, spaces also have a set of [Cloud Foundry roles](https://cloud.ibm.com/docs/account?topic=account-mngcfcfroles) with specific permissions that are assigned to team members:



* Space manager
* Space developer
* Space auditor
Yes, you can use this setup because NFS is a file-aware protocol.





 Can I increase inodes for my NFS volume? 

Typically, when volumes are provisioned, they are allotted the maximum inode count for the size that you ordered. Maximum inode count grows automatically as the volume grows. If the inodes count does not increase after you expanded a volume, submit a [support case](https://cloud.ibm.com/unifiedsupport/cases/add).





 I am unable to upgrade storage. What can affect the ability to upgrade or expand storage? 

The following situations can affect the ability to upgrade or expand storage.



* If the original volume is the Endurance 0.25 tier, then the IOPS tier can’t be updated.
* Older storage types can't be upgraded. Ensure that the storage was ordered in an upgraded Data Center that allows for [Expandable storage](https://cloud.ibm.com/docs/FileStorage?topic=FileStorage-expandCapacity).
* The permissions that you have in the Cloud console can be a factor. For more information, see the topics within [User roles and permissions](https://cloud.ibm.com/docs/account?topic=account-userroles).







 Are File Storage for Classic volumes thin or thick provisioned? 

All Block and File Storage for Classic services are thin-provisioned. This method is not modifiable.





 My billing ID changed, what does this mean? 

You might notice that your Storage volumes are now billed as "Endurance Storage Service” or "Performance Storage Service" instead of "Enterprise Storage". You might also have new options in the console, such as the ability to adjust IOPS or increase capacity. IBM Cloud® strives to continuously improve storage capabilities. As hardware gets upgraded in the data centers, storage volumes that reside in those data centers are also upgraded to use all enhanced features. The price that you pay for your Storage volume does not change with this upgrade.





 How durable is File Storage for Classic? 

When you store your data in File Storage for Classic, it's durable, highly available, and encrypted.
The RAM provisioned to your deployment remains for your future needs, or until you scale down your deployment manually. The disk provisioned to your deployment remains because disk can not be scaled down.
* If you just need to add resources to your deployment occasionally or rarely, you can [manually scale](https://cloud.ibm.com/docs/databases-for-mysql?topic=databases-for-mysql-resources-scaling) your deployment.







 Configuring Autoscaling in the UI 

The Autoscaling panel is on the Resources tab of your deployment's Manage page. To enable scaling, enter your parameters. Then, check the boxes to enable the parameters you are using. Be sure to click Save Changes for your configuration to be saved and your changes to take effect.

To disable autoscaling, clear the boxes for the parameters that you no longer want to use. If you clear all the boxes, autoscaling is disabled. Click Save Changes to save the configuration.





 Configuring Autoscaling in the CLI 

You can get the autoscaling parameters for your deployment through the CLI by using the [cdb deployment-autoscaling](https://cloud.ibm.com/docs/databases-cli-plugin?topic=databases-cli-plugin-cdb-reference-ibmcloud-cdb-deployment-autoscaling-) command.

ibmcloud cdb deployment-autoscaling <deployment name or CRN> member

To enable and set autoscaling parameters through the CLI, use a JSON object or file with the [cdb deployment-autoscaling-set](https://cloud.ibm.com/docs/databases-cli-plugin?topic=databases-cli-plugin-cdb-reference-ibmcloud-cdb-deployment-autoscaling-set-) command.
For more information, see [Scaling Event Streams](https://cloud.ibm.com/docs/EventStreams?topic=EventStreams-ES_scaling_capacity) on storage capacity options.

Storage capacity cannot be scaled down. To move to a lower storage capacity would require creating a new Event Streams service instance at the lower capacity unit.

For more information, see [Scaling Event Streams](https://cloud.ibm.com/docs/EventStreams?topic=EventStreams-ES_scaling_capacity).





 Schema Registry 



 Schemas 



* Maximum number of schemas that can be stored: 1000
* Maximum number of schema versions for each schema that can be stored: 100
* Maximum schema size: 64 kB







 Limits 



* Maximum request rate [HTTP Schema Admin] 10 per second
* Maximum request rate [HTTP Serdes] 100 per second









 Other limits 



* Maximum message size: 1 MB
* Maximum concurrently active Kafka clients: 10000
* Maximum record key size when you use REST Producer API is 4 K.
* Maximum record value size when you use REST Producer API is 64 K.
* Maximum messages per second when you use REST Producer API is 200.









 Satellite plan 



 Network throughput 

Network throughput capacity is based on the peak maximum. Each peak maximum has a recommended maximum for typical production workloads.



Table 2. Network throughput capacity on Satellite

 Peak Maximum Recommended maximum 

 150 MB/s (75 MB/s producing and 75 MB/s consuming) 100 MB/s (50 MB/s producing and 50 MB/s consuming) 



Throughput is expressed as the number of bytes per second that can be both sent and received in a service instance.

Throughput capacity cannot be scaled down. To move to a lower throughput capacity, requires creating a new Event Streams service instance at the lower capacity unit.

The following figures are not verified. They are guidelines only.

The recommended maximum figure is based on a typical workload and considers the possible impact of operational actions such as internal updates or failure modes, like the loss of an availability zone.
Autoscaling configurations based on memory usage are currently not available.

Disk - Disk autoscaling can scale when either disk usage reaches a certain threshold, Disk I/O usage reach a certain threshold, or both. (The "or" in the UI operates as an inclusive or, |, v.) The amount of IOPS available to your deployment increases with disk size at a ratio of 10 IOPS for each GB.

The resource numbers refer to each database member in a deployment. For example, there are two data members in a PostgreSQL deployment and if the deployment is scaled with 10 GB of disk and 1 GB of RAM, that means each member gets 10 GB of disk and 1 GB of RAM. The total resources added to your deployment is 20 GB of disk and 2 GB of RAM.



 Autoscaling Considerations 



* Scaling your deployment up might cause your databases to restart. If your scaled deployment needs to be moved to a host with more capacity, then the databases are restarted as part of the move.
* Disk cannot be scaled down.
* A few scaling operations can be more long running than others. Drastically increasing RAM or Disk can take longer than smaller increases to account for provisioning more underlying hardware resources.
* Autoscaling operations are logged in [IBM Cloud® Activity Tracker](https://cloud.ibm.com/docs/databases-for-postgresql?topic=cloud-databases-activity-tracker).
* Limits



* can't set anything to scale in an interval less than 60 seconds.
* Maximum Disk = 4 TB per member
* Maximum RAM = 112 GB per member



* Autoscaling does not scale down deployments where disk or memory usage is shrunk. The RAM provisioned to your deployment remains for your future needs, or until you scale down your deployment manually. The disk provisioned to your deployment remains because disk cannot be scaled down.
* If you need to add resources to your deployment only occasionally or rarely, [manually scale](https://cloud.ibm.com/docs/databases-for-postgresql?topic=databases-for-postgresql-resources-scaling) your deployment.
* Read-only replicas do not auto-scale to match the leader.
For a list of valid provisioning codes for LocationConstraint, see [the Storage Classes guide](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-classes).
* Can the storage class of a bucket be changed? For example, if you have production data in 'standard', can we easily switch it to 'vault' for billing purposes if we are not using it frequently?

You can change the storage class by manually moving or copying the data from one bucket to another bucket with the wanted storage class.
* Can the location of a bucket be changed?

To change a location, create a new bucket in the desired location and move existing data to the new bucket.
* Does data consistency in Object Storage come with a performance impact?

Consistency with any distributed system comes with a cost, because the efficiency of the IBM Cloud Object Storage dispersed storage system is not trivial, but is lower compared to systems with multiple synchronous copies.
* Aren't there performance implications if my application needs to manipulate large objects?

For performance optimization, objects can be uploaded and downloaded in multiple parts, in parallel.
* How does IBM Cloud® Object Storage delete expired data?

Deletion of an object undergoes various stages to prevent data from being accessible (both before and after deletion). For details, see [Data deletion](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-securitysecurity-deletion).
* How many objects can fit in a single bucket?

There is no practical limit to the number of objects in a single bucket.
* Can I nest buckets inside one another?

No, buckets cannot be nested. If a greater level of organization is required within a bucket, the use of prefixes is supported: {endpoint}/{bucket-name}/{object-prefix}/{object-name}. The object's key remains the combination {object-prefix}/{object-name}.
* What is the difference between 'Class A' and 'Class B' requests?

'Class A' requests are operations that involve modification or listing.