vania-janet/multiturn-rag-retrieval-data huggingface dataset:
IBM Cloud Controller Manager v1.17.17-1 v1.17.17-5 Updated image for for [DLA-2509-1](https://www.debian.org/lts/security/2020/dla-2509). 
 IBM Cloud File Storage for Classic plug-in and monitor 385 388 Improved the retry logic for provisioning persistent volume claims (PVCs). 
 IBM Cloud RBAC Operator f859228 86de2b7 Updated to use Go version 1.15.7. 
 Load balancer and load balancer monitor for IBM Cloud Provider 1078 1165 Updated to use Go version 1.15.7. 







 Change log for worker node fix pack 4.3.40_1554_openshift, released 15 February 2021 

The following table shows the changes that are in the worker node fix pack 4.3.40_1554_openshift. Worker node patch updates can be applied by updating, reloading (in classic infrastructure), or replacing (in VPC infrastructure) the worker node.



Changes since version 4.3.40_1553_openshift

 Component Previous Current Description
nvm install v6.17.1

Whichever approach you use after you install Node.js and npm (included with Node) on your computer, congratulate yourself on a job well started!





 Installing Git 

You're probably already familiar with Git, as it's the most widely used source code versioning system. We use Git later when we create a Continuous Deployment (CD) Toolchain in the IBM Cloud Platform for continuous delivery and deployment. If you don't have a GitHub account, create a free public personal account at the [GitHub](https://github.com/join) website; otherwise, feel free to log in with any other account you might have.

We need to generate and upload SSH keys to your [GitHub profile](https://help.github.com/en/articles/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent) for secure access to GitHub from the command line. However, doing that now provides good practice, as you repeat the steps for the instance of GitHub used for the IBM Cloud Platform later.

For now, download the [GitHub Desktop](https://desktop.github.com/) and run the installer. When the installer finishes, log in to GitHub with your account.

Enter a name and email (this is displayed publicly) for any commits to your repository. Once the application is linked to your account, you might be asked to verify the application connection through your GitHub account online.

Zoom

![github_desktop_setup](http://docs-resources.s3.us.cloud-object-storage.appdomain.cloud/web-app-tutorial-001-github-login.png)

Figure 1. GitHub Desktop Login window







 Step 1: Creating the Node.js starter app 

To start developing your application locally, begin by logging in to the IBM Cloud Platform directly from the command line, as shown in the example.
* UI
* CLI
* API







 Sync associated resources 

You can initiate a manual data synchronization request between root keys and other cloud resources, such as IBM Cloud Object Storage buckets or deployments of Cloud Databases, by using the [IBM® Key Protect API](https://cloud.ibm.com/apidocs/key-protect), [IBM Cloud console](https://cloud.ibm.com/login), or the [Key Protect CLI plugin](https://cloud.ibm.com/docs/key-protect?topic=key-protect-key-protect-cli-reference).

When you perform a key lifecycle action (for example rotate, restore, disable, enable, delete) on a root key that is associated with other IBM Cloud services, those IBM Cloud services are notified of the key lifecycle event and are encouraged to respond accordingly. In the case that the cloud services do not respond to the key lifecycle notification, you can use the sync API to initiate of a renotification of the key lifecycle event to those associated cloud services.

It can take up to four hours for services to respond to events and sync requests.

For example, you might delete a root key that has an association with IBM Cloud Object Storage (COS). After waiting 4 hours for changes to take effect, you notice that you are still able to access the key's resources despite expecting to be blocked from accessing those resources. In this case, you should call the sync API to notify COS of the deleted key lifecycle event so they can block access to the key's resources.

The sync API only initiates a request for synchronization. The IBM Cloud services associated with the key are responsible for managing all related associated resources and ensuring that the key state and key versions are up to date.



 Syncing associated resources with the Key Protect console 



1. [Log in to the IBM Cloud console](https://cloud.ibm.com/login/).
2. Go to Menu > Resource List to view a list of your resources.
3. From your IBM Cloud resource list, select your provisioned instance of Key Protect.
4.
After a worker node updates or reloads, why do duplicate nodes and pods appear? 

Virtual Private Cloud

Classic infrastructure

  What’s happening 

When you run kubectl get nodes, you see duplicate worker nodes with the status NotReady. The worker nodes with NotReady have public IP addresses, while the worker nodes with Ready have private IP addresses.

  Why it’s happening 

Older clusters listed worker nodes by the cluster's public IP address. Now, worker nodes are listed by the cluster's private IP address. When you reload or update a node, the IP address is changed, but the reference to the public IP address remains.

  How to fix it 

Service is not disrupted due to these duplicates, but you can remove the old worker node references from the API server.

kubectl delete node <node_name1> <node_name2>
Follow the instructions in the [Build a network tutorial](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-console-build-networkibp-console-build-network-create-peer-org1) to create a new peer identity with the correct type and peer.





 Why is my peer unable to communicate with my ordering node? 

 What’s happening 

A peer node has a timeout or connection refused error when trying to communicate with the orderer.

 Why it’s happening 

This problem can occur due to the network policies applied by the operator, which occurs when the environment variable IBPOPERATOR_CONSOLE_APPLYNETWORKPOLICY is set to "true".

 How to fix it 

[Disable the network policies in your namespace](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-v2-troubleshootingibp-v2-troubleshooting-disable-network-policies). This should resolve connectivity issues with your nodes.





 When I hover over my node, the status is red, what does this mean? 

 What’s happening 

A CA, peer, or ordering node has a red status box, meaning there may be connectivity issues with the node. Ideally, when you hover over any node, the node status should be Running.

 Why it’s happening 

This problem can occur due to the network policies applied by the operator, which occurs when the environment variable IBPOPERATOR_CONSOLE_APPLYNETWORKPOLICY is set to "true".

 How to fix it 

[Disable the network policies in your namespace](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-v2-troubleshootingibp-v2-troubleshooting-disable-network-policies). This should resolve connectivity issues with your nodes.





 How do I disable the network policies in my namespace? 

 What’s happening 

You may need to disable the network policies in your namespace to address connectivity issues in your network.

 How to fix it
The instructions below demonstrate some sample code to implement an endpoint handler to send notifications via PagerDuty in an IBM Cloud Function, but you could also adapt this code to run in a location of your choice

Note: the below function is written in Node.js

const https = require('https');

function main(params) {

return new Promise((resolve, reject) => {

// Replace the string "R4nd0m5tr1ng0fCh4r4ct3r5" with your own value to secure access to your own specific endpoint
// An example to implement the query parameter '?token=R4nd0m5tr1ng0fCh4r4ct3r5'
if (params.token !== "R4nd0m5tr1ng0fCh4r4ct3r5") {
process.exit();
}

const pdparams = {
"service_key": "<PagerDuty service key>",
"description": params.description,
"event_type": "trigger"
}

const options = {
hostname: 'events.pagerduty.com',
port: 443,
path: '/generic/2010-04-15/create_event.json',
method: 'POST'
}

const req = https.request(options, (resp) => {
let data = '';
resp.on('data', (chunk) => {
data += chunk;
});

resp.on('end', () => {
const info = JSON.parse(data);
console.log(info);
params.info = info;
resolve(params);
});

}).on("error", (err) => {
console.log(err);
reject({
statusCode: 500,
headers: {'Content-type': 'application/json'},
ibmc-vpcblock-snapshot true csi-block-pvc 1Gi ibmc-vpcblock-snapshot snapcontent-9c374fbf-43a6-48d6-afc5-e76e1ab7c12b 18h 18h







 Restoring from a volume snapshot 

After you deploy the snapshot resources, you can restore data to a new volume by using the snapshot. Creating a PVC dynamically provisions a new volume with snapshot data.



1. Create a second PVC that references your volume snapshot.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: restore-pvc
spec:
storageClassName: ibmc-vpc-block-5iops-tier
dataSource:
name: snapshot-csi-block-pvc
kind: VolumeSnapshot
apiGroup: snapshot.storage.k8s.io
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi
2. Verify that the PVC is created and is in a Bound state.

kubectl get pvc

NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
restore-pvc Bound pvc-4ede7630-5a49-4bae-b34d-dc528acfb884 10Gi RWO ibmc-vpc-block-5iops-tier 18h
3. Create a second YAML configuration file for a deployment that mounts the PVC that you created.

apiVersion: apps/v1
kind: Deployment
metadata:
name: podtwo
labels:
app: podtwo
spec:
replicas: 1
selector:
matchLabels:
app: podtwo
template:
metadata:
labels:
app: podtwo
spec:
containers:
- image: nginx Your containerized app image
name: container-name
volumeMounts:
- mountPath: /myvolumepath Mount path for pvc from container
IBM Cloud File Storage for Classic plug-in and monitor 425 427 Updated universal base image (UBI) to resolve CVEs. 
 Key Management Service provider v2.5.13 v2.6.3 Updated Go dependencies and to Go version 1.19.6. 
 Konnectivity agent and server v0.0.34_491_iks v0.1.1_569_iks-amd64 Updated to Konnectivity version v0.1.0. 
 Kubernetes NodeLocal DNS cache 1.22.11 1.22.18-amd64 See the [Kubernetes NodeLocal DNS cache release notes](https://github.com/kubernetes/dns/releases/tag/1.22.18). 
 Load balancer and Load balancer monitor for IBM Cloud Provider 2325 2383 Updated to armada-utils version 1.9.35. 
 Portieris admission controller v0.12.6 v0.13.3 See the [Portieris admission controller release notes](https://github.com/IBM/portieris/releases/tag/v0.13.3). 







 Change log for worker node fix pack 1.23.16_1563, released 27 February 2023 

The following table shows the changes that are in the worker node fix pack 1.23.16_1563. Worker node patch updates can be applied by updating, reloading (in classic infrastructure), or replacing (in VPC infrastructure) the worker node.



Changes since version 1.23.16_1562

 Component Previous Current Description 

 containerd v1.6.17 v1.6.18 See the [1.6.18 change log](https://github.com/containerd/containerd/releases/tag/v1.6.18) and the [security bulletin for CVE-2023-25153 and CVE-2023-25173](https://www.ibm.com/support/pages/node/6960181).
For more information, see [Getting started with Terraform](https://cloud.ibm.com/docs/ibm-cloud-provider-for-terraform?topic=ibm-cloud-provider-for-terraform-getting-started).
* [Create](https://cloud.ibm.com/docs/vpc?topic=vpc-snapshots-vpc-createsnapshots-vpc-create) your snapshots.
* [View](https://cloud.ibm.com/docs/vpc?topic=vpc-snapshots-vpc-viewsnapshots-vpc-view) and [manage](https://cloud.ibm.com/docs/vpc?topic=vpc-snapshots-vpc-managesnapshots-vpc-manage) your snapshots.
* [Restore](https://cloud.ibm.com/docs/vpc?topic=vpc-snapshots-vpc-restoresnapshots-vpc-restore) a volume from a snapshot.







 Restore a volume from a snapshot 

You can create a volume from a snapshot at any time. This process, called restoring a volume, can be performed when you create an instance, modify an instance, or when you create a stand-alone volume (no instance provisioning is required). Volume data restoration begins immediately as the volume is hydrated, but performance is degraded until the volume is fully restored. The volume does not need to be attached to an instance. For more information, see [Restoring a volume from a snapshot](https://cloud.ibm.com/docs/vpc?topic=vpc-snapshots-vpc-restore).





 Fast restore snapshot clones 

By using the snapshots fast restore feature, you create and keep a clone of the data in a zone within your VPC region. In other words, your data is fully available when the volume is created because it is already in the VPC region and not in Object Storage.
* The parent cannot be a node of type response_condition or event_handler.



The resulting dialog looks like this:

![Example dialog 3](https://cloud.ibm.com/docs-content/v1/content/417db917d18067d9dcc4cf2612564a9a87c3ddc8/assistant/images/dialog_api_3.png)

In addition to creating node_9, the service automatically updates the previous_sibling property of node_6 so that it points to the new node.





 Moving a node to a different parent 

Let's move node_5 to a different parent by using the POST /dialog_nodes/node_5 method with the following body:

{
"parent": "node_1"
}

The specified value for parent must be valid:



* It must refer to an existing node.
* It must not refer to the node being modified (a node cannot be its own parent).
* It must not refer to a descendant of the node being modified.
* It must not refer to a node of type response_condition or event_handler.



This results in the following changed structure:

![Example dialog 4](https://cloud.ibm.com/docs-content/v1/content/417db917d18067d9dcc4cf2612564a9a87c3ddc8/assistant/images/dialog_api_4.png)

Several things have happened here:



* When node_5 moved to its new parent, node_7 went with it (because the parent value for node_7 did not change). When you move a node, all descendants of that node stay with it.
* Because we did not specify a previous_sibling value for node_5, it is now the first sibling under node_1.
* The previous_sibling property of node_4 was updated to node_5.
* The previous_sibling property of node_9 was updated to null, because it is now the first sibling under node_2.







 Resequencing siblings
* The hub is a central point of traffic routing between enterprise and the cloud.
* Enterprise to cloud traffic is routed through the hub, and can be monitored, and logged through Network Function Virtualization (NFV) appliance running inside the hub.
* The hub can monitor all or some of the traffic - spoke <-> spoke, spoke <-> transit, or spoke <-> enterprise.
* The hub can be the repository for shared microservices used by spokes.
* The hub can be the repository for shared cloud resources, like databases, accessed through [virtual private endpoint gateways](https://cloud.ibm.com/docs/vpc?topic=vpc-about-vpe) controlled with VPC security groups and subnet access control lists, shared by spokes.
* The hub can hold the VPN resources that are shared by the spokes.



([Part two](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-vpc-transit2)) will extend this tutorial by routing all VPC to VPC traffic through the hub, implement a highly available firewall-router and route traffic to IBM Cloud service instances with DNS resolution.

There is a companion [GitHub repository](https://github.com/IBM-Cloud/vpc-transit) that provisions resources and configures routing in incremental layers. In the tutorial thin layers enable the introduction of bite size challenges and solutions.

During the journey the following are explored:



* [VPC Network planning](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-addressing-plan-design).
* [VPC egress and ingress routing](https://cloud.ibm.com/docs/vpc?topic=vpc-about-custom-routes).
* Connectivity via [IBM Cloud® Direct Link](https://www.ibm.com/cloud/direct-link).
* Connectivity via [IBM Cloud Transit Gateway](https://www.ibm.com/cloud/transit-gateway).
The [cross-regional copy](https://cloud.ibm.com/docs/vpc?topic=vpc-backup-service-aboutbackup-service-crc) can be used in disaster recovery scenarios when you need to turn on your virtual server instance and data volumes in a different region. The remote copy can be created automatically as part of a backup plan, or manually later.

With the fast restore feature, you can cache snapshots in a specified zone of your choosing. This way, volumes can be restored from snapshots nearly immediately and the new volumes operate with full IOPS instantly. The fast restore feature can achieve a

recovery time objective(RTO) quicker than restoring from a regular backup snapshot. When you opt for fast restore, your existing regional plan is adjusted, including billing. For more information about the cost of fast restore, see [Pricing](https://www.ibm.com/cloud/vpc/pricing).



 Comparison of backups and snapshots 

Backups are in effect, backup snapshots. In the console, backups appear in the list of Block Storage for VPC snapshots. Backups are identified by how they were created, in this case, by backup policy. These terms are used interchangeably in the Documentation, depending on the context.

The snapshots service is used to create backups, similarities and differences exist between backups and snapshots. Table 1 compares backups to snapshots.



Table 1. Comparison of backups and snapshots

 Feature Backup Snapshot 

 Backs up Block Storage for VPC boot and data volumes. ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/f02b9c9adcbb7328d95a45e105cec371d50f15eb/icons/checkmark-icon.svg) !
-uri $uri -body $xmlPayload -connection $nsxConnection

 Disconnect
Disconnect-NsxServer
Show more





 Related links 



* [Red Hat OpenShift Bastion node setup](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-openshift-runbook-runbook-bastion-intro)
* [Red Hat OpenShift 4.7 user provider infrastructure installation](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-openshift-runbook-runbook-install-intro)
Updated the node-local-dns daemon set to include the prometheus.io/port and prometheus.io/scrape annotations on the pods. 
 Load balancer and load balancer monitor for IBM Cloud Provider Master 177 208 Updated the version 2.0 network load balancers (NLB) to clean up unnecessary IPVS rules. Improved application logging. Updated image for [CVE-2020-1967](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1967). 
 Ubuntu 18.04 packages Worker 4.15.0-99-generic 4.15.0-101-generic Updated worker node images with kernel and package updates for [CVE-2019-20795](https://nvd.nist.gov/vuln/detail/CVE-2019-20795), [CVE-2020-11494](https://nvd.nist.gov/vuln/detail/CVE-2020-11494), [CVE-2020-12762](https://nvd.nist.gov/vuln/detail/CVE-2020-12762), [CVE-2020-3810](https://nvd.nist.gov/vuln/detail/CVE-2020-3810), [CVE-2020-8616](https://nvd.nist.gov/vuln/detail/CVE-2020-8616), and [CVE-2020-8617](https://nvd.nist.gov/vuln/detail/CVE-2020-8617).
Cluster health image v1.1.11 v1.1.12 Updated to use Go version 1.15.2. 
 Gateway-enabled cluster controller 1082 1105 Updated to use Go version 1.15.2. 
 IBM Cloud Controller Manager v1.18.9-1 v1.18.10-1 Updated to support the Kubernetes 1.18.10 release. 
 IBM Cloud RBAC Operator 4b47693 31c794a Updated to use Go version 1.15.2. 
 Kubernetes v1.18.9 v1.18.10 See the [Kubernetes release notes](https://github.com/kubernetes/kubernetes/releases/tag/v1.18.10). 
 Kubernetes NodeLocal DNS cache 1.15.13 1.15.14 See the [Kubernetes NodeLocal DNS cache release notes](https://github.com/kubernetes/dns/releases/tag/1.15.14). 







 Change log for worker node fix pack 1.18.9_1530, released 12 October 2020 

The following table shows the changes that are in the worker node fix pack 1.18.9_1530. Worker node patch updates can be applied by updating, reloading (in classic infrastructure), or replacing (in VPC infrastructure) the worker node.



Changes since version 1.18.8_1529

 Component Previous Current Description 

 Ubuntu 18.04 packages N/A N/A Updated worker node image with package updates for [CVE-2019-8936](https://nvd.nist.gov/vuln/detail/CVE-2019-8936), [CVE-2020-26137](https://nvd.nist.gov/vuln/detail/CVE-2020-26137), and [CVE-2020-14365](https://nvd.nist.gov/vuln/detail/CVE-2020-14365).
[Create a NodePort service](https://cloud.ibm.com/docs/openshift?topic=openshift-nodeport).<br>2. A NodePort service opens a port on a worker node over both the private and public IP address of the worker node. You must use a [Calico preDNAT network policy](https://cloud.ibm.com/docs/openshift?topic=openshift-network_policiesblock_ingress) to block traffic to the public NodePorts.<br><br><br> 
 NLB 1.0 Basic load balancing that exposes the app with a private IP address Quickly expose one app to a private network with a private IP address. <br><br>1. [Create a private NLB service](https://cloud.ibm.com/docs/openshift?topic=openshift-loadbalancer). An NLB with a portable private IP address still has a public node port open on every worker node.<br>2. Create a [Calico preDNAT network policy](https://cloud.ibm.com/docs/openshift?topic=openshift-network_policiesblock_ingress) to block traffic to the public NodePorts.<br><br><br> 
 NLB v2.0 DSR load balancing that exposes the app with a private IP address Expose an app that might receive high levels of traffic to a private network with an IP address. <br><br>1. Complete the [prerequisites](https://cloud.ibm.com/docs/openshift?topic=openshift-loadbalancer-v2ipvs_provision).<br>2.
Internally, Edge functions use the same V8 JavaScript engine, which is used in the Chrome browser to run workers on our infrastructure. V8 dynamically compiles your JavaScript code into ultra-fast machine code, enhancing performance. This makes it possible for your code to run in microseconds, and for our edge server to run many thousands of scripts per second.

While Edge functions does use V8, it does not use Node.js. The JavaScript APIs available to you inside workers are implemented by us directly. Working with V8 directly allows the code to run more efficiently and with the security controls needed to keep the customers and the infrastructure safe.





 Working with Edge functions request properties 

Here, we discuss the Cloudflare runtime APIs for CIS Edge functions. The Edge functions runtime provides the following Cloudflare APIs for use by scripts running at the cloud edge.



 Constructor syntax 

new Request(input [, init])





 Constructor parameters 



* input: Can be either a USVString that contains the URL, or an existing Request object. Note that the url property is immutable, so when modifying a request and changing the URL, you must pass the new URL in this parameter.
* init (optional): An options object that contains custom settings to apply to the request. Valid options are:



* method: The request method, such as GET or POST
* headers: A Headers object



* body: Any text to add to the request. Requests using the GET or HEAD methods cannot have a body.
* redirect: The mode respected when the request is fetched. The default for requests generated from the incoming fetchEvent from the event handler is manual. Default for newly constructed Requests (in other words, new Request (url) ) is follow. Valid options:



* follow: If a redirect response is returned to the fetch, another fetch is fired based on the Location header in the response until a non-redirect code is returned. For example, await fetch(..) could never return a 301 redirect.
* manual: redirect responses return from a fetch.













 Properties