vania-janet/multiturn-rag-retrieval-data huggingface dataset:
* Introduced two new configurable flags in addon-vpc-block-csi-driver-configmap configMap to enable/disable and edit the retry interval for Snapshot Creation.



* IsSnapshotEnabled allows users to disable or enable snapshot functionality. By default, this parameter is set to true
* CustomSnapshotCreateDelay allows users to edit the maximum delay (in seconds) for snapshot calls in case the source volume is not found and the volume is not attached. The maximum delay allowed is 15 minutes and the default is 5 minutes.









 Change log for version 5.0.12_1963, released 15 May 2023 



* Updates UBI image to 8.7-1107
* Updates Golang to 1.19.8
* Users must determine token exchange URL based on cluster provider. For Satellite clusters, always use the provided token exchange URL. If the URL is not provided, use public IAM endpoint.
* Resolves the following CVEs: [CVE-2023-0361](https://nvd.nist.gov/vuln/detail/CVE-2023-0361), [CVE-2023-24536](https://nvd.nist.gov/vuln/detail/CVE-2023-24536), [CVE-2023-24537](https://nvd.nist.gov/vuln/detail/CVE-2023-24537), [CVE-2023-24538](https://nvd.nist.gov/vuln/detail/CVE-2023-24538).







 Change log for version 5.0.10_1869, released 05 April 2023 



* Updates the storage-secret-sidecar image to v1.2.20.
* Updates Golang to v1.19.7.
* Updates the UBI image to 8.7-1085.1679482090
Async, parallel stage runs 

You can run a pipeline stage from the pipeline configuration YAML as an async stage in a small parallel pipeline.

This feature includes the following potential benefits:



* Optimized pipeline run time: You can run time-consuming stages in a parallel "process," while the parent pipeline might process other stages without awaiting the results of the triggered async stage.
* Improved pipeline resiliency: By using the rerun feature of Tekton pipelines, you can rerun a failed stage and keep the state from its first initialization. This feature might be useful to remediate transient infrastructural errors, like network timeouts.





 Glossary 

async stage
: A custom pipeline stage defined in the pipeline config YAML, running asynchronously along with the /parent pipeline/ run.

parallel pipeline
: A small pipeline that runs a single async stage along with the /parent pipeline/ run.

parent pipeline
: The pipeline from the async stage that was initiated.

exported parameter or variable
: A value that is saved for the pipeline run by using the set_env command of [pipelinectl](https://cloud.ibm.com/docs/devsecops?topic=devsecops-devsecops-pipelinectlset_env). The value is exported for async pipeline runs by using the export_env command.





 Capabilities and gaps 

One stage per triggered parallel run
: Each parallel pipeline that runs an async stage can run only one stage. Currently, it’s not possible to run more than one in a single parallel pipeline. However, any number of stages can be created.

Serialized data
: Data that is available in the parent pipeline run and is required for the async stage must be exported for serialization before the stage is triggered.

One-way data flow
: While it is possible to export data to async stages from the parent pipeline run, sending data back directly to the parent pipeline run is not possible.

Existing stages only
: Only stages in the pipeline configuration YAML can be loaded into async stages.
* Understand how your providers route traffic: When you know more details about how your data is transferred to customers around the world, you can make better decisions about where you host your data.







 How IBM Cloud minimizes network latency 

To minimize latency, IBM Cloud took a unique approach to building our network. All of our data centers are connected to network points of presence (PoPs), and all of our network points of presence are connected to each other through our global backbone network. Because IBM maintains our own global backbone network, our network operations team can control network paths and data transfers more precisely than if we relied on other providers to move data between geographies.

For example, if an IBM Cloud customer in Berlin wants to watch a cat video hosted on an IBM Cloud server in Dallas, the packets of data that makes up that cat video travels across our backbone network (which is exclusively used by IBM Cloud traffic) to Frankfurt, where the packets are sent to one of our peering or transit public service providers, finally to get to the user in Berlin. Even better, if our customer uses IBM Cloud CDN capability, the packets are sent from an edge server that is located close to the customer, and they never need to be sent from Dallas at all.

Without a global backbone network, the video packets are sent to a peering or transit public network provider in Dallas, then that provider routes the packets across its network or sends the packets to another provider at a network hop, and the packets finally bounce their way to Germany. It’s entirely possible that the packets might get from Dallas to Berlin with the same network latency without using the global backbone network, but without the global backbone network, more variables exist; the total latency is much more difficult to guarantee or predict.

Along with using our own global backbone network, IBM Cloud also segments public, private, and management traffic onto different network ports. That means that different types of traffic are transferred without interfering with one another.





 Summary: network latency 

Your customers want your data as quickly as you can get it to them. The time that it takes for your data to get to them across the internet is called network latency. The more control that you have over your data’s network path, the more consistent (and lower) your network latency can be.
Using Node.js 

The IBM Cloud® Object Storage SDK for Node.js provides modern capabilities that make the most of IBM Cloud Object Storage.



 Installing the SDK 

[Node.js](https://cloud.ibm.com/docs/node?topic=node-getting-started) is an excellent way to build [web applications](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-mean-stack), and customize your instance of Object Storage for your end users. The preferred way to install the Object Storage SDK for Node.js is to use the [npm](https://www.npmjs.com) package manager for Node.js. Type the following command into a command line:

npm install ibm-cos-sdk

To download the SDK directly, the source code is hosted on [GitHub](https://github.com/IBM/ibm-cos-sdk-js).

More detail on individual methods and classes can be found in [the API documentation for the SDK](https://ibm.github.io/ibm-cos-sdk-js/).





 Getting Started 



 Minimum requirements 

To run the SDK, you need Node 4.x+.





 Creating a client and sourcing credentials 

To connect to COS, a client is created and configured by providing credential information (API Key, Service Instance ID, and IBM Authentication Endpoint). These values can also be automatically sourced from a credentials file or from environment variables.

After generating a [Service Credential](https://cloud.ibm.com/docs/services/cloud-object-storage/iam?topic=cloud-object-storage-service-credentials), the resulting JSON document can be saved to /.bluemix/cos_credentials. The SDK will automatically source credentials from this file unless other credentials are explicitly set during client creation. If the cos_credentials file contains HMAC keys the client authenticates with a signature, otherwise the client uses the provided API key to authenticate with a bearer token.
For more information, see [Migration that uses vMotion or third-party tools and NSX-T L2 bridge](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-v2t-l2-nsx-t).
* VMware HCX - VMware HCX is a solution that is primarily used for migrating workloads between environments, and consists of a number of services to achieve workload mobility. HCX integrates into both NSX-V and NSX-T. HCX Network Extension (NCX-NE) allows simultaneous bridging of multiple networks. The solution is useful in cases where the applications are spread across multiple segments and need inter-app connectivity for extended periods of time during the migration. Using HCX allows bridging of eight segments at a time per HCX-NE pair. This action is especially useful if a workload spans multiple segments. For more information, see [Workload migration with HCX](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-v2t-hcx).



A third possible Layer 2 approach is to use NSX-T L2VPN. In this approach, the NSX-V environment acts as the L2VPN client and the NSX-T environment acts as the L2VPN server. The L2 VPN connection is secured with a route-based IPsec tunnel between the L2 VPN server and the L2 VPN client. This approach is not recommended in IBM Cloud between two vCenter Server instances for V2T migration as NSX-T L2 Bridge offers better performance. And also because IBM Cloud private network supports large MTU (jumbo frames).





 Related links 



* [Terraform by Hashicorp](https://www.terraform.io/)
* [The NSX Terraform Provider](https://registry.terraform.io/providers/vmware/nsxt/latest/docs)
Network and services hub account 

The network and services hub account provides a location for centralized network services, centralized security services, and any customer services that also require centralization.

Zoom

![hub account diagram. All of the information is conveyed in the surrounding text.](https://cloud.ibm.com/docs-content/v1/content/f18e964848e0337fedc42d43e246fa446f4b9646/enterprise-account-architecture/images/shared-tools.svg)

Figure 1. Network and services hub account

A network and services hub account is created in both development and production environments.



Table 1. Components

 Component Quantity Description 

 Transit Gateway 1 Provides network connectivity across all VPCs in the enterprise 
 Direct Link 1-4 Connects the enterprise to the corporate network. Up to 4 instances used if maximum redundancy required 
 Hyper Protect Crypto Services 1-2 Provides key management services to applications across the enterprise. Requires a service-to-service policy for each application. 2 instances required only if scale demands. 
 VPE - VPC 1 Provides private networking for IBM Cloud services. VPEs are provisioned in this VPC for all IBM Cloud services that are used in the enterprise. A custom DNS resolver enables DNS resolution for the VPEs. 
 Shared customer applications n Customer applications that must be centralized can be deployed here 
 Trusted profile 1 Authorizes management of this account by a project in the central administration account 
 Access groups n Small number of access groups to enable a centralized DevOps team to monitor and manage the account 





 Rationale for centralizing shared resources 

Some network infrastructure and certain key resources are costly and require lengthly lead times and manual labor to set up. These resources benefit from enterprise-level centralization to avoid the costs and delays that would be incurred if deployed at an account level. These needs must be balanced against the desire for separation of concerns and blast radius reduction.





 Hyper Protect Crypto Services 

Hyper Protect Crypto Services (HPCS) instances are centrally located so they can be shared across the enterprise to reduce costs. Two instances are required to reach the scale requirements of this recommendation.
Synchronous replication 

By default, streaming replication is asynchronous. If the primary server crashes, some transactions that were committed might not have been replicated to the standby server, causing data loss. Cloud Databases ensures that data loss is kept to a minimum substantial data loss; however, synchronous replication offers the ability to confirm that all changes were 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-postgresql?topic=databases-for-postgresql-changing-configurationgen-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 hangs until 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 might 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 you are deciding to use synchronous replication, weigh the relative costs and benefits of higher data durability versus potential availability issues.

Employing synchronous replication negatively impacts 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 PostgreSQL is a managed service, regular updates and database maintenance occurs as part of normal operations.
* Update DNS records with correct IP addresses on/for target machines.
* Configured shared disk on target side.
* Ensure all the configuration regarding cluster is correct and all services are up and running correctly.
* Known issue: When migration is performed for machines with clustered node "the trust relationship between this workstation and the primary domain failed". So even if you enter the correct domain credentials post migration, it does not allow to user to login.
* Workaround: Simple solution to this problem is to login to the node machine using local admin account and explicitly unjoin node machine from domain and rejoin domain. Once this is done login to the target machine using domain credentials. This process is automated in the form of script. To download and use this script, see this [public GitHub repository](https://github.com/IBM-Cloud/vpc-migration-tools/tree/main/db-migration/mssql/post-migration/).



The RMM tool does not support migration of AWS RDS or similar databases.

This tool can be found in the IBM Cloud catalog as [RackWare RMM](https://cloud.ibm.com/catalog/content/Rackware-Golden-Template-1.11-06545490-596b-4133-8516-8425a11b3265-global) and [RackWare RMM - BYOL](https://cloud.ibm.com/catalog/content/IBM-MarketPlace-P2P-1.3-22935832-bd76-49ab-b53e-12fc5d04c266-global).





 Backup and restore with Windows® IBM Cloud® Backup Agent 

To protect Microsoft® SQL Server databases, you can install the SQL Server plug-in with the Windows® IBM Cloud Backup Agent on the machine where the SQL Server is running. Then, you can add and run backup jobs that specify which SQL Server databases to back up and where to save the backup data. After you back up the SQL Server databases by using the SQL Server plug-in, you can restore databases directly to an SQL Server instance, or restore databases to flat files.
* Understand how your providers route traffic: When you know more details about how your data is transferred to customers around the world, you can make better decisions about where you host your data.







 How IBM Cloud minimizes network latency 

To minimize latency, IBM Cloud took a unique approach to building our network. All of our data centers are connected to network points of presence (PoPs), and all of our network points of presence are connected to each other through our global backbone network. Because IBM maintains our own global backbone network, our network operations team can control network paths and data transfers more precisely than if we relied on other providers to move data between geographies.

For example, if an IBM Cloud customer in Berlin wants to watch a cat video hosted on an IBM Cloud server in Dallas, the packets of data that makes up that cat video will travel across our backbone network (which is exclusively used by IBM Cloud traffic) to Frankfurt, where the packets are sent to one of our peering or transit public network Service Providers, finally to get to the user in Berlin. Even better, if our customer uses IBM Cloud CDN capability, the packets are sent from an edge server located close to the customer, and they never need to be sent from Dallas at all.

Without a global backbone network, the video packets are sent to a peering or transit public network provider in Dallas, then that provider routes the packets across its network or sends the packets to another provider at a network hop, and the packets finally bounce their way to Germany. It’s entirely possible that the packets might get from Dallas to Berlin with the same network latency without using the global backbone network, but without the global backbone network, more variables exist; the total latency is much more difficult to guarantee or predict.

Along with using our own global backbone network, IBM Cloud also segments public, private, and management traffic onto different network ports. That means that different types of traffic are transferred without interfering with one another.





 Summary: network latency 

Your customers want your data as quickly as you can get it to them. The time that it takes for your data to get to them across the internet is called network latency. The more control that you have over your data’s network path, the more consistent (and lower) your network latency can be.
See [Certificate Management](https://cloud.ibm.com/docs/blockchain?topic=blockchain-cert-mgmt) to learn more about your responsibilities. In addition, it is now possible to enable Node OU support for your MSPs and channels through the console. Read more about [Node OU support](https://cloud.ibm.com/docs/blockchain?topic=blockchain-cert-mgmtcert-mgmt-nodeou), why this is important, and how to simplify certificate renewal for the MSPs on your network.





 14 July 2020 

CA, Peer, and ordering node patch 1.4.7-1, 2.1.1-1

Miscellaneous bug fixes and security patches.





 18 June 2020 

Peer and ordering node patch 1.4.7-0

IBM considers this a critical patch that you should apply at your nearest opportunity. Not applying this patch risks being susceptible to a data integrity issue if you experience a CouchDB or underlying storage crash on your peer. This patch updates the CouchDB delayed_commits configuration property to false. The prior setting could cause the peer's CouchDB database to be in an inconsistent state in the event of a CouchDB or underlying storage system crash. The new setting ensures that a peer will recover from crashes in a consistent state. As always, it is recommended to utilize an endorsement policy that requires multiple peers to endorse a transaction, to avoid an inconsistency from a single peer from impacting the overall blockchain network state.

To be certain that your peers have no database corruption, you should reprovision your peers.

Miscellaneous bug fixes and security patches. If you are running OpenShift Container Platform 3.11 in IBM Cloud, it is recommended that you [upgrade your cluster to 4.3](https://docs.openshift.com/container-platform/4.3/migration/migrating_3_4/planning-migration-3-to-4.html) now in order to fully take advantage of the new features.
* [VPC: Adding raw Block Storage for VPC to VPC worker nodes by using the API](https://cloud.ibm.com/docs/openshift?topic=openshift-utilitiesvpc_api_attach)



* [Detaching raw and unformatted Block Storage for Classic from a worker node in a VPC cluster by using the API](https://cloud.ibm.com/docs/openshift?topic=openshift-utilitiesvpc_api_detach)
* [Reviewing volume attachment details for a VPC worker node by using the API](https://cloud.ibm.com/docs/openshift?topic=openshift-utilitiesvpc_api_get_worker)



* [VPC: Attaching raw Block Storage for VPC to VPC worker nodes by using the CLI](https://cloud.ibm.com/docs/openshift?topic=openshift-utilitiesvpc_cli_attach)



* [Removing raw Block Storage for VPC from VPC worker nodes by using the CLI](https://cloud.ibm.com/docs/openshift?topic=openshift-utilitiesstorage-util-rm-vpc-cli)



* [Backing up and restoring PVC data for file and block storage](https://cloud.ibm.com/docs/openshift?topic=openshift-utilitiesibmcloud-backup-restore)



* [Setting up an IBM Cloud Object Storage service instance](https://cloud.ibm.com/docs/openshift?topic=openshift-utilitiesbackup_restore_setup_object_storage)
* [Using IBM Cloud Object Storage to back up and restore PVC data](https://cloud.ibm.com/docs/openshift?topic=openshift-utilitiesbackup-restore-pvc)



* [Setting up IBM Cloud Monitoring for storage volumes](https://cloud.ibm.com/docs/openshift?topic=openshift-utilitiesmonitor_storage)
The peer and ordering nodes are similar in that they both contain an enrollment certificate (the public key or signed certificate), their TLS certificate that enables them to transact with other nodes in their organization, and their MSP admin certificate, which represents the admin identity that is allowed to administer the node.

The IBM Blockchain Platform can automatically renew the enrollment certs for the peer and ordering nodes and the TLS certificate for the peer. But the MSP admin identities have to be manually renewed. If the MSP is enabled for Node Organizational Units (Node OUs), no further action is required. More information about Node OU support and how to determine whether the MSP is enabled for it is provided in this topic.

The right column shows the certificates that are relevant to the system channel and the application channel. When the MSP is not enabled for Node OU support, additional steps are required to update these certificates on the system and application channels and are provided here.

Because the certificate renewal process is different for peers and ordering nodes, the certificate renewal tooling described in this topic cannot be used on networks where the peers and ordering nodes share the same organization MSP definition.





 Node OU support 

When you register a user with the CA, you need to select a user Type of client, peer, orderer, or admin, that is used to confer a "role" onto the identity. Roles are referred to as Organizational Units (OU) inside a certificate and MSPs can be configured to recognize these roles. The admin and orderer types were added to the IBM Blockchain Platform when Fabric v1.4.3 was included and contains support for Node OUs in MSPs and channels.

This new capability means that when the MSP admin identity is enrolled during MSP creation, the generated signed certificate includes the admin type as an OU inside the certificate. This admin designation means that the signed cert of the identity does not need to be included in the MSP defining the organization. You can learn more about the benefits of Node OUs in the Fabric documentation on the [Membership Service Provider](https://hyperledger-fabric.readthedocs.io/en/release-2.2/membership/membership.htmlnode-ou-roles-and-msps).