vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Change log for worker node fix pack 1.17.5_1524, released 11 May 2020 

The following table shows the changes that are in the worker node fix pack 1.17.5_1524. 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.17.4_1523

 Component Previous Current Description 

 Ubuntu 18.04 packages 4.15.0-96-generic 4.15.0-99-generic Updated worker node images with kernel and package updates for [CVE-2019-19768](https://nvd.nist.gov/vuln/detail/CVE-2019-19768), [CVE-2020-11884](https://nvd.nist.gov/vuln/detail/CVE-2020-11884), and [CVE-2020-12243](https://nvd.nist.gov/vuln/detail/CVE-2020-12243). 
 Ubuntu 16.04 packages 4.4.0-177-generic 4.4.0-178-generic Updated worker node images with package and kernel updates for [CVE-2019-19768](https://nvd.nist.gov/vuln/detail/CVE-2019-19768) and [CVE-2020-12243](https://nvd.nist.gov/vuln/detail/CVE-2020-12243). 







 Change log for worker node fix pack 1.17.5_1523, released 27 April 2020 

The following table shows the changes that are in the worker node fix pack 1.17.5_1523. 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.17.4_1521

 Component Previous Current Description 

 containerd v1.3.3 v1.3.4 See the [containerd release notes](https://github.com/containerd/containerd/releases/tag/v1.3.4).
* If you don't use edge nodes: Ensure that at least two worker nodes exist in each zone by [resizing an existing worker pool](https://cloud.ibm.com/docs/containers?topic=containers-add_workersresize_pool), [creating a new worker pool in a VPC cluster](https://cloud.ibm.com/docs/containers?topic=containers-add_workersvpc_add_pool), or [creating a new worker pool in a classic cluster](https://cloud.ibm.com/docs/containers?topic=containers-add_workersadd_pool).
* If you use edge nodes: Ensure that at least two [edge worker nodes](https://cloud.ibm.com/docs/containers?topic=containers-edge) are enabled in each zone.



* Classic clusters only: If more than one worker node exists in each zone of your classic cluster, your worker nodes might be connected to different VLANs within one zone so that only one worker node exists on a private VLAN. Continue to the next step.



2. For each worker node in one zone, get the private VLAN that the worker node is attached to.

ibmcloud ks worker get -w <worker_ID> -c <cluster_name_or_ID>
3. If only one worker node exists on a private VLAN, and the other worker nodes in the zone are attached to a different private VLAN, [create a new worker pool](https://cloud.ibm.com/docs/containers?topic=containers-add_workersadd_pool) with a size of at least one worker node. When you add a zone to the worker pool in step 6, specify the same zone and private VLAN as the worker node that you previously identified.
4. Repeat these steps for each zone in your cluster to ensure that more than one worker node exists on a private VLAN.



After the new worker nodes deploy, the ALB pods are automatically scheduled to deploy to those worker nodes.
containers-kubernetes.cluster-worker-pool-zone-network.add The networking data, such as public and private VLAN data, is added for a zone that the worker pool spans. 
 containers-kubernetes.cluster-worker-pool-zone-worker.list The worker nodes within a zone that a the worker pool spans are listed as part of cluster autoscaler operations. 
 containers-kubernetes.worker.delete A worker node is deleted from the cluster. 
 containers-kubernetes.worker.get The details of a worker node in the cluster are returned. 
 containers-kubernetes.worker.reboot A worker node is rebooted. 
 containers-kubernetes.worker.reload A worker node is reloaded. 
 containers-kubernetes.worker.replace A worker node is removed and another worker node of the same flavor is created in the cluster. 
 containers-kubernetes.worker.update A worker node version is updated. 







 Viewing your cluster events 

To [view events](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-view_events) that are sent to IBM Cloud Activity Tracker, you select the Activity Tracker instance that matches with the location of your IBM Cloud Kubernetes Service cluster.

The following table shows the Activity Tracker location where your events are sent to. To view your events, make sure that you have an Activity Tracker instance in the location that matches your cluster location. Note that clusters in the Montreal, Toronto, and Washington, D.C. locations forward all events to the Dallas Activity Tracker location.



Corresponding Activity Tracker instance and IBM Cloud Kubernetes Service cluster locations.

 IBM Cloud Kubernetes Service classic location Activity Tracker event location 

 Dallas (dal10, dal12, dal13) Dallas 
 Montreal (mon01) Washington, D.C. 
 San Jose (sjc03, sjc04) Dallas 
 São Paulo (sao01) Dallas 
 Toronto (tor01) Toronto 
 Washington, D.C. (wdc04, wdc06, wdc07) Washington, D.C. 
 Amsterdam (ams03) Frankfurt
Before you install ODF, get the details of the local disks on your worker nodes.



1. Log in to your cluster and get a list of available worker nodes. Make a note of the worker nodes that you want to use in your OCS deployment.

oc get nodes
2. Log in to each worker node that you want to use for your ODF.

oc debug node/<node-name>
3. After you deploy the debug pod on the worker node, run the following command to allow host binaries.

chroot /host
4. List the available disks on the worker node.

lsblk
5. Review the command output for available disks. You can use only unmounted disks for ODF deployments, such as sdc disks in the following example. Note the initial storage capacity of your ODF deployment is equal to the size of the disk that you specify as the osd-device-path. In this example, the sdc disk is unmounted and has two available partitions: sdc1 and sdc2.

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931G 0 disk
|-sda1 8:1 0 256M 0 part /boot
|-sda2 8:2 0 1G 0 part
-sda3 8:3 0 929.8G 0 part /
sdb 8:16 0 744.7G 0 disk
-sdb1 8:17 0 744.7G 0 part /disk1
sdc 8:32 0 744.7G 0 disk
|-sdc1 8:33 0 18.6G 0 part
-sdc2 8:34 0 260.8G 0 part
6. For each unmounted disk that you want to use in your deployment, find the disk ID.
To retrieve these values, run kubectl get nodes -o jsonpath="{.items[].metadata.labels.ibm-cloud.kubernetes.io/os}{'n'}". Store the operating system of the worker nodes in an environment variable. For IBM Cloud Kubernetes Service clusters, run SET WORKER_OS="debian" and SET PLATFORM="k8s".

REGION
: The region of the worker nodes. To retrieve this value, run kubectl get nodes -o yaml | grep 'ibm-cloud.kubernetes.io/region'. Store the region of the worker nodes in an environment variable by running SET REGION="< region>".



 Updating the IBM Cloud Object Storage plug-in 

You can upgrade the existing IBM Cloud Object Storage plug-in to the most recent version.



1. Get the name of your IBM Cloud Object Storage plug-in Helm release and the version of the plug-in in your cluster.

helm ls -A | grep object

Example output

NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
<release_name> <namespace> 1 2020-02-13 16:05:58.599679 -0500 EST deployed ibm-object-storage-plugin-1.1.2 1.1.2
2. Update the IBM Cloud Helm repo to retrieve the most recent version of all Helm charts in this repo.

helm repo update
3. Update the IBM Cloud Object Storage ibmc Helm plug-in to the most recent version.

helm ibmc --update
4. Install the most recent version of the ibm-object-storage-plugin for your operating system.

Example helm ibmc upgrade command for OS X and Linux.

helm ibmc upgrade ibm-object-storage-plugin ibm-helm/ibm-object-storage-plugin --set license=true [--set bucketAccessPolicy=false]

Example helm upgrade command for Windows.
* Check any Calico or Kubernetes network policies that are applied to the cluster and make sure that they do not block traffic from the worker node to the cluster apiservice, container registry, or other critical services.



2. Check if the applications, security, or monitoring components in your cluster are overloading the cluster apiserver with requests, which may cause disruptions for your worker nodes.
3. If you recently added any components to your cluster, remove them. If you made changes to any existing components in your cluster, revert the changes. Then, check the status of your worker nodes to see if the new components or changes were causing the issue.
4. Check for changes on any cluster webhooks, which can disrupt apiserver requests or block a worker node's ability to connect with the apiserver. [Remove all webhooks](https://cloud.ibm.com/docs/containers?topic=containers-ts-delete-webhooks) that were added to the cluster after it was created.
5. Check the status of your worker nodes. If they are in a Normal state, add back any deleted components and re-create any reverted changes, one by one, until you can determine which configuration or component caused the worker node disruption.
6. If the issue is still not resolved, follow the steps to [gather your worker node data](https://cloud.ibm.com/docs/containers?topic=containers-ts-critical-notreadyts-critical-notready-gather) and open a support ticket.







 If worker nodes switch between normal and critical states 

If your worker nodes switch between a Normal and Critical or NotReady state, check the following components for any issues or recent changes that may disrupt your worker nodes.



1. For classic clusters, check your firewalls or gateways. If there is a bandwidth limit or any type of malfunction, resolve the issue. Then, check your worker nodes again.
2. Check if the applications, security, or monitoring components in your cluster are overloading the cluster apiserver with requests, which may cause disruptions for your worker nodes.
3.
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.15_1556

 Component Previous Current Description 

 Ubuntu 18.04 packages N/A N/A N/A 
 Ubuntu 20.04 packages N/A N/A N/A 
 Kubernetes N/A N/A N/A 







 Change log for worker node fix pack 1.23.15_1556, released 19 December 2022 

The following table shows the changes that are in the worker node fix pack 1.23.15_1556. 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.14_1554

 Component Previous Current Description 

 Containerd 1.6.10 1.6.12 See the [1.6.12 change log](https://github.com/containerd/containerd/releases/tag/v1.6.12), the [1.6.11 change log](https://github.com/containerd/containerd/releases/tag/v1.6.11), and the security bulletin for [CVE-2022-23471](https://www.ibm.com/support/pages/node/6850799).
You can monitor the provisioning process in the Status column of your CLI output. If your worker node is stuck in this state for a long time, check whether a problem occurred during the provisioning.





 Provision pending state 

You can view the current worker node state by running the ibmcloud ks worker ls --cluster <cluster_name_or_ID> command and locating the State and Status fields.

A Provision pending state means that another process is completing before the worker node provisioning process starts. You can monitor the other process that must complete first in the Status column of your CLI output. For example, in VPC clusters, the Pending security group creation indicates that the security group for your worker nodes is creating first before the worker nodes can be provisioned. If your worker node is stuck in this state for a long time, check whether a problem occurred during the other process.





 Provision_failed state 

You can view the current worker node state by running the ibmcloud ks worker ls --cluster <cluster_name_or_ID> command and locating the State and Status fields.

Your worker node could not be provisioned. List the details for the worker node to find the details for the failure by running ibmcloud ks worker get --cluster <cluster_name_or_id> --worker <worker_node_id>.





 Reloading state 

You can view the current worker node state by running the ibmcloud ks worker ls --cluster <cluster_name_or_ID> command and locating the State and Status fields.

A Reloading state means that your worker node is being reloaded and is not available in the cluster. You can monitor the reloading process in the Status column of your CLI output. If your worker node is stuck in this state for a long time, check whether a problem occurred during the reloading.





 Reloading_failed state 

You can view the current worker node state by running the ibmcloud ks worker ls --cluster <cluster_name_or_ID> command and locating the State and Status fields.

A Reloading_failed state means that your worker node could not be reloaded.
* [Updating VPC worker nodes in the console](https://cloud.ibm.com/docs/containers?topic=containers-updatevpc_worker_ui)



* [Updating flavors (machine types)](https://cloud.ibm.com/docs/containers?topic=containers-updatemachine_type)
* [Updating cluster components](https://cloud.ibm.com/docs/containers?topic=containers-updatecomponents)



* [Managing automatic updates for Fluentd](https://cloud.ibm.com/docs/containers?topic=containers-updatelogging-up)
* [Managing automatic updates for Ingress ALBs](https://cloud.ibm.com/docs/containers?topic=containers-updatealb)



* [Updating managed add-ons](https://cloud.ibm.com/docs/containers?topic=containers-updateaddons)
* [Updating from stand-alone worker nodes to worker pools](https://cloud.ibm.com/docs/containers?topic=containers-updatestandalone_to_workerpool)



[Tuning performance](https://cloud.ibm.com/docs/containers?topic=containers-kernelkernel)



* [Default worker node settings](https://cloud.ibm.com/docs/containers?topic=containers-kernelworker-default)



* [Customizing the operating system](https://cloud.ibm.com/docs/containers?topic=containers-kernelworker-default-os)
* [Hardware changes](https://cloud.ibm.com/docs/containers?topic=containers-kernelworker-default-hw)



* [Modifying worker node settings to optimize performance](https://cloud.ibm.com/docs/containers?topic=containers-kernelworker)



* [Modifying worker node kernel settings](https://cloud.ibm.com/docs/containers?topic=containers-kernelworker-kernel-ds)
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.25.5_1526

 Component Previous Current Description 

 Ubuntu 18.04 packages N/A N/A N/A 
 Ubuntu 20.04 packages N/A N/A N/A 
 Kubernetes N/A N/A N/A 







 Change log for worker node fix pack 1.25.5_1526, released 19 December 2022 

The following table shows the changes that are in the worker node fix pack 1.25.5_1526. 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.25.4_1524

 Component Previous Current Description 

 Containerd 1.6.10 1.6.12 See the [1.6.12 change log](https://github.com/containerd/containerd/releases/tag/v1.6.12), the [1.6.11 change log](https://github.com/containerd/containerd/releases/tag/v1.6.11), and the security bulletin for [CVE-2022-23471](https://www.ibm.com/support/pages/node/6850799).
Adding worker nodes and zones to clusters 

To increase the availability of your apps, you can add worker nodes to an existing zone or multiple existing zones in your cluster. To help protect your apps from zone failures, you can add zones to your cluster.

When you create a cluster, the worker nodes are provisioned in a worker pool. After cluster creation, you can add more worker nodes to a pool by resizing it or by adding more worker pools. By default, the worker pool exists in one zone. Clusters that have a worker pool in only one zone are called single zone clusters. When you add more zones to the cluster, the worker pool exists across the zones. Clusters that have a worker pool that is spread across more than one zone are called multizone clusters.

If you have a multizone cluster, keep its worker node resources balanced. Make sure that all the worker pools are spread across the same zones, and add or remove workers by resizing the pools instead of adding individual nodes. After you set up your worker pool, you can [set up the cluster autoscaler](https://cloud.ibm.com/docs/containers?topic=containers-cluster-scaling-classic-vpc) to automatically add or remove worker nodes from your worker pools based on your workload resource requests.



 Adding worker nodes by resizing an existing worker pool 

You can add or reduce the number of worker nodes in your cluster by resizing an existing worker pool, regardless of whether the worker pool is in one zone or spread across multiple zones.

For example, consider a cluster with one worker pool that has three worker nodes per zone.



* If the cluster is single zone and exists in dal10, then the worker pool has three worker nodes in dal10. The cluster has a total of three worker nodes.
* If the cluster is multizone and exists in dal10 and dal12, then the worker pool has three worker nodes in dal10 and three worker nodes in dal12. The cluster has a total of six worker nodes.



For bare metal worker pools, keep in mind that billing is monthly. If you resize up or down, it impacts your costs for the month.
[Worker node states](https://cloud.ibm.com/docs/openshift?topic=openshift-worker-node-state-referenceworker-node-state-reference)



* [Critical state](https://cloud.ibm.com/docs/openshift?topic=openshift-worker-node-state-referenceworker-node-critical)
* [Deleting state](https://cloud.ibm.com/docs/openshift?topic=openshift-worker-node-state-referenceworker-node-deleting)
* [Deleted state](https://cloud.ibm.com/docs/openshift?topic=openshift-worker-node-state-referenceworker-node-deleted)
* [Deployed state](https://cloud.ibm.com/docs/openshift?topic=openshift-worker-node-state-referenceworker-node-deployed)
* [Deploying state](https://cloud.ibm.com/docs/openshift?topic=openshift-worker-node-state-referenceworker-node-deploying)
* [Deploy_failed state](https://cloud.ibm.com/docs/openshift?topic=openshift-worker-node-state-referenceworker-node-deploy-failed)
* [Normal state](https://cloud.ibm.com/docs/openshift?topic=openshift-worker-node-state-referenceworker-node-normal)
* [Provisioned state](https://cloud.ibm.com/docs/openshift?topic=openshift-worker-node-state-referenceworker-node-provisioned)
* [Provisioning state](https://cloud.ibm.com/docs/openshift?topic=openshift-worker-node-state-referenceworker-node-provisioning)
When you create your file storage configuration, you must specify which devices that you want to use. The device paths that you retrieve in the following steps are specified as parameters when you create your configuration.



1. Log in to your cluster and get a list of available worker nodes. Make a note of the worker nodes that you want to use in your configuration.

oc get nodes
2. Log in to each worker node that you want to use for your local storage configuration.

oc debug node/<node-name>
3. When the debug pod is deployed on the worker node, run the following commands to list the available disks on the worker node.



1. Allow host binaries.

chroot /host
2. List your devices.

lsblk
3. Get the details of your devices. Verify that the devices that you want to use are unmounted and unformatted.

fdisk -l



4. Review the command output for available disks. You must use unmounted disks for the local storage configuration. In the following example output from the lsblk command, the xvdc disk is unmounted and has no partitions.

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 100G 0 disk
|-xvda1 202:1 0 1G 0 part /boot
-xvda2 202:2 0 99G 0 part /
xvdb 202:16 0 2G 0 disk
-xvdb1 202:17 0 2G 0 part
xvdc 202:32 0 100G 0 disk
xvde 202:64 0 50G 0 disk /var/data
xvdh 202:112 0 64M 0 disk
5. Repeat the previous steps for each worker node that you want to use for your local file storage configuration.







 Labeling your worker nodes when using local file storage
ibmcloud iam oauth-tokens
5. Retrieve the ID of the worker node that you want to attach to the Block Storage for Classic instance. Make sure to select a worker node that is located in the same zone as your Block Storage for Classic volume.

ibmcloud ks worker ls --cluster <cluster_name_or_ID>
6. Use a POST request to attach your Block Storage for Classic volume to the worker node.

Example request

curl -X POST "https://containers.cloud.ibm.com/global/v2/storage/createAttachment" -H "accept: application/json" -H "Authorization: <IAM_token>" -H "X-Auth-Resource-Group-ID: <resource_group>" -H "Content-Type: application/json" -d "{ "cluster": "<cluster_name_or_ID>", "volumeID": "<volume_ID>", "worker": "<worker_ID>"}"

IAM_token
: The IAM OAuth token for your current session. You can retrieve this value by running ibmcloud iam oauth-tokens.

cluster_name_or_ID
: The unique ID or the name that is assigned to your cluster. You can retrieve this ID by running ibmcloud ks cluster ls.

worker_ID
: The unique ID that is assigned to the worker node where you want to attach your volume. You can retrieve this value by running ibmcloud ks worker ls -c <cluster_name>.

volume_ID
: The unique ID that is assigned to your Block Storage for Classic volume. You can retrieve a list of your Block Storage for Classic volumes by running ibmcloud is volumes.

Example response.

{
"id": "0111-1aaa11a1-aa1a-111a-111b-1111a1dad1bc",
"volume": {
"name": "my-vol",
Change log for worker node fix pack 1.17.9_1535, released 3 August 2020 

The following table shows the changes that are in the worker node fix pack 1.17.9_1535. 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.17.9_1532

 Component Previous Current Description 

 Ubuntu 18.04 packages 4.15.0-111-generic 4.15.0-112-generic Updated worker node images with kernel and package updates for [CVE-2019-17514](https://nvd.nist.gov/vuln/detail/CVE-2019-17514), [CVE-2019-20907](https://nvd.nist.gov/vuln/detail/CVE-2019-20907), [CVE-2019-9674](https://nvd.nist.gov/vuln/detail/CVE-2019-9674), [CVE-2020-10713](https://nvd.nist.gov/vuln/detail/CVE-2020-10713), [CVE-2020-10757](https://nvd.nist.gov/vuln/detail/CVE-2020-10757), [CVE-2020-11935
* [Worker node](https://cloud.ibm.com/docs/containers?topic=containers-securityworkernodes)



* [Who owns the worker node and am I responsible to secure it?](https://cloud.ibm.com/docs/containers?topic=containers-securityworker-node-owner)
* [How does my worker node setup look?](https://cloud.ibm.com/docs/containers?topic=containers-securityworker-node-setup)



* [Network](https://cloud.ibm.com/docs/containers?topic=containers-securitynetwork)



* [Network segmentation and privacy for classic clusters](https://cloud.ibm.com/docs/containers?topic=containers-securitynetwork_segmentation)
* [What network traffic is allowed for my Classic cluster by default?](https://cloud.ibm.com/docs/containers?topic=containers-securitydefault-network-traffic-allowed)
* [What is network segmentation and how can I set it up for a Classic cluster?](https://cloud.ibm.com/docs/containers?topic=containers-securitynetwork-segmentation-setup)
* [What else can I do to reduce the surface for external attacks for Classic clusters?](https://cloud.ibm.com/docs/containers?topic=containers-securityexternal-what-else)
* [What if I want to connect my cluster to an on-prem data center?](https://cloud.ibm.com/docs/containers?topic=containers-securityonprem-network-setup)
* [Network segmentation and privacy for VPC clusters](https://cloud.ibm.com/docs/containers?topic=containers-securitynetwork_segmentation_vpc)
* [What network traffic is allowed for my VPC cluster by default?](https://cloud.ibm.com/docs/containers?topic=containers-securityvpc-network-traffic-default)