vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Change log for worker node fix pack 4.3.40_1555_openshift, released 1 March 2021 

The following table shows the changes that are in the worker node fix pack 4.3.40_1555_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_1554_openshift

 Component Previous Current Description 

 IBM Cloud Container Registry private endpoints N/A N/A VPC worker nodes: Fixed a bug where traffic to the private endpoints of IBM Cloud Container Registry might fail after rebooting the worker node. 
 RHEL 7 Packages N/A N/A Updated worker node with package updates. 







 Change log for master fix pack 4.3.40_1555_openshift, released 22 February 2021 

The following table shows the changes that are in the master fix pack patch update 4.3.40_1555_openshift. Master patch updates are applied automatically.



Changes since version 4.3.40_1552_openshift

 Component Previous Current Description 

 Cluster health image v1.1.16 v1.1.18 Updated to use Go version 1.15.7. Updated image to implement additional IBM security controls. 
 Gateway-enabled cluster controller 1195 1232 Updated to use Go version 1.15.7. 
 IBM Calico extension 567 618 Updated to use Go version 1.15.7. 
 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.
Note: If you are removing a flavor that is billed monthly (such as bare metal), you are charged for the entire the month.



1. Remove the worker pool with the old machine type. Removing a worker pool removes all worker nodes in the pool in all zones. This process might take a few minutes to complete.

ibmcloud oc worker-pool rm --worker-pool WORKER-POOL --cluster CLUSTER
2. Verify that the worker pool is removed.

ibmcloud oc worker-pool ls --cluster CLUSTER



6. Verify that the worker nodes are removed from your cluster.

ibmcloud oc worker ls --cluster CLUSTER
7. Repeat these steps to update other worker pools or stand-alone worker nodes to different flavors.







 Updating cluster components 

Your Red Hat OpenShift on IBM Cloud cluster comes with components, such as Ingress, that are installed automatically when you provision the cluster. By default, these components are updated automatically by IBM. However, you can disable automatic updates for some components and manually update them separately from the master and worker nodes.

What default components can I update separately from the cluster?
: You can optionally disable automatic updates for the following components:



