vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Planning snapshots 

When you plan a snapshot strategy for your Block Storage for VPC volumes, you might find this checklist helpful when you configure and use snapshots.



 Planning to create and use snapshots 

Consider the following prerequisites before you create snapshots.



Table 1. Checklist for planning snapshots

 Item Considerations 

 Cloud Identity and Access Management permissions Confirm that you have the necessary [IAM access permissions](https://cloud.ibm.com/docs/vpc?topic=vpc-snapshots-vpc-managesnapshots-vpc-iam) to create snapshots. 
 Interface Choose between the UI, CLI, API, or Terraform to create and manage your snapshots. 
 Volumes <br><br> * Evaluate which volumes are most important to snapshot. You can create a snapshot of boot and data volumes.<br> * Evaluate the amount of change that you expect for the volumes that you intend to snapshot. A volume with numerous changes and a lengthy retention period requires more attention than a volume with moderate changes. Also, the cumulative size of all snapshots for a volume can't exceed 10 TB.<br><br><br> 
 Naming conventions Select a unique name for your snapshot. For example, if you have a method for naming volumes, you might name snapshots by using similar conventions. It's easier to filter and search for them later. For more information, see [Naming snapshots](https://cloud.ibm.com/docs/vpc?topic=vpc-snapshots-vpc-managesnapshots-vpc-naming). 
 Snapshots retention Evaluate how many snapshots to retain, how long you need to retain them, and when to delete snapshots. Review the [snapshots limitations](https://cloud.ibm.com/docs/vpc?topic=vpc-snapshots-vpc-aboutsnapshots-vpc-limitations) before you perform these actions. 
 Restoring a volume Consider when you might want to restore a volume from a snapshot.
Step 1 - Initial planning and prerequisites 

Each Caveonix RiskForesight™ application component is loosely coupled, but centrally managed. Therefore, they can be deployed in an “all-in-one” virtual machine deployment pattern or the application components can be “scaled-out” and deployed on multiple VMs for higher availability, performance, and capacity.

Deployment patterns are based on both availability requirements and sizing for data retention. RiskForesight deployment nodes can be characterized as:



* Base VMs – The base VMs host the application components that do not scale due to data retention. These components are; RiskForesight UI, RiskForesight App, RiskForesight Plugins, Central Collector, Remote Collector, Index Datastore, Messaging Datastore, and Relational Datastore.
* Scale-out VMs – The scale-out VMs (the database and the data index) scale according to the number of assets and the required data retention. These requirements might create demand for more scale-out hard disk space and more scale-out VMs.



Review the three Caveonix RiskForesight deployment models:



* “All-in-one” – An automated deployment and configuration of one VM that hosts all the application components:



* All application components installed on one VM.
* Remote Collectors can be installed on separate VMs.
* Small deployments – up to 100 assets with 7 - 30 days of indexing.



* Partial Distributed – After the automated deployment is completed, you can manually scale out by increasing RAM and disk in the initial VM and add three scale-out VM.



* UI, App, Plugins, Central Collector, Remote Collector, Index Datastore, Messaging Datastore, and Relational Datastore deployed on one VM.
* Remote Collectors installed on separate VMs.
* Index Data Nodes deployed on separate VMs.
* Small-to-medium deployments – up to 500 assets with 30 days of indexing.



* Fully Distributed - Add more base VMs and scale-out VMs according to the number of assets and data retention requirements:



* Application components distributed onto separate VMs to facilitate scaling.
* Required deployment pattern as number of assets increases in the range 500 - 100000.
Removing compliance evidence generated before a designated time 

Because of the substantial volume of evidence generated by DevSecOps pipelines, the Git repository continuously expands causing performance degradation and failure during pipeline runs. Therefore, you must remove older evidence by using the evidence pruning tool.

Collecting evidence an essential aspect of the DevSecOps reference architecture. Compliance evidence establishes an audit trail that auditors seek during compliance audits. One of the objectives of DevSecOps is to automate the generation and storage of evidence in auditable evidence lockers. The primary locker for housing evidence is the Git repository.

The Cloud Object Storage bucket functions as a secondary evidence repository and automatically prunes evidence based on a retention policy of 365 days. However, the Git Evidence Repository, serving as the primary evidence repository, requires explicit cleanup of evidence that surpasses the 365-day threshold. The evidence pruning tool eliminates any evidence that is generated before a designated time for the Git Evidence Repository.

If the evidence that is pruned is still referred to by the inventory asset then the CD pipeline breaks. In such cases, rebuild the app to have the latest evidence.



 Running the evidence pruning tool 

The evidence pruning trigger is preconfigured for DevSecOps pipelines that are created after the v9.16.0 release of compliance pipelines. However, the following take the following steps if you have existing DevSecOps Toolchains.



1. Add a manual trigger

While there are no definitive guidelines on the choice of pipelines (CI, CD, or CC) for configuring the evidence pruning tool, you must set it up within the CC Pipeline. Based on your choice of pipeline, go to Pipeline Configuration" > Triggers > Add and select Manual.

Zoom

![Add manual trigger](https://cloud.ibm.com/docs-content/v1/content/5eb88a2575e30e316dbb83829c7f4c8b1ddbc67c/devsecops/images/devsecops-pipeline-config-manual-trigger.png)

Figure 1. Manual trigger for Pruning Evidence
For more information, see [Maximizing transcription accuracy](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-audio-formatsaudio-formats-recommendations).
* Speech recognition is sensitive to background noise and nuances of human speech.



* Engine noise, working devices, street noise, and background conversations can significantly reduce recognition accuracy.
* Regional accents and differences in pronunciation can also reduce accuracy.



If your audio has these characteristics, consider using acoustic model customization to improve the accuracy of speech recognition. For more information, see [Understanding customization](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-customization).
* To learn more about the characteristics of your audio, consider using audio metrics with your speech recognition request. If you are knowledgeable about audio-signal processing, the metrics can provide meaningful and detailed insight into your audio characteristics. For more information, see [Audio metrics](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-metricsaudio-metrics).
For more information about Retention Schemes, see the [FAQ](https://cloud.ibm.com/docs/Backup?topic=Backup-faqsfaqs).





 Running a BMR backup job 



* If you scheduled a time-based backup job, you don't need to do anything else. Your job runs automatically as scheduled.
* If you set up a manual job (without a time-based schedule), you can run it by selecting its row in the job list and click Run backup. As with time-based jobs, you can choose the Retention Scheme and the Advanced backup options. After you made your configuration choices, click Start backup to start the job.
ibmcloud cr quota-set [--traffic TRAFFIC] [--storage STORAGE]



 Prerequisites 

To find out about the required permissions, see [Access roles for configuring Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-iamaccess_roles_configure).





 Command options 

--traffic TRAFFIC
: (Optional) Changes your traffic quota to the specified value in megabytes. The operation fails if you are not authorized to set traffic, or if you set a value that exceeds your current pricing plan.

--storage STORAGE
: (Optional) Changes your storage quota to the specified value in megabytes. The operation fails if you are not authorized to set storage quotas, or if you set a value that exceeds your current pricing plan.





 Example 

Set your quota limit for pull traffic to 7000 megabytes and storage to 600 megabytes.

ibmcloud cr quota-set --traffic 7000 --storage 600







 ibmcloud cr region 

Displays the targeted region and the registry.

ibmcloud cr region

For more information, see [Regions](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewregistry_regions).



 Prerequisites 

None







 ibmcloud cr region-set 

Set a target region for the IBM Cloud Container Registry commands. To list the available regions, run the command with no options.

ibmcloud cr region-set [REGION]



 Prerequisites 

None





 Command options 

REGION
: (Optional) The name of your target region, for example, us-south. For more information, see [Regions](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_overviewregistry_regions).





 Example 

Target the US South region.

ibmcloud cr region-set us-south







 ibmcloud cr retention-policy-list 

List the image retention policies for your account. Image retention policies retain the specified number of images for each repository within a namespace in IBM Cloud Container Registry.
You can set only one policy in each namespace.

You can choose whether to exclude all untagged images from the total number of images that you decide to retain.

Where an image, within a repository, is referenced by multiple tags, that image is counted only once. Newest images are retained. Age is determined by when the image was created, not when it was pushed to the registry.

If a retention policy deletes an image that you want to keep, you can restore the image. To identify the image, list the contents of the trash by running the [ibmcloud cr trash-list](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_trash_list) command and restore the selected image by running the [ibmcloud cr image-restore](https://cloud.ibm.com/docs/Registry?topic=Registry-containerregclibx_cr_image_restore) command.

If you want to cancel a retention policy, see [Update a retention policy to keep all your images](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_retentionretention_policy_keep).

ibmcloud cr retention-policy-set [--retain-untagged] --images IMAGECOUNT NAMESPACE



 Prerequisites 

To find out about the required permissions, see [Access roles for using Container Registry](https://cloud.ibm.com/docs/Registry?topic=Registry-iamaccess_roles_using).





 Command options 

NAMESPACE
: The namespace for which you want to create a policy.

--retain-untagged
: (Optional) Retain all untagged images when the retention policy is being processed. Only tagged images are analyzed and, if the images don't meet the criteria, they are deleted. If the option isn't specified, all tagged and untagged images are analyzed and, if the images don't meet the criteria, they are deleted.

--images
: Determines how many images to keep within each repository in the specified namespace. The newest images are retained.
For hosts running an agent for non-orchestrated environments or for hosts running an agent for orchestrated environments that exceed the base tier allotment for Prometheus, JMX, appchecks, and Statsd metrics, additional prices apply:



* Time series are priced according to the following tiers:



* Tier 1: The price per time-series is 0.08 USD for up to 100K time-series per month.
* Tier 2: The price per time-series is 0.05 USD for 100K to 1M time-series per month.
* Tier 3: The price per time-series is 0.03 USD for 1M to 10M time-series per month.
* Tier 4: The price per time-series is 0.02 USD for more than 10M time-series per month.



* Containers are priced as follows: 5.23 USD per 10 containers per month.
* API calls are priced as follows: The price for API calls is 0.01 USD per 1000 API calls per month.



Each measure is priced independently when there is an overage.

Platform metrics are an additional source of time-series. They are priced based on the tiers.

A host can be a container, a virtual machine, a bare metal, or any metrics source where you install a monitoring agent.

Data is collected and retained per the standard guidelines across all plans. For more information see [data collection](https://cloud.ibm.com/docs/monitoring?topic=monitoring-mng-datadata-collection) and [data retention](https://cloud.ibm.com/docs/monitoring?topic=monitoring-mng-datadata_storage_retention).

Prometheus remote write cost is based on metric ingestion. The price is calculated the same as for metrics collected using the agent with IBM Cloud Monitoring.





 Graduated Tier - Sysdig Secure + Monitor 

The Graduated Tier - Sysdig Secure + Monitor service plan includes both IBM Cloud Monitoring and [IBM Cloud Security and Compliance Center Workload Protection functionality.](https://cloud.ibm.com/docs/workload-protection).
For speeds of 2-10 GB, IBM installs 10 GB optics. As a result, an upgrade of 1-5 GB would require new optics to be assigned or inserted. It would be a service affecting event. If you anticipate that type of growth, it's possible to request 10 GB optical fibers to be installed at the beginning of your Direct Link deployment, or to order 2 GB initially so that the 10 GB optics are in place.





 Is ECMP the way to go for redundant Direct Link connections? What alternatives exist? 

ECMP isn’t for redundant connections, but for balancing the load over the two links. With ECMP, both connections must terminate to the same IBM Cloud cross-connect router (XCR), which makes it a single point of failure. In other words, ECMP can be provisioned only as two sessions on the same IBM Cloud XCR.

ECMP is a feature of BGP. If you are looking for redundancy, you should get two Direct Link connections, one going into each XCR. If you want to use ECMP and have redundancy, you need two Direct Link connections on each XCR so that you can have 2 ECMP sessions running simultaneously.

Alternatively, some customers set up two links into a different XCR in the same data center (for example, WDC02) and then failover as needed by using BGP configurations. This configuration is less redundant (less safe) than having Direct Link connections into two separate data centers, such as WDC02 and WDC05.





 Is there a Service Level Agreement (SLA) on the Direct Link XCR connections up to the account’s BCR connection? 

There is no SLA on Direct Link today. You can achieve 99.99% effectively with two or more direct links that are properly configured for failover by using BGP, but IBM cannot control that or provide an SLA on it.





 For Direct Link offerings, does IBM set a BGP password? 

By default, BGP passwords for Direct Link aren't set up. Currently, BGP MD5 authentication is supported.
If the original IOPS/GB ratio for the volume is less than 0.25, the new IOPS/GB ratio must be less than 0.25. If the original IOPS/GB ratio for the volume is greater than or equal to 0.25, the new IOPS/GB ratio for the volume must be greater than or equal to 0.25.

Example output

Order 31020713 was placed successfully!.
> Storage as a Service

> 40 GBs

> 2 IOPS per GB

> 20 GB Storage Space (Snapshot Space)

You may run 'ibmcloud sl file volume-list --order 12345667' to find this file volume after it is ready.
4. If you changed the size of your volume and you use the volume in a pod, log in to your pod to verify the new size. List all the pods that use PVC. Pods are returned in the format: <pod_name>: <pvc_name>.

oc get pods --all-namespaces -o=jsonpath='{range .items[]}{"n"}{.metadata.name}{":t"}{range .spec.volumes[]}{.persistentVolumeClaim.claimName}{" "}{end}{end}' | grep "<pvc_name>"
5. Log in to your pod.

oc exec -it <pod_name> bash
6. Show the disk usage statistics and find the server path for your volume that you retrieved earlier.

df -h

Example output

Filesystem Size Used Avail Use% Mounted on
overlay 99G 4.8G 89G 6% /
tmpfs 64M 0 64M 0% /dev
tmpfs 7.9G 0 7.9G 0% /sys/fs/cgroup
fsf-dal1001g-fz.adn.networklayer.com:/IBM01SEV1234567_6/data01 40G 0 40G 0% /myvol
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 appropriate 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 (SLO) describe the design points that the IBM Cloud services are engineered to meet. IBM Cloud Container Registry is designed to achieve the following availability target.



Table 1. SLO for Container Registry

 Availability target Target Value 

 Availability % 99.999 



The SLO is not a warranty and IBM does 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 service level objectives, see [IBM Cloud service level objectives](https://cloud.ibm.com/docs/overview?topic=overview-slo).





 Locations for service availability 

For more information about service availability within regions and data centers, see [Service and infrastructure availability by location](https://cloud.ibm.com/docs/overview?topic=overview-services_region).





 Frequently asked questions about high availability 

Review the following FAQs about high availability.



 Does IBM Cloud replicate the service? 

IBM doesn't make replicas of your data available in any region other than the region where you stored it. High availability is achieved by running the service in three data centers in each region.





 Are users required to replicate the service? 

You're not required to replicate your data into another region, but you can do it yourself by using tools such as [skopeo copy](https://github.com/containers/skopeo/blob/main/docs/skopeo-copy.1.md).
Range between [100 and 6000], and in multiples of 100 [only for performance volumes] If no IOPS value is specified, the original IOPS value of the volume is used. Requirements: [If original IOPS/GB for the volume is less than 0.3, new IOPS/GB must also be less than 0.3. If original IOPS/GB for the volume is greater than or equal to 0.3, new IOPS/GB for the volume must also be greater than or equal to 0.3.]

-t, --new-tier
: Endurance Storage Tier (IOPS per GB) [only for endurance volumes] If no tier is specified, the original tier of the volume is used. Requirements: [If original IOPS/GB for the volume is 0.25, new IOPS/GB for the volume must also be 0.25. If original IOPS/GB for the volume is greater than 0.25, new IOPS/GB for the volume must also be greater than 0.25.]

-f, --force
: Force operation without confirmation.

Examples:

ibmcloud sl block volume-modify 12345678 --new-size 1000 --new-iops 4000

This command modifies volume 12345678 with size of 1000 GB, and IOPS is 4000.

ibmcloud sl block volume-modify 12345678 --new-size 500 --new-tier 4

This command modifies volume 12345678 with size 500 GB, and tier level is 4 IOPS per GB.





 ibmcloud sl block volume-set-lun-id 

Set the LUN ID on an existing block storage volume:

ibmcloud sl block volume-set-lun-id VOLUME_ID LUN_ID





 ibmcloud sl block volume-convert 

Convert a dependent duplicate volume to an independent volume:

ibmcloud sl block volume-convert VOLUME_ID

Examples:

ibmcloud sl block volume-convert 12345678

Convert a dependent duplicate 12345678 to an independent volume.





 ibmcloud sl block volume-detail 

Display details for a specified volume:

ibmcloud sl block volume-detail VOLUME_ID
6000 in multiples of 100 [only used for
performance volumes] If no IOPS value is
specified, the IOPS value of the origin
volume will be used.
Requirements: [If
IOPS/GB for the origin volume is less than
0.3, IOPS/GB for the duplicate must also be
less than 0.3. If IOPS/GB for the origin
volume is greater than or equal to 0.3,
IOPS/GB for the duplicate must also be
greater than or equal to 0.3.]
-t, --duplicate-tier [0.25|2|4|10]
Endurance Storage Tier (IOPS per GB) [only
used for endurance volumes] If no tier is
specified, the tier of the origin volume
will be used.
Requirements: [If IOPS/GB
for the origin volume is 0.25, IOPS/GB for
the duplicate must also be 0.25. If IOPS/GB
for the origin volume is greater than 0.25,
IOPS/GB for the duplicate must also be
greater than 0.25.]
-s, --duplicate-snapshot-size INTEGER
The size of snapshot space to order for the
duplicate. If no snapshot space size is
specified, the snapshot space size of the
origin file volume will be used.
Input
"0" for this parameter to order a duplicate
volume with no snapshot space.
--billing [hourly|monthly] Optional parameter for Billing rate (default
to monthly)
-h, --help Show this message and exit.

Dependent duplicate volumes can be ordered from the SLCLI, too, with the option --dependent-duplicate TRUE.

slcli file volume-duplicate --dependent-duplicate TRUE <primary-vol-id>

For more information about available command options, see [file volume-duplicate](https://softlayer-python.readthedocs.io/en/latest/cli/file/file-volume-duplicate).





 Creating a duplicate LUN with the API
With ECMP, both connections must terminate to the same IBM Cloud cross-connect router (XCR), which makes it a single point of failure. In other words, ECMP can be provisioned only as two sessions on the same IBM Cloud XCR.

ECMP is a feature of BGP. If you are looking for redundancy, you should get two Direct Link connections, one going into each XCR. If you want to use ECMP and have redundancy, you need two Direct Link connections on each XCR so that you can have 2 ECMP sessions running simultaneously.

Alternatively, some customers set up two links into a different XCR in the same data center (for example, WDC02) and then failover as needed by using BGP configurations. This configuration is less redundant (less safe) than having Direct Link connections into two separate data centers, such as WDC02 and WDC05.
* Is there a Service Level Agreement (SLA) on the Direct Link XCR connections up to the account’s BCR connection?

There is no SLA on Direct Link today. You can achieve 99.99% effectively with two or more direct links that are properly configured for failover by using BGP, but IBM cannot control that or provide an SLA on it.
* For Direct Link offerings, does IBM set a BGP password?

By default, BGP passwords for Direct Link aren't set up. Currently, BGP MD5 authentication is supported.



Direct Link on Classic



* How does Direct Link on Classic differ from the new Direct Link offering?

The new IBM Cloud Direct Link offering differs from "Direct Link on Classic" in that the new Direct Link is decoupled from classic IaaS, and exists only in the local cross-connect router (XCR). This design enables native connectivity to VPC and future capabilities without being forced into the classic IaaS network.

The zone-region model allows for multiple data centers to exist in a single zone.

The new Direct Link offering allows connectivity to both Classic IaaS as well as VPCs, whereas the Classic Direct Link always connects to IaaS network and a global VRF first.