vania-janet/multiturn-rag-retrieval-data huggingface dataset:
About Block Storage Snapshots for VPC 

Block Storage Snapshots for VPC are a regional offering that is used create a point-in-time copy of your Block Storage for VPC boot or data volume. The initial snapshot that you take is a full backup of the volume. Subsequent snapshots of the same volume are incremental, so only the changes since the last snapshots are captured. You can restore data to a new volume during instance provisioning, from an existing instance, and when you create an unattached volume.



 Snapshots concepts 

A snapshot is a copy of your volume that you take manually in the UI or from the CLI, or create programmatically with the API, or Terraform. You can take a snapshot of a boot or data volume that is attached to a running virtual server instance or from an unattached data volume. A "bootable" snapshot is a snapshot of a boot volume. A "nonbootable" snapshot is of a data volume. You can take snapshots as often as you want. However, you cannot take a snapshot of a volume that's in a degraded state.

Do you want to automatically create snapshots of your Block Storage for VPC volumes? With Backup for VPC, you can create backup policies to schedule regular volume backups. For more information, see [About Backup for VPC](https://cloud.ibm.com/docs/vpc?topic=vpc-backup-service-about).

The first time that you take a snapshot of a volume, all the volume's contents are copied. The snapshot has the same encryption as the volume (customer-managed or provider-managed). Snapshots are stored and retrieved from IBM Cloud® Object Storage. Data is encrypted while in transit and stored in the same region as the original volume.

When you take a second snapshot, it captures only the changes that occurred since the last snapshot was taken. As such, the size of the snapshots can grow or shrink, depending on what is being uploaded to IBM Cloud® Object Storage. The number of snapshots increases with each successive snapshot that you take.
If your Edge function script only passes subrequest responses back to the client verbatim, without reading their bodies, then its body handling is already optimal, and there is no need for the techniques described here.



 Streaming pass-through 

Here’s a minimal pass-through example to get started.

addEventListener("fetch", event => {
event.respondWith(fetchAndStream(event.request))
})

async function fetchAndStream(request) {
// Fetch from origin server.
let response = await fetch(request)

// Create an identity TransformStream (a.k.a. a pipe).
// The readable side becomes our new response body.
let { readable, writable } = new TransformStream()

// Start pumping the body. NOTE: No await!
streamBody(response.body, writable)

// ... and deliver our Response while that's running.
return new Response(readable, response)
}

async function streamBody(readable, writable) {
let reader = readable.getReader()
let writer = writable.getWriter()

while (true) {
const { done, value } = await reader.read()
if (done) break
// Optionally transform value's bytes here.
await writer.write(value)
}

await writer.close()
}
Show more

Some important details to note:



* Although streamBody() is an asynchronous function, we do not want to call await on it, so that it does not block forward progress of the calling fetchAndStream() function. It continues to run asynchronously for as long as it has an outstanding reader.read() or writer.write() operation.
* Backpressure: We await the read operation before calling the write operation. Likewise, we await the write operation before calling the next read operation. Following this pattern propagates backpressure to the origin.
Synchronous replication 

By default, streaming replication is asynchronous. If the primary server crashes then some transactions that were committed may not have been replicated to the standby server, causing data loss. Cloud Databases ensures data loss is kept to a minimum substantial data loss; however, synchronous replication offers the ability to confirm that all changes made by a transaction have been transferred to a synchronous member, ensuring consistency across a cluster. This consistency come from confirming that writes are written to a secondary before returning to the connecting client with a success. For variables regarding synchronous replication, see [synchronous_commit](https://cloud.ibm.com/docs/databases-for-enterprisedb?topic=databases-for-enterprisedb-changing-configurationgeneral-settings) on the Changing Configuration page.

Synchronous replication brings replica availability into the primary write path. If there is no replica to acknowledge the write, the write will hang until such time as a replica is available. This requires at least three members to function reliably, as synchronous replication is not supported on two-member deployments. You must horizontally scale to at least three members before synchronous replication can be enabled.

While unlikely, it is possible that more than one replica may become unavailable simultaneously. If this happens, the primary database will not be able to complete any writes until a replica comes back online, effectively blocking all write traffic to your database. When deciding to use synchronous replication, you should weigh the relative costs and benefits of higher data durability versus potential availability issues.

Employing synchronous replication will negatively impact the performance of the database. Typically, a performant and effective way to employ this feature is by using it only on specific databases or users that must have the highest degree of data durability available.





 Application-level High-Availability 

Applications that communicate over networks and cloud services are subject to transient connection failures. You want to design your applications to retry connections when errors are caused by a temporary loss in connectivity to your deployment or to IBM Cloud.

Because Databases for EnterpriseDB is a managed service, regular updates and database maintenance occurs as part of normal operations. This can occasionally cause short intervals where your database is unavailable.
true N/A 
 Node Label Key Value label-value Config The value of the worker node key=value label. true N/A 
 Device Path devicepath Config The local storage device path. Example: /dev/sdc. Required when auto-discover-devices is set to false. false N/A 









 Storage class reference for local block storage 

Review the Satellite storage classes for local block storage. You can describe storage classes in the command line with the oc describe sc <storage-class-name> command.



Table 2. Local block storage class reference

 Storage class name Type Reclaim policy 

 sat-local-block-gold Block Retain 







 Getting help and support for local block storage 



1. Review the FAQs in the [Red Hat OpenShift docs](https://docs.openshift.com/container-platform/4.9/storage/persistent_storage/persistent-storage-local.html).
2. Review the [troubleshooting documentation](https://cloud.ibm.com/docs/satellite?topic=satellite-storage-must-gather) to troubleshoot and resolve common issues.
3. Check the status of the IBM Cloud platform and resources by going to the [Status page](https://cloud.ibm.com/status).
4. Review [Stack Overflow](https://stackoverflow.com/questions/tagged/ibm-cloud) to see whether other users experienced the same problem. Tag any questions with ibm-cloud, so that it's seen by the IBM Cloud development teams.
5. If you run into an issue with the Local Storage Operator - Block template, you can open an issue in the [Red Hat Customer Portal](https://access.redhat.com/).
Kubernetes NodeLocal DNS cache N/A 1.15.4 For more information, see the [Kubernetes NodeLocal DNS cache release notes](https://github.com/kubernetes/dns/releases/tag/1.15.4). For more information about this new beta feature, see [Setting up NodeLocal DNS Cache (beta)](https://cloud.ibm.com/docs/containers?topic=containers-cluster_dnsdns_enablecache). 
 Cluster master HA proxy 1.9.7-alpine 2.0.1-alpine See the [HAProxy release notes](https://www.haproxy.org/download/2.0/src/CHANGELOG). 
 GPU device plug-in and installer a7e8ece d91d200 Updated image for [CVE-2019-9924](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9924).
Where smart contracts contain the business logic that governs the interactions for a set of assets, "chaincode" describes the larger set of packages and infrastructure that encompass the smart contract.





 Channel 

Consisting of a subset of network members who want to transact privately. Channels provide data isolation and confidentiality by allowing the members of a channel to establish specific rules and a separate ledger that only channel members can access. Peers, which are the nodes that function as transaction endpoints for organizations, are joined to channels.





 Client 

The client represents the entity that acts on behalf of a user. It must connect to a peer for communicating with the blockchain. The client might connect to any peer of its choice. Clients create and thus invoke transactions. The client submits an actual transaction invocation to the endorsers, and broadcasts transaction proposals to the ordering service.





 Commit 

Referring to a step in the Hyperledger Fabric v2.x smart contract lifecycle, after the number of approvals that are specified in the channel lifecycle endorsement policy are satisfied, the smart contract definition can be committed to a channel, and the peers where it is installed can begin to process requests.





 Connection profile 

A connection profile is used by the Fabric Client SDKs to connect to the network. A connection profile can be downloaded from the [Organizations tile](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-organizationsibp-console-organizations-connx-profile).





 Consensus 

A collaborative process to keep the ledger transactions synchronized across the network. Consensus ensures that ledgers are updated only when the appropriate participants approve transactions, and that ledgers are updated with the same transactions in the same order. There are many different algorithmic ways of achieving consensus.





 Consenter set 

The ordering service nodes actively participating in the ordering process on a channel. These nodes are also known as "consenters."





 Console 

The name of the user interface in the IBM Blockchain Platform. The console allows users to view, create, and manage their deployments. Because the public and private keys are only stored locally in the browser the console runs on, users maintain total control over their keys.





 Consortium
The asynchronous HTTP interface 

The asynchronous HTTP interface of the IBM Watson® Speech to Text service provides methods for transcribing audio via non-blocking calls to the service. The interface employs user-specified secret strings and digital signatures to provide a level of security for requests that are made over the HTTP protocol. To use the asynchronous interface, you can



* Register a callback URL to be notified by the service of the job status and the results automatically.
* Poll the service to obtain the job status and the results manually.



The two approaches are not mutually exclusive. You can elect to receive callback notifications but still poll the service for the latest status or contact the service to retrieve results manually. The following sections describe how to use the asynchronous HTTP interface with either approach.

Submit a maximum of 1 GB and a minimum of 100 bytes of audio data with a single request. For information about audio formats and about using compression to maximize the amount of audio that you can send with a request, see [Supported audio formats](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-audio-formats). For more information about the individual methods of the interface, see the [API & SDK reference](https://cloud.ibm.com/apidocs/speech-to-text).

The asynchronous HTTP interface does not support multipart speech recognition. You can use only the synchronous HTTP interface for multipart requests. For more information, see [Making a multipart HTTP speech recognition request](https://cloud.ibm.com/docs/speech-to-text?topic=speech-to-text-httpHTTP-multi).



 Usage models 

When you work with the service's asynchronous HTTP interface, you can elect to learn about job status and receive results in the following ways:



* By using callback notifications:



1. Call the POST /v1/register_callback method to register a callback URL with the service.
rsync -a /data/ <public HPVS IP or internal HPVS IP>:/data

On Ubuntu, you install the file-copying tool rsync on the primary virtual server in two steps:

Initially, on the primary virtual server, use the following command to synchronize the package index files from their sources. This is required to retrieve information about available packages, versions, and dependencies.

apt-get update

Then install the file-copying tool rsync on the primary virtual server:

apt-get install rsync

You must exchange the SSH keys so that the cron job script can run. How this works depends on the backup server's SSH server configuration. With the default configuration, you must place the public SSH key as a line in the $HOME/.ssh/authorized_keys file of the user that is used on the backup server. To make rsync use the private SSH key, you must place this key in the cron-jobs user's $HOME/.ssh and give it a default name, for example, for rsa keys, use the name id_rsa. Other options are to configure the SSH client for this user or to adjust the rsync command accordingly.

If needed, quiesce the concerned application before the backup operation. If the primary and the recovery virtual servers are located in one region, use the internal IP address for the backup.

If you want to maintain multiple backups outside virtual server instances created with Hyper Protect Virtual Servers, you can package the data with tar, encrypt it with GnuPG and store it in IBM Cloud® Object Storage.

Also, install the application to the recovery virtual server instance to enable a quick failover.

Finally, always access the application that should be recoverable by using a URL that is pointing to the virtual server IP address and never access the IP address directly.

In a recovery scenario, you can then adjust the URL to point to the recovery virtual server).





 Recovery 

To recover from a disaster by using the previously described backup environment, perform the following steps:



1. Connect to the recovery virtual server instance.
2. Start the concerned application.
3.
Before you take a snapshot, make sure that all cached data is present on disk, especially when you're taking snapshots of instances with Windows and Linux® operating systems. For example, on Linux operating systems, run the sync command to force an immediate write of all cached data to disk.

For customers with special access, data isolation is provided to store snapshots that you created from your dedicated hosts. With data isolation's extra security, your data is encrypted at rest with a unique key and access to your data is protected by a private firewall.





 How snapshots work 

When you take a snapshot, read and write operations from your virtual server instance to the volume continue uninterrupted. After volume data is retrieved, the snapshot enters a pending state until the snapshot is created. When the snapshot is successfully created and in a stable state, you can resume volume management activities, such as deleting, resizing, or detaching a volume. You can also take more snapshots.

Volume data that is retrieved for the requested snapshot is encrypted while in transit from the hypervisor to IBM Cloud® Object Storage. The initial snapshot is the entire copy of your Block Storage for VPC volume. Subsequent snapshots copy only what was changed since the last snapshot.

You can restore a boot or data volume from a running virtual server instance in the UI, CLI, API, or Terraform. Restoring a data from a snapshot creates a new, fully provisioned volume. Restoring from a snapshot of a boot volume creates a new boot volume that you can use to provision a new instance. Restoring from a snapshot of a data volume creates a secondary volume that is attached to the instance.

You can also restore a [stand-alone (unattached) data volume from a snapshot](https://cloud.ibm.com/docs/vpc?topic=vpc-snapshots-vpc-restore&interface=apirestoring-from-an-unattached-snapshot) by using the UI, CLI, or the volumes API and specifying the snapshot ID. The volume from which the snapshot was created does not have to be attached to an instance.
Add both ordering nodes to the consenter set of the system channel. Click each new ordering node, then Add node to ordering service. After the nodes have been added to the ordering service, the nodes are now part of the system channel.





 Export the ordering nodes 

After these two ordering nodes have started successfully as indicated by the green status indicator on its tile, we need to export the node so that they can be imported into the ordering service in the Region 1 and Region 3 consoles.

Open both new ordering nodes, OS4-Region3 and OS5-Region3, and click Export![export icon](https://cloud.ibm.com/docs-content/v1/content/icons/download.svg) to download the configuration to a JSON file on your local system. Share these files with the operators of the consoles in Region 1 and Region 2.







 Update the ordering service in Region 1, Region 2, and Region 3. 

The final step is to update the ordering service in each region with the ordering nodes that were generated in the other two regions.



1. In the Region 1 console, import the os3-Region2, os4-Region3, and os5-Region3 files.



* From the Nodes tab, open the Multiregion Ordering Service tile and click the Ordering nodes tab.
* Click Add another node and then Import an existing ordering node.
* Click Add file and browse to the JSON file for one of the exported ordering nodes.
* Repeat this process for the other two ordering node JSON files.



2. In the Region 2 console, import the os4-Region3, and os5-Region3 files by repeating the same steps that you used in the Region 1 console.
3. In the Region 3 console, import the os3-Region2 file by repeating the same steps.



The ordering service is now synchronized in each console across each region and can be used to create application channels between consortium members.

To summarize, anytime a new ordering node is added to the ordering service in a console, it needs to be exported and then imported into the ordering service in the consoles in the other regions.
* [Node SDK change log](https://github.com/IBM/vpc-node-sdk/blob/master/CHANGELOG.md)
* [Python SDK change log](https://github.com/IBM/vpc-python-sdk/blob/master/CHANGELOG.md)
* [Go SDK change log](https://github.com/IBM/vpc-go-sdk/blob/master/CHANGELOG.md)





 Upcoming changes 

InstanceTemplate response schema change. In an upcoming release, future methods of creating instances, and therefore creating instance templates, may not require a primary network interface. To accommodate this, the primary_network_interface property is now optional in the instance template response model.

At this time, all instances, and therefore all instance templates, continue to require that a primary network interface be specified. Therefore, existing instance templates are unaffected. Additionally, new instance templates will continue to include a primary network interface until further notice. However, to ensure your clients will not be affected in the future, verify that they are tolerant of the primary_network_interface property not being included when consuming InstanceTemplate responses.

Instance response schema change. In an upcoming release, volume attachments returned in the boot_volume_attachment and volume_attachments[] properties of an instance will not include the volume sub-property if the volume has not yet been provisioned. Such volumes are currently represented with empty crn, id, and href properties along with an undocumented sentinel value for name.

To prepare for this change, verify that your client checks that the volume property exists for a volume attachment before attempting to access its crn, id, href, or name sub-properties.

Asynchronous DELETE response code change. In an upcoming release, the response code output for asynchronous DELETE operations will change from 204 to 202. A response code of 204 implies the action is completed, which could be misleading for operations that are still processing. A response code of 202 is more appropriate. This behavior change will occur only for an API version date after its release.
Resyncing is a disruptive operation and performing a resync tears down and rebuilds the data in the read-only replica. The read-only replica is not able to perform any other operations or run any queries while a resync is running. Queries are not rerouted to the leader, so any connections to the read-only replica fail until it is finished resyncing.

The amount of time it takes to resync a read-only replica varies, but the process can be long running.

To start a resync through the CLI, use the [cdb read-replica-resync](https://cloud.ibm.com/docs/databases-cli-plugin?topic=databases-cli-plugin-cdb-referenceread-replica-resync) command.

ibmcloud cdb read-replica-resync <deployment name>

To start a resync through the API, send a POST to the [/deployments/{id}/remotes/resync](https://cloud.ibm.com/apidocs/cloud-databases-apiresync-read-only-replica) endpoint.

curl -X POST https://api.{region}.databases.cloud.ibm.com/v4/ibm/deployments/{id}/remotes/resync -H 'Authorization: Bearer <>'





 Promoting a Read-only Replica 

A read-only replica is able to be promoted to an independent cluster that can accept write operations as well as read operations. If something happens to the leader deployment, the read-only replica can be promoted to a stand-alone cluster and start accepting writes from your application.

To promote a read-only replica from the UI, click the Promote Read-Only Replica button.

Upon promotion, the read-only replica terminates its connection to the leader and becomes a stand-alone Databases for PostgreSQL deployment. The deployment can start accepting and running read and write operations, backups are enabled, and it is issued its own admin user. A new data member is added so the deployment becomes a cluster with two data members.
For more information, see [Persistent VPC load balancers](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-lbaasvpc_lb_persist).

service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "proxy-protocol"
: Enable the PROXY protocol. The load balancer passes client connection information, including the client IP address, the proxy server IP address, and both port numbers, in request headers to your back-end app. Note that your back-end app must be configured to accept the PROXY protocol. For example, you can configure an NGINX app to accept the PROXY protocol by following [these steps](https://docs.nginx.com/nginx/admin-guide/load-balancer/using-proxy-protocol/).

service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type
: Annotation to specify a service that accepts public or private requests. If you don't include this annotation, a public LoadBalancer is created.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector
: Annotation to specify a worker node label selector. To identify the worker nodes that receive traffic, you can select one of the supported label selector keys. Note that you can include only one label selector in the annotation, and that the selector must be specified in the "key=value" format. If this annotation is not specified, all worker nodes in your cluster are configured to receive traffic from the VPC ALB. If specified, this annotation takes precedence over the service.kubernetes.io/ibm-load-balancer-cloud-provider-zone annotation, and any dedicated: edge labels on worker nodes are ignored.
: The following keys are permitted:



* ibm-cloud.kubernetes.io/internal-ip
* ibm-cloud.kubernetes.io/machine-type
* ibm-cloud.kubernetes.io/os