* [Fluentd for logging](https://cloud.ibm.com/docs/openshift?topic=openshift-updatelogging-up)
* [Ingress application load balancer (ALB)](https://cloud.ibm.com/docs/openshift?topic=openshift-updatealb)



Are there components that I can't update separately from the cluster?
: Yes. Your cluster is deployed with the following managed components and associated resources that can't be changed, except to scale pods or edit configmaps for certain performance benefits. If you try to change one of these deployment components, their original settings are restored on a regular interval when they are updated with the cluster master. However, note that resources that you create that are associated with these components, such as Calico network policies that you create to be implemented by the Calico deployment components, are not updated.



* calico components
* coredns components
* UI
* CLI







 Deploying OpenShift Data Foundation on Classic clusters 

OpenShift Data Foundation is a highly available storage solution that you can use to manage persistent storage for your containerized workloads in Red Hat® OpenShift® on IBM Cloud® clusters.

Installing OpenShift Data Foundation from OperatorHub is not supported on IBM Cloud clusters. To install ODF, complete the following steps to deploy the cluster add-on.



 Planning your setup 

Before you install ODF in your cluster, you must make sure that the following prerequisite conditions are met:

To install OpenShift Data Foundation on classic clusters, you must enable [VRF](https://cloud.ibm.com/docs/account?topic=account-vrf-service-endpointvrf) in your account.



1. [Install](https://cloud.ibm.com/docs/openshift?topic=openshift-cli-install) or update the oc CLI
2. If you don't have virtual route forwarding (VRF) enabled in your account, enable [VRF](https://cloud.ibm.com/docs/account?topic=account-vrf-service-endpointvrf).



1. After you have enabled VRF, enable [Service endpoints](https://cloud.ibm.com/docs/account?topic=account-vrf-service-endpoint&interface=uiservice-endpoint).



3. [Review the SDS worker node flavors](https://cloud.ibm.com/docs/openshift?topic=openshift-planning_worker_nodessds-table).
4. Create a [classic cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-clusters) with a minimum of one worker node per zone across three zones. Choose worker nodes of flavor type mb4c.32x384.3.8tb.ssd or mb4c.20x64.2x1.9tb.ssd that have the required local disks for ODF.
5.
"username": "iamapikey",
"password": "<encoded_string>",
"email": "email@example.com",
"auth": "<encoded_string>"
}
}
}
6. To pick up the global configuration changes, reload all the worker nodes in your cluster.



1. Note the ID of the worker nodes in your cluster.

ibmcloud oc worker ls -c <cluster_name_or_ID>
2. Reload each worker node. You can reload multiple worker nodes by including multiple -w options, but make sure to leave enough worker nodes running at the same time for your apps to avoid an outage.

ibmcloud oc worker reload -c <cluster_name_or_ID> -w <workerID_1> -w <workerID_2>



7. After the worker nodes are back in a healthy state, verify that the global pull secret is updated on a worker node.



1. Start a debugging pod to log in to a worker node. Use the Private IP that you retrieved earlier for the <node_name>.

oc debug node/<node_name>
2. Change the root directory to the host so that you can view files on the worker node.

chroot /host
3. Verify that the Docker configuration file has the registry credentials that match the global pull secret that you set.

vi /.docker/config.json









 Updating an IBM Cloud Kubernetes Service containerd custom registry configuration 

With Kubernetes version 1.22 or later, you can use containerd configuration files on worker nodes to configure pulling from a container registry. You can use a daemonset to update the configurations across all nodes in a cluster, which prevents configurations from being wiped when worker nodes reload or when new workers are added.



 Example daemonset to update a containerd custom registry configuration 

Use the example YAML file to define a daemonset that runs on all worker nodes to set or update a containerd registry host configuration and mount to the corresponding containerd registry path.
If you remove a worker node, your cluster becomes unbalanced, and [replacing a worker node](https://cloud.ibm.com/docs/cli?topic=cli-kubernetes-service-clicli_worker_replace) no longer creates a replacement worker node. You can automatically rebalance your worker pool by running the ibmcloud ks worker-pool rebalance[command](https://cloud.ibm.com/docs/cli?topic=cli-kubernetes-service-clics_rebalance) after you remove a worker node.

ibmcloud ks worker rm --cluster CLUSTER --worker WORKER [-f] [-q]

Minimum required permissions
: Operator platform access role for the cluster in IBM Cloud Kubernetes Service

Command options:

-c, --cluster CLUSTER
: Required: The name or ID of the cluster.

-w, --worker WORKER
: Specify a worker node ID. To reload multiple worker nodes, use multiple options, such as -w worker1_id -w worker2_id.

-f
: Optional: Force the command to run with no user prompts.

-q
: Optional: Do not show the message of the day or update reminders.



 Example worker rm command 

ibmcloud ks worker rm --cluster my_cluster -w kube-dal10-cr18a61a63a6a94b658596aa93d087aaa9-w1 -w kube-dal10-cr18a61a63a6a94b658596aa93d087aaa9-w2







 ibmcloud ks worker update 

Classic infrastructure

Update worker nodes to apply the latest security updates and patches to the operating system, and to update the Kubernetes version to match the version of the Kubernetes master. You can update the master Kubernetes version with the ibmcloud ks cluster master update[command](https://cloud.ibm.com/docs/cli?topic=cli-kubernetes-service-clics_cluster_update).
If you remove a worker node, your cluster becomes unbalanced, and [replacing a worker node](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clicli_worker_replace) no longer creates a replacement worker node. You can automatically rebalance your worker pool by running the ibmcloud ks worker-pool rebalance[command](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_rebalance) after you remove a worker node.

ibmcloud ks worker rm --cluster CLUSTER --worker WORKER [-f] [-q]

Minimum required permissions
: Operator platform access role for the cluster in IBM Cloud Kubernetes Service

Command options:

-c, --cluster CLUSTER
: Required: The name or ID of the cluster.

-w, --worker WORKER
: Specify a worker node ID. To reload multiple worker nodes, use multiple options, such as -w worker1_id -w worker2_id.

-f
: Optional: Force the command to run with no user prompts.

-q
: Optional: Do not show the message of the day or update reminders.



 Example worker rm command 

ibmcloud ks worker rm --cluster my_cluster -w kube-dal10-cr18a61a63a6a94b658596aa93d087aaa9-w1 -w kube-dal10-cr18a61a63a6a94b658596aa93d087aaa9-w2







 ibmcloud ks worker update 

Classic infrastructure

Update worker nodes to apply the latest security updates and patches to the operating system, and to update the Kubernetes version to match the version of the Kubernetes master. You can update the master Kubernetes version with the ibmcloud ks cluster master update[command](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_cluster_update).
Local storage on the worker node is for short-term processing only, and the primary and auxiliary disks are wiped when you update or reload the worker node. For persistent storage solutions, see [Planning highly available persistent storage](https://cloud.ibm.com/docs/containers?topic=containers-storage-plan).

Because you have full control over the isolation and resource consumption for your workloads, you can use bare metal machines to achieve HIPAA and PCI compliance for your environment.

Bare metal seems awesome! What's stopping me from ordering one immediately?
: Bare metal servers are more expensive than virtual servers, and are best suited for high-performance apps that need more resources and host control. Bare metal worker nodes are also not available for VPC clusters.

Bare metal servers are billed monthly. If you cancel a bare metal server before the end of the month, you are charged through the end of that month. After you order or cancel a bare metal server, the process is completed manually in your IBM Cloud infrastructure account. Therefore, it can take more than one business day to complete.





 Available flavors for bare metal 

Worker node flavors vary by cluster type, the zone where you want to create the cluster, the container platform, and the infrastructure provider that you want to use. To see the flavors available in your zone, run ibmcloud ks flavors --zone <zone>. You can also review available [VM](https://cloud.ibm.com/docs/containers?topic=containers-planning_worker_nodesvm) or [SDS](https://cloud.ibm.com/docs/containers?topic=containers-planning_worker_nodessds) flavors.

Bare metal machines are optimized for different use cases such as data-, GPU-, or RAM-intensive workloads.

Choose a flavor, or machine type, with the correct storage configuration to support your workload. Some flavors have a mix of the following disks and storage configurations. For example, some flavors might have a SATA primary disk with a raw SSD secondary disk.



* SATA: A magnetic spinning disk storage device that is often used for the primary disk of the worker node that stores the OS file system.
Replace <volume_ID> with the volume ID of your block storage device that you retrieved earlier, and <private_worker_IP> with the private IP address of the non-SDS worker node where you want to attach the device.

ibmcloud sl block access-authorize <volume_ID> -p <private_worker_IP>

Example output

The IP address 123456789 was authorized to access <volume_ID>.
7. Verify that your non-SDS worker node is successfully authorized and note the host_iqn, username, and password.

ibmcloud sl block access-list <volume_ID>

Example output

ID name type private_ip_address source_subnet host_iqn username password allowed_host_id
123456789 <private_worker_IP> IP <private_worker_IP> - iqn.2018-09.com.ibm:ibm02su1543159-i106288771 IBM02SU1543159-I106288771 R6lqLBj9al6e2lbp 1146581

The authorization is successful when the host_iqn, username, and password are assigned.
8. [Attach the block storage devices to your worker nodes](https://cloud.ibm.com/docs/openshift?topic=openshift-utilitiesattach_block).







 Classic: Attaching raw block storage to non-SDS worker nodes 

To attach the block storage device to a non-SDS worker node, you must create a persistent volume (PV) with the IBM Cloud Block Volume Attacher storage class and the details of your block storage device.

The instructions in this topic are available for classic worker nodes only. If you want to attach raw, unformatted block storage to a VPC worker node, see [Adding raw Block Storage for VPC to worker nodes](https://cloud.ibm.com/docs/openshift?topic=openshift-utilitiesvpc_api_attach).
Replace <volume_ID> with the volume ID of your block storage device that you retrieved earlier, and <private_worker_IP> with the private IP address of the non-SDS worker node where you want to attach the device.

ibmcloud sl block access-authorize <volume_ID> -p <private_worker_IP>

Example output

The IP address 123456789 was authorized to access <volume_ID>.
7. Verify that your non-SDS worker node is successfully authorized and note the host_iqn, username, and password.

ibmcloud sl block access-list <volume_ID>

Example output

ID name type private_ip_address source_subnet host_iqn username password allowed_host_id
123456789 <private_worker_IP> IP <private_worker_IP> - iqn.2018-09.com.ibm:ibm02su1543159-i106288771 IBM02SU1543159-I106288771 R6lqLBj9al6e2lbp 1146581

The authorization is successful when the host_iqn, username, and password are assigned.
8. [Attach the block storage devices to your worker nodes](https://cloud.ibm.com/docs/containers?topic=containers-utilitiesattach_block).







 Classic: Attaching raw block storage to non-SDS worker nodes 

To attach the block storage device to a non-SDS worker node, you must create a persistent volume (PV) with the IBM Cloud Block Volume Attacher storage class and the details of your block storage device.

The instructions in this topic are available for classic worker nodes only. If you want to attach raw, unformatted block storage to a VPC worker node, see [Adding raw Block Storage for VPC to worker nodes](https://cloud.ibm.com/docs/containers?topic=containers-utilitiesvpc_api_attach).
You can't scale worker pools down to zero. Because of the worker node quota, you are limited in the number of worker pools per cluster and number of worker nodes per worker pool. For example, with the default worker node quota of 500 per region, you might have up to 500 worker pools of 1 worker node each in a region with only 1 cluster. Or, you might have 1 worker pool with up to 500 worker nodes in a region with only 1 cluster. 
 Cluster naming To ensure that the Ingress subdomain and certificate are correctly registered, the first 24 characters of the clusters' names must be different. If you create and delete clusters with the same name or names that have the same first 24 characters 5 times or more within 7 days, such as for automation or testing purposes, you might reach the [Let's Encrypt Duplicate Certificate rate limit](https://cloud.ibm.com/docs/containers?topic=containers-cs_rate_limit). 







 Classic cluster limitations 

Classic infrastructure clusters in IBM Cloud Kubernetes Service are released with the following limitations.



 Compute 

Keep in mind that the [service](https://cloud.ibm.com/docs/containers?topic=containers-limitationstech_limits) limitations also apply.



Classic cluster compute limitations

 Category Description 

 Reserved instances [Reserved capacity and reserved instances](https://cloud.ibm.com/docs/virtual-servers?topic=virtual-servers-provisioning-reserved-capacity-and-instances) are not supported. 
 Worker node flavors Worker nodes are available in [select flavors](https://cloud.ibm.com/docs/containers?topic=containers-planning_worker_nodesshared_dedicated_node) of compute resources. 
 Worker node host access For security, you can't SSH into the worker node compute host. 







 Networking 

Keep in mind that the [service](https://cloud.ibm.com/docs/containers?topic=containers-limitationstech_limits) limitations also apply.



Classic cluster networking limitations

 Category Description 

 Ingress ALBs <br><br> * The Ingress application load balancer (ALB) can process 32,768 connections per second.
Setting up the public cloud service endpoint 

Enable the public cloud service endpoint for your cluster.

Your cluster must have a public cloud service endpoint on classic infrastructure. For a cluster with only a private cloud service endpoint, create a VPC cluster instead.

The public cloud service endpoint makes your Kubernetes master publicly accessible. Your worker nodes and your authorized cluster users can securely communicate with the Kubernetes master over the public network. For more information, see [Worker-to-master and user-to-master communication](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_basicsinternet-facing).



 Steps to enable the public cloud service endpoint 

If you previously disabled the public endpoint, you can re-enable it.



1. Enable the public cloud service endpoint.

ibmcloud oc cluster master public-service-endpoint enable --cluster <cluster_name_or_ID>
2. Refresh the Kubernetes master API server to use the public cloud service endpoint. You can follow the prompt in the CLI, or manually run the following command. It might take several minutes for the master to refresh.

ibmcloud oc cluster master refresh --cluster <cluster_name_or_ID>
3. [Create a configmap](https://cloud.ibm.com/docs/containers?topic=containers-updateworker-up-configmap) to control the maximum number of worker nodes that can be unavailable at a time in your cluster. When you update your worker nodes, the ConfigMap helps prevent downtime for your apps as the apps are rescheduled orderly onto available worker nodes.
4. Update all the worker nodes in your cluster to remove the public cloud service endpoint configuration.

ibmcloud oc worker update --cluster <cluster_name_or_ID> --worker <worker1,worker2>

By issuing the update command, the worker nodes are reloaded to pick up the service endpoint configuration.
Change log for worker node fix pack 1.20.5_1535, released 12 April 2021 

The following table shows the changes that are in the worker node fix pack 1.20.5_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.20.5_1534

 Component Previous Current Description 

 HA proxy 9b2dca a3b1ff The update addresses [CVE-2021-3449](https://nvd.nist.gov/vuln/detail/CVE-2021-3449) and [CVE-2021-3450](https://nvd.nist.gov/vuln/detail/CVE-2021-3450). 
 Ubuntu 18.04 packages N/A N/A Updated worker node images with package updates for [CVE-2021-22876](https://nvd.nist.gov/vuln/detail/CVE-2021-22876). 
 Ubuntu 16.04 packages N/A N/A Updated worker node images with package updates for [CVE-2021-22876](https://nvd.nist.gov/vuln/detail/CVE-2021-22876). 







 Change log for master fix pack 1.20.5_1533, released 30 March 2021 

The following table shows the changes that are in the master fix pack patch update 1.20.5_1533. Master patch updates are applied automatically.



Changes since version 1.20.4_1531

 Component Previous Current Description 

 Activity Tracker event N/A N/A Now, the containers-kubernetes.version.update event is sent to Activity Tracker when a master fix pack update is initiated for a cluster. 
 Cluster health image v1.2.8 v1.2.9 Updated image for [CVE-2020-28851](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-28851).
Change log for worker node fix pack 1.18.17_1548, released 12 April 2021 

The following table shows the changes that are in the worker node fix pack 1.18.17_1548. 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.17_1547

 Component Previous Current Description 

 HA proxy 9b2dca a3b1ff The update addresses [CVE-2021-3449](https://nvd.nist.gov/vuln/detail/CVE-2021-3449) and [CVE-2021-3450](https://nvd.nist.gov/vuln/detail/CVE-2021-3450). 
 Ubuntu 18.04 packages N/A N/A Updated worker node images with package updates for [CVE-2021-22876](https://nvd.nist.gov/vuln/detail/CVE-2021-22876). 
 Ubuntu 16.04 packages N/A N/A Updated worker node images with package updates for [CVE-2021-22876](https://nvd.nist.gov/vuln/detail/CVE-2021-22876). 







 Change log for master fix pack 1.18.17_1546, released 30 March 2021 

The following table shows the changes that are in the master fix pack patch update 1.18.17_1546. Master patch updates are applied automatically.



Changes since version 1.18.16_1544

 Component Previous Current Description 

 Activity Tracker event N/A N/A Now, the containers-kubernetes.version.update event is sent to Activity Tracker when a master fix pack update is initiated for a cluster. 
 Cluster health image v1.1.18 v1.1.19 Updated image for [CVE-2020-28851](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-28851).
Change log for worker node fix pack 1.17.17_1559, released 12 April 2021 

The following table shows the changes that are in the worker node fix pack 1.17.17_1559. 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.17_1558

 Component Previous Current Description 

 HA proxy 9b2dca a3b1ff The update addresses [CVE-2021-3449](https://nvd.nist.gov/vuln/detail/CVE-2021-3449) and [CVE-2021-3450](https://nvd.nist.gov/vuln/detail/CVE-2021-3450). 
 Ubuntu 18.04 packages N/A N/A Updated worker node images with package updates for [CVE-2021-22876](https://nvd.nist.gov/vuln/detail/CVE-2021-22876). 
 Ubuntu 16.04 packages N/A N/A Updated worker node images with package updates for [CVE-2021-22876](https://nvd.nist.gov/vuln/detail/CVE-2021-22876). 







 Change log for master fix pack 1.17.17_1557, released 30 March 2021 

The following table shows the changes that are in the master fix pack patch update 1.17.17_1557. Master patch updates are applied automatically.



Changes since version 1.17.17_1555

 Component Previous Current Description 

 Activity Tracker event N/A N/A Now, the containers-kubernetes.version.update event is sent to Activity Tracker when a master fix pack update is initiated for a cluster. 
 Cluster health image v1.1.18 v1.1.19 Updated image for [CVE-2020-28851](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-28851).