vania-janet/multiturn-rag-retrieval-data huggingface dataset:
To create your customized storage class, see [Customizing a storage class](https://cloud.ibm.com/docs/containers?topic=containers-file_storagecustom-sc-nfs-creat). Then, [use your customized storage class in your PVC](https://cloud.ibm.com/docs/containers?topic=containers-file_storageadd_file).



 Creating topology-aware storage 

To use File Storage for Classic in a multizone cluster, your pod must be scheduled in the same zone as your File Storage for Classic instance so that you can read and write to the volume. Before topology-aware volume scheduling was introduced by Kubernetes, the dynamic provisioning of your storage automatically created the File Storage for Classic instance when a PVC was created. Then, when you created your pod, the Kubernetes scheduler tried to deploy the pod to a worker node in the same data center as your File Storage for Classic instance.

Creating the File Storage for Classic instance without knowing the constraints of the pod can lead to unwanted results. For example, your pod might not be able to be scheduled to the same worker node as your storage because the worker node has insufficient resources or the worker node is tainted and does not allow the pod to be scheduled. With topology-aware volume scheduling, the File Storage for Classic instance is delayed until the first pod that uses the storage is created.

The following examples show how to create storage classes that delay the creation of the File Storage for Classic instance until the first pod that uses this storage is ready to be scheduled. To delay the creation, you must include the volumeBindingMode: WaitForFirstConsumer option. If you don't include this option, the volumeBindingMode is automatically set to Immediate and the File Storage for Classic instance is created when you create the PVC.

Example for Endurance File Storage for Classic.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: ibmc-file-bronze-delayed
parameters:
billingType: hourly
classVersion: "2"
iopsPerGB: "2"
sizeRange: '[20-12000]Gi'
type: Endurance
* Objects encrypted [using SSE-C](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-sse-c) cannot be replicated, although [managed encryption (SSE-KMS) like Key Protect](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-kp) is fully compatible with replication.
* Objects in an archived state cannot be replicated.



As versioning is a requirement for replication, it is not possible to replicate objects in buckets configured with an [Immutable Object Storage policy](https://cloud.ibm.com/docs/cloud-object-storage/basics?topic=cloud-object-storage-immutable).



1. After navigating to your chosen source bucket, click the Configuration tab.
2. Look for Bucket replication and click the Setup replication button.
3. Select Replication source and click Next.
4. Assuming the target bucket is in the same IBM Cloud account, select the instance and bucket from the drop-down menus. Alternatively, toggle the radio button to No and paste in the CRN of the target bucket.
5. Click on the Check permissions button.



Now, you'll need to grant the source bucket Writer permissions on the target bucket. There are several ways to do this, but the easiest is to use the IBM Cloud Shell and the IBM Cloud CLI.



1. Open an IBM Cloud Shell in a new window or tab.
2. Copy the IBM Cloud CLI command shown in the Object storage console, and paste it into the new shell.
3. Return to the bucket configuration window or tab, and click on the Check permissions button again.



Now you'll create a replication rule.



1. Ensure the rule status radio button is set to Enabled.
2. Give the rule a name and a priority, as well as any prefix or tag filters that will limit the objects subject to the replication rule.
3. Click Done.







 Terminology 

Source bucket: The bucket for which a replication policy is configured.
Upload data 

After getting your storage organized into buckets, it's time to add some objects by uploading data.

Depending on how you want to use your storage, there are different ways to get data into the system. A data scientist has a few large files that are used for analytics, a systems administrator needs to keep database backups synchronized with local files, and a developer is writing software that needs to read and write millions of files. Each of these scenarios is best served by different methods of data ingest.

Some applications may wish to restrict a user or Service ID to only uploading data, without any access to reading data in a bucket. This is possible through the Object Writer [IAM role](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-iam).



 Using the console 

Typically, using the web-based console is not the most common way to use Object Storage. Objects are limited to 200 MB and the file name and key are identical. Multiple objects can be uploaded at the same time, and if the browser allows for multiple threads each object will be uploaded by using multiple parts in parallel. Support for larger object sizes and improved performance (depending on network factors) is provided by [Aspera high-speed transfer](https://cloud.ibm.com/docs/cloud-object-storage/basics?topic=cloud-object-storage-aspera).





 Using a compatible tool 

Some users want to use a stand-alone utility to interact with their storage. As the Cloud Object Storage API supports the most common set of S3 API operations, many S3-compatible tools can also connect to Object Storage by using [HMAC credentials](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-uhc-hmac-credentials-main).
<LocationConstraint xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
us-south-standard
</LocationConstraint>

--------------------





 Create a bucket lifecycle configuration 

A PUT operation uses the lifecycle query parameter to set lifecycle settings for the bucket. A Content-MD5 header is required as an integrity check for the payload.

Not all operations are supported in Satellite environments. For details, see [supported Satellite APIs](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-apis-cos-satellite)

Syntax

PUT https://{endpoint}/{bucket-name}?lifecycle path style
PUT https://{bucket-name}.{endpoint}?lifecycle virtual host style

Payload Elements

The body of the request must contain an XML block with the following schema:



 Element Type Children Ancestor Constraint 

 LifecycleConfiguration Container Rule None Limit 1 
 Rule Container ID, Status, Filter, Transition LifecycleConfiguration Limit 1 
 ID String None Rule Must consist of (a-z,A- Z0-9) and the following symbols:!_ .*'()- 
 Filter String Prefix Rule Must contain a Prefix element. 
 Expiration Container Days, Date, ExpiredObjectDeleteMarker Rule Limit 1 
 Prefix String None Filter If using a transition (archive) rule, the value must be set to <Prefix/>. This limitation does not apply to expiration rules. 
 Transition Container Days, StorageClass Rule Limit 1 transition rule, and 1000 rules in total. 
 Days Non-negative integer None Transition Must be a value equal to or greater than 0. 
 Date Date None Transition Must be in ISO 8601 Format and the date must be in the future. 
 StorageClass String None Transition Must be set to GLACIER or ACCELERATED. 
 ExpiredObjectDeleteMarker Boolean None Expiration Must be true or false.
: New buckets created in eu Cross Region configuration can now use [Key Protect managed encryption](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-kp).





 20 January 2022 

IBM Cloud Satellite
: You can now use your own compute infrastructure to create a Satellite location. Then, you use the capabilities of Satellite to run IBM Cloud services on your infrastructure, and consistently deploy, manage, and control your software workloads. For details, see [IBM Cloud Satellite](https://cloud.ibm.com/docs/satellite)





 15 December 2022 

Encryption update
: Buckets can be created in a US cross-region configuration using [Hyper Protect Crypto Services](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-hpcs-cr) managed encryption.





 11 November 2021 

Versioning update
: Object expiration is now permitted in [buckets with versioning enabled](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-versioning).

Lifecycle update
: Bucket lifecycle rules can now be created to [automatically remove incomplete multipart uploads](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-lifecycle-cleanup-mpu).





 24 September 2021 

Encryption update
: Buckets created using [Key Protect managed encryption](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-kp) can now also use [Immutable Object Storage](https://cloud.ibm.com/docs/cloud-object-storage/basics?topic=cloud-object-storage-immutable) to create retention policies that prevent object deletion or modification.





 30 August 2021 

New location!
: Buckets can now be created in a Regional configuration in São Paulo, Brazil.
Best practices for Block Storage for Classic 

Follow our best practices to maximize the performance of your storage, and avoid application downtime.



 Best practice 1 - Clear the path 

To achieve maximum IOPS, adequate network resources need to be in place.



* Run storage traffic on a dedicate VLAN. Running storage traffic through software firewalls increases latency and adversely affects storage performance. It's best to run storage traffic on a VLAN, which bypasses the firewall. For more information, see [routing storage traffic to its own VLAN interface](https://cloud.ibm.com/docs/BlockStorage?topic=BlockStorage-block-storage-faqs&interface=uihowtoisolatedstorage).
* Avoid routing your storage traffic to a gateway device whenever possible. When storage traffic is routed to a gateway device, it can add latency to storage traffic, or it can cause storage traffic disruption if the firewall in the gateway device is misconfigured. The storage disruption is especially true when maintenance such as a restart is required on a single (nonclustered) gateway device. If a storage traffic must be routed through a gateway device, ensure that the gateway device has an at-least 10-Gbps interface, or the gateway device might become a network bottleneck.
* Use a faster NIC. Throughput limits are set at the LUN level and a faster interface doesn't increase that limit. However, with a slower Ethernet connection, your bandwidth can be a potential hindrance to achieving best performance levels.
* Choose a higher bandwidth. The speed of your Ethernet connection must be faster than the expected maximum throughput from your volume. Generally, don't expect to saturate your Ethernet connection beyond 70% of the available bandwidth.

For example, if you have 6,000 IOPS and are using a 16-KB block size, the volume can handle approximately 94-MBps throughput. However, when you have a 1-Gbps Ethernet connection to your LUN, it becomes a bottleneck when your servers attempt to use the maximum available throughput. It's because 70 percent of the theoretical limit of a 1-Gbps Ethernet connection (125 MB per second) would allow for 88 MB per second only.
System.out.printf("Updated metadata for item %s from bucket %sn", itemName, bucketName);
}
Show more





 Using COPY to update metadata 

public static void updateMetadataCopy(String bucketName, String itemName, String key, String value) {
System.out.printf("Updating metadata for item: %sn", itemName);

//set the new metadata
HashMap<String, String> userMetadata = new HashMap<String, String>();
userMetadata.put(key, value);

ObjectMetadata metadata = new ObjectMetadata();
metadata.setUserMetadata(userMetadata);

//set the copy source to itself
CopyObjectRequest req = new CopyObjectRequest(bucketName, itemName, bucketName, itemName);
req.setNewObjectMetadata(metadata);

_cos.copyObject(req);

System.out.printf("Updated metadata for item %s from bucket %sn", itemName, bucketName);
}
Show more







 Using Immutable Object Storage 



 Add a protection configuration to an existing bucket 

This implementation of the PUT operation uses the protection query parameter to set the retention parameters for an existing bucket. This operation allows you to set or change the minimum, default, and maximum retention period. This operation also allows you to change the protection state of the bucket.

Objects written to a protected bucket cannot be deleted until the protection period has expired and all legal holds on the object are removed. The bucket's default retention value is given to an object unless an object specific value is provided when the object is created. Objects in protected buckets that are no longer under retention (retention period has expired and the object does not have any legal holds), when overwritten, will again come under retention. The new retention period can be provided as part of the object overwrite request or the default retention time of the bucket will be given to the object.
If you want to persist your images, consider using a private registry such as IBM Cloud Container Registry, backing up your images to persistent storage such as Object Storage, or creating a separate, stand-alone Red Hat OpenShift container registry (OCR) cluster. For more information, see the [Red Hat OpenShift docs](https://docs.openshift.com/container-platform/4.11/registry/index.html).

VPC clusters
: The internal registry of your Red Hat OpenShift cluster backs up your images to a bucket that is automatically created in an IBM Cloud Object Storage instance in your account. Any data that is stored in the object storage bucket remains even if you delete the cluster.

Classic, VPC, or Satellite clusters
: You can optionally choose to set up the internal registry to store data in the emptyDir of the worker node where the internal registry pod runs. Keep in mind that this data is not persistent, and if the pod or worker node is restarted, the stored data is deleted and unrecoverable. You might store the images locally in the emptyDir to increase performance if you build containers from large images regularly.



 Backing up your internal image registry to IBM Cloud Object Storage 

Virtual Private Cloud

Your images in your Red Hat OpenShift cluster internal registry are automatically backed up to an IBM Cloud Object Storage bucket. Any data that is stored in the object storage bucket remains even if you delete the cluster.

The internal registry is backed up to IBM Cloud Object Storage only for Red Hat OpenShift on IBM Cloud clusters that run version 4 on VPC infrastructure.

However, if the bucket fails to create when you create your cluster, you must manually create a bucket and set up your cluster to use the bucket. In the meantime, the internal registry uses an emptyDir Kubernetes volume that stores your container images on the secondary disk of your worker node. The emptyDir volumes are not considered persistent highly available storage, and if you delete the pods that use the image, the image is automatically deleted.
Engage technical skills and strategic vision to co-create with your client as their technical consultant with the [IBM Certified Professional Sales Engineer v1](https://www.ibm.com/training/certification/C0010200). Use public, hybrid, and multicloud solutions to get the technical win. IBM Cloud Sales Engineers possess a breadth of architecture experience, technical leadership skills, and knowledge in multiple technologies, industries, and platforms, with depth in IBM Cloud technologies and offerings.





 IBM Cloud Security Engineer Specialty 

Learn how to anticipate threats and maintain your organization’s security environment with an [IBM Cloud Security Engineer Specialty v1](https://www.ibm.com/training/path/ibmcloudsecurityengineerspecialty) certification. This course includes modules on secure infrastructure and hybrid cloud connections, Cloud compute, Kubernetes services, and VMware solutions in IBM Cloud.





 IBM Cloud Satellite Specialty 

As an [IBM Cloud Satellite Specialty v1](https://www.ibm.com/training/path/ibmcloudsatellite) technical professional, you can deploy and run applications across on-premises, edge computing, and public cloud environments. Help your clients bring the flexibility and agility of public cloud services to their secure on-premises data centers and gain a competitive advantage.





 IBM Cloud for Financial Services Specialty 

An [IBM Cloud for Financial Services v1 Specialty](https://www.ibm.com/training/path/ibmcloudforfinancialservices) certification teaches you the business drivers, differentiators, and components of IBM Cloud for Financial Services. Learn how to deliver operational criteria and compliance controls for confidential compute environments.





 IBM Cloud DevSecOps Specialty 

With an [IBM Cloud DevSecOps Specialty](https://www.ibm.com/training/path/ibmclouddevsecopsspecialty) certification, you are able to integrate security in a continuous delivery pipeline and understand how to deploy apps faster and more securely.
Understanding high availability for Planning Analytics as a Service 

High availability(HA) is a core discipline in an IT infrastructure to keep your apps up and running, even after a partial or full site failure. The main purpose of high availability is to eliminate potential points of failures in an IT infrastructure.



  Responsibilities 

See [Shared responsibilities for IBM products.](https://cloud.ibm.com/docs/overview?topic=overview-shared-responsibilities) for details on responsibility ownership between IBM and the customer when using Planning Analytics as a Service.





  What level of availability do I need? 

You can achieve high availability on different levels in your IT infrastructure and within different components of your cluster. The level of availability that is right for you depends on several factors, such as your business requirements, the service level agreements (SLAs) that you have with your customers, and the resources that you want to expend.





  What level of availability does IBM Cloud offer? 

The level of availability that you set up for your cluster impacts your coverage under the IBM Cloud high availability service level agreement terms.

Service level objectives (SLOs) describe the design points that the IBM Cloud services are engineered to meet. Planning Analytics as a Service is designed to achieve the following availability target.



Table 1. SLO for Planning Analytics as a Service

 Availability target  Target Value 

 Availability %       99.99        



The SLO is not a warranty and IBM will not issue credits for failure to meet an objective. Refer to the SLAs for commitments and credits that are issued for failure to meet any committed SLAs. For a summary of all SLOs, see [IBM Cloud service level objectives](https://cloud.ibm.com/docs/overview?topic=overview-slo).
Designed for professionals with three or more years of experience working as cloud architects, [IBM Certified Advanced Architect - Cloud v1](https://www.ibm.com/training/path/ibmcloudadvancedarchitect) extends and validates your capabilities. This interactive curriculum offers a deeper exploration of the latest IBM technologies and best practices.





 IBM Cloud Professional Developer 

Gain the skills and knowledge that is required to build cloud services and large-scale business applications as an [IBM Certified Professional Developer - Cloud](https://www.ibm.com/training/path/ibmcloudprofessionaldeveloper) technical professional. Learn cloud development and operations (DevOps) functions by using IBM Cloud services and APIs, including AI, cloud databases, and cloud security.





 IBM Cloud Associate Site Reliability Engineer (SRE) 

As an [IBM Certified Associate SRE - Cloud v1](https://www.ibm.com/training/path/ibmcloudassociatesitereliabilityengineer%28sre%29) technical professional, you are able to manage enterprise workloads in IBM Cloud environments. You also develop skills and knowledge around incident management, monitoring, troubleshooting, operations, deployments, and security and compliance.





 IBM Cloud Professional Site Reliability Engineer 

Advance your skills with [IBM Certified Professional SRE - Cloud v2](https://www.ibm.com/training/path/ibmcloudprofessionalsitereliabilityengineer%28sre%29v2) professional-level training. Renew your understanding of operations, software engineering, and systems administration. And learn the monitoring and incident management tools that are needed to manage enterprise workloads in IBM Cloud environments.





 IBM Cloud Professional Sales Engineer 

Engage technical skills and strategic vision to co-create with your client as their technical consultant with the [IBM Certified Professional Sales Engineer v1](https://www.ibm.com/training/certification/C0010200). Use public, hybrid, and multicloud solutions to get the technical win. IBM Cloud Sales Engineers possess a breadth of architecture experience, technical leadership skills, and knowledge in multiple technologies, industries, and platforms, with depth in IBM Cloud technologies and offerings.





 IBM Cloud Security Engineer Specialty
You use a service credential to programmatically access the service from your application. The service credential includes the URL to access the service instance and the credentials to access the service. It may be desirable to create multiple service credentials for different applications or deployments of your applications. You cannot restore removed credentials. You'll have to create new credentials for your application.



1. On the left side, click Service credentials and click New credential. Then, do the following steps:



* In the Name field, you specify the name of the credential. This should represent the name of the application that will be accessing the service.
* Optionally select an Access role and Service ID. Note: The IAM role is currently not used to access the Cognos Dashboard Embedded service.
* Click Add.



2. On the Service Credentials screen, click View credentials on the name of the credential that you created in the previous step. A JSON object is displayed which includes credential details.



You will use the following values to create a session and embed Cognos Dashboard Embedded into your application:



* api_endpoint_url
* client_id
* client_secret







 Step 3: Creating a Cognos Dashboard Embedded session 

You can use a REST service to create a Cognos Dashboard Embedded session with basic authentication using the client_id and client_secret. Store and handle these credentials securely as you would any other password. Use credentials only from a server application.

Request Example:

curl -X POST "https://dde-us-south.analytics.ibm.com/daas/v1/session" -H "accept: application/json" -H "authorization: Basic <base64 client_id:client_secret>" -H "Content-Type: application/json" -d "{ "expiresIn": 3600, "webDomain": "https://dde-us-south.analytics.ibm.com"}"

Response Example:

{
"sessionId": "SN401234567801933ccccf",