vania-janet/multiturn-rag-retrieval-data huggingface dataset:
IBM Cloud File Storage for Classic plug-in 320 334 Increased the timeout for persistent volume creation from 15 to 30 minutes. Changed the default billing type to hourly. Added mount options to the pre-defined storage classes. In the NFS file storage instance in your IBM Cloud infrastructure account, changed the Notes field to JSON format and added the Kubernetes namespace that the PV is deployed to. To support multizone clusters, added zone and region labels to persistent volumes. 
 Kubernetes v1.10.3 v1.10.5 See the Kubernetes [release notes](https://github.com/kubernetes/kubernetes/releases/tag/v1.10.5). 
 Kernel N/A N/A Minor improvements to worker node network settings for high performance networking workloads. 
 OpenVPN client N/A N/A The OpenVPN client vpn deployment that runs in the kube-system namespace is now managed by the Kubernetes addon-manager. 







 Change log for worker node fix pack 1.10.3_1514, released 3 July 2018 

The following table shows the changes that are in the worker node fix pack 1.10.3_1514.



Table 1. Changes since version 1.10.3_1513

 Component Previous Current Description 

 Kernel N/A N/A Optimized sysctl for high performance networking workloads. 







 Change log for worker node fix pack 1.10.3_1513, released 21 June 2018 

The following table shows the changes that are in the worker node fix pack 1.10.3_1513.



Table 1. Changes since version 1.10.3_1512

 Component Previous Current Description 

 Docker N/A N/A For non-encrypted flavors, the secondary disk is cleaned by getting a fresh file system when you reload or update the worker node. 







 Change log for 1.10.3_1512, released 12 June 2018 

The following table shows the changes that are in patch 1.10.3_1512.



Table 1. Changes since version 1.10.1_1510

 Component Previous Current Description
I deleted a portable subnet and now my Classic cluster my Load Balancers are failing. How do I recover? 

Classic

 What’s happening 

your cluster is experiencing network errors.

 Why it’s happening 

A portable subnet was deleted.

 How to fix it 

Complete the following steps.



1. For the cluster that is experiencing issues, run the following command and make a note of the cluster ID.

ibmcloud oc cluster ls
2. List the subnets your cluster is using. In the output, make a note of the subnets that your cluster is using.

ibmcloud oc subnets --provider classic | grep CLUSTER-ID
3. List the subnets in your account. Check whether any subnets that you found in step 1 are missing from the list of subnets in your account. This means your cluster is using a subnet that was deleted, which is causing your Load Balancer to fail.

ibmcloud sl subnet list

ibmcloud sl subnet detail SUBNET-ID
4. For each subnet that was deleted, re-create it. If you need public IP addresses for your ALBs or LoadBalancers, specify the public VLAN ID of your worker nodes; for private IPs specify the private VLAN ID of your worker nodes.

ibmcloud oc cluster subnet create -c CLUSTER --size 8 --vlan VLAN-ID
5. Find any LoadBalancers that use IP addresses in the deleted portable subnets, save them, and then delete them. Do not delete the LoadBalancers in the openshift-ingress namespace, as those are deleted later in these steps.



1. Find your LoadBalancer details and make a note of the IP addresses they use.

kubectl get svc -A -o wide | grep LoadBalancer
2. For each LoadBalancer not in the openshift-ingress namespace that uses a portable IP address, save the settings to a YAML file.
Classic clusters: Why does enabling Ingress ALBs result in subnet errors? 

Classic infrastructure

  What’s happening 

When you try to enable an Ingress ALB by running the ibmcloud ks ingress alb enable command, you see the following error:

No valid subnets found for the specified zone. Verify that a subnet exists on the VLAN in the zone that you specify by running 'ibmcloud ks subnets'. Note: If the problem persists, verify that your ALBs and worker nodes are on the same VLANs by following the steps in this troubleshooting doc: <https://ibm.biz/alb-vlan-ts>

However, you ran ibmcloud ks ks subnets and verified that one or more subnets are available on the VLAN in the zone where the ALB exists.

  Why it’s happening 

Your ALBs and your worker nodes might not exist on the same VLANs.

This can occur when you delete worker nodes on the VLANs that the ALBs were also originally created on, and then create new worker nodes on new VLANs.

  How to fix it 

Move your ALBs to the same VLANs that your worker nodes exist on by following the steps in [Moving ALBs across VLANs](https://cloud.ibm.com/docs/containers?topic=containers-ingress-alb-managemigrate-alb-vlan).
ibmcloud ks worker replace --cluster <cluster_name_or_ID> --worker <worker_node_ID>
3. Verify that the worker node is replaced.

ibmcloud ks worker ls --cluster <cluster_name_or_ID>



ibmcloud ks worker replace --cluster CLUSTER_NAME_OR_ID --worker WORKER_ID [--update] [-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.

--worker WORKER
: Required: The name or ID of a worker node.

--update
: Include this option to update the worker node to the same major and minor version of the master and the latest patch.

-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 replace command 

ibmcloud ks worker replace --cluster my_cluster --worker kube-dal10-cr18a61a63a6a94b658596aa93d087aaa9-w1







 ibmcloud ks worker rm 

Virtual Private Cloud

Classic infrastructure

Remove one or more worker nodes from a cluster. 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
ibmcloud ks worker replace --cluster <cluster_name_or_ID> --worker <worker_node_ID>
3. Verify that the worker node is replaced.

ibmcloud ks worker ls --cluster <cluster_name_or_ID>



ibmcloud ks worker replace --cluster CLUSTER_NAME_OR_ID --worker WORKER_ID [--update] [-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.

--worker WORKER
: Required: The name or ID of a worker node.

--update
: Include this option to update the worker node to the same major and minor version of the master and the latest patch.

-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 replace command 

ibmcloud ks worker replace --cluster my_cluster --worker kube-dal10-cr18a61a63a6a94b658596aa93d087aaa9-w1







 ibmcloud ks worker rm 

Virtual Private Cloud

Classic infrastructure

Remove one or more worker nodes from a cluster. 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
10.241.128.4 Ready master,worker 22d v1.21.6+bb8d50a
10.241.64.4 Ready master,worker 22d v1.21.6+bb8d50a







 Step 6: Clean up the resources from the old node 

Major

Minor



1. Navigate to the openshift-storage project.

oc project openshift-storage
2. Remove the failed OSD from the cluster. You can specify multiple failed OSDs if required:

oc process -n openshift-storage ocs-osd-removal -p FAILED_OSD_IDS=<failed_osd_id> | oc create -f OSD-ID,OSD-ID, OSD-ID

The FORCE_OSD_REMOVAL value must be changed to true in clusters that have only three OSDs, or clusters with insufficient space to restore all three replicas of the data after the OSD is removed.
3. Verify that the OSD was removed successfully by checking the status of the ocs-osd-removal-job pod.

oc get pod -l job-name=ocs-osd-removal-job -n openshift-storage
4. Verify that the OSD removal is completed.

oc logs -l job-name=ocs-osd-removal-job -n openshift-storage --tail=-1 | egrep -i 'completed removal'

Example output

2023-03-10 06:50:04.501511 I | cephosd: completed removal of OSD 0







 Step 7: Add the new storage node 

Major

Minor



1. If you limited your ODF deployment to a subset of worker nodes by specifying node names during installation, you must update the ocscluster CRD to include the new name. If you did not limit your configuration to only certain worker nodes, you do not need to update the ocscluster CRD.

oc edit ocscluster

apiVersion: ocs.ibm.io/v1
kind: OcsCluster
metadata:
High availability For both classic and VPC clusters, the master includes three replicas for high availability. Further, if you create your cluster in a multizone metro, the master replicas are spread across zones and you can also spread your worker pools across zones. For more information, see [High availability for Red Hat OpenShift on IBM Cloud](https://cloud.ibm.com/docs/openshift?topic=openshift-ha). 
 Reservations [Create a reservation](https://cloud.ibm.com/docs/openshift?topic=openshift-reservations) with contracts for 1 or 3 year terms for classic worker nodes to lock in a reduced cost for the life of the contract. Typical savings range between 30-50% compared to regular worker node costs. 
 Cluster administration Classic clusters support the entire set of v1 API operations, such as resizing worker pools, reloading worker nodes, and updating masters and worker nodes across major, minor, and patch versions. When you delete a cluster, you can choose to remove any attached subnet or storage instances. 
 Cluster networking Your worker nodes are provisioned on private VLANs that provide private IP addresses to communicate on the private IBM Cloud infrastructure network. For communication on the public network, you can also provision the worker nodes on a public VLAN. Communication to the cluster master can be on the public or private cloud service endpoint. For more information, see [Understanding cluster network basics](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_clusters). 
 Apps and container platform You can choose to create [community Kubernetes or Red Hat OpenShift clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-faqscontainer_platforms) to manage your containerized apps. Your app build processes don't differ because of the infrastructure provider, but how you expose the app does. For more information, see [Choosing an app exposure service](https://cloud.ibm.com/docs/openshift?topic=openshift-cs_network_planning).
VPC clusters can be provisioned as standard clusters on shared [virtual](https://cloud.ibm.com/docs/openshift?topic=openshift-planning_worker_nodesvm) worker nodes only, and must be created in one of the supported [multizone locations](https://cloud.ibm.com/docs/openshift?topic=openshift-regions-and-zoneszones-vpc). Free VPC clusters are not supported.

VPC clusters can be provisioned using virtual worker nodes on standard infrastructure or dedicated hosts. Free VPC clusters are not supported.





 Can I combine different flavors in a cluster? 

Yes. To add different flavors to your cluster, you must [create another worker pool](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_worker_pool_create). You can't resize existing worker pools to have different compute resources such as CPU or memory.





 How can I change worker node flavors? 

See [updating flavors](https://cloud.ibm.com/docs/containers?topic=containers-updatemachine_type).





 Are the worker nodes encrypted? 

The secondary disk of the worker node is encrypted. For more information, see [Overview of cluster encryption](https://cloud.ibm.com/docs/openshift?topic=openshift-encryptionencrypt_ov). After you create a worker pool, you might notice that the worker node flavor has .encrypted in the name, such as b3c.4x16.encrypted.





 How do I manage my worker nodes? 

Worker nodes in classic clusters are provisioned into your IBM Cloud account. You can manage your worker nodes by using Red Hat OpenShift on IBM Cloud, but you can also use the [classic infrastructure dashboard](https://cloud.ibm.com/classic/) in the IBM Cloud console to work with your worker node directly.
VRVDR-42774 Critical X710 (i40e) driver sending flow control frames at a very high rate 
 VRVDR-42635 Minor BGP redistribute route-map policy change does not take effect 
 VRVDR-42620 Minor Vyatta-ike-sa-daemon throws error “Command failed: establishing CHILD_SA passthrough-peer” while tunnel appears to be up 
 VRVDR-42483 Minor TACACS authentication failing 
 VRVDR-42283 Major VRRP state changes to FAULT for all interfaces when a vif interface ip is deleted 
 VRVDR-42244 Minor Flow-monitoring only exports 1000 samples to collector 
 VRVDR-42114 Critical HTTPS service MUST NOT expose TLSv1 
 VRVDR-41829 Major Dataplane core dumps until system becomes unresponsive with SIP ALG soak test 
 VRVR-41683 Blocker DNS name server address learned over VRF is not consistently recognized 
 VRVDR-41628 Minor Route/prefix from router-advertisement active in kernel and data plane but ignored by RIB 







 Security Vulnerabilities Resolved 



Security vulnerabilities resolved for 1801q

 Issue Number CVSS score Advisory Summary 

 VRVDR-43288 5.6 DSA-4279-1 CVE-2018-3620, CVE-2018-3646: Debian DSA-4279- 1 – Linux security update 
 VRVDR-43111 N/A DSA-4266-1 CVE-2018-5390, CVE-2018-13405: Debian DSA- 4266-1 – Linux security update 









 1801n 



 Issues Resolved 



Issues resolved for 1801n

 Issue Number Priority Summary 

 VRVDR-42588 Minor Sensitive routing protocol configuration inadvertently leaked in system log 
 VRVDR-42566 Critical After upgrading from 17.2.0h to 1801m, a day later multiple reboots occurred on both HA members 
 VRVDR-42490 Major VTI-IPSEC IKE SAs fail around a minute after VRRP transition 
 VRVDR-42335 Major IPSEC: remote-id “hostname” behavior changes from 5400 to 5600
Available predefined profiles 

With the IBM Cloud® Security and Compliance Center, you can take advantage of predefined profiles that contain collections of controls that are curated based on industry standards. You can also create your own [Assessment-based profiles](https://cloud.ibm.com/docs/security-compliance?topic=security-compliance-build-custom-profiles).

Security and Compliance Center supports predefined profiles. Within each profile, you can review the controls that are required to be compliant. You can't modify or remove controls from a predefined profile. But, you can use a predefined profile as a base to create a new profile to choose only the controls and goals that are relevant for your business.

Then, if needed, you can update the default parameters that are associated with the goals within each predefined profile.



 Updating predefined profiles 

At times, Security and Compliance Center publishes new versions of IBM Cloud predefined profiles. Reasons for reversioning include:



* to remove rules that are invalid or are no longer required to meet controls;
* to add new rules and extend the compliance coverage of profiles;
* to fix defective rules.





 Update levels 

Based on specific activities, the updates to the IBM Cloud's predefined profiles can be major, minor, or a simple fix. To understand what each update level includes, review the following table.



Table 1. IBM Cloud predefined profiles update levels

 Activity Fix Minor Major 

 Bug fixes<br><br><br><br> * Small change to a rule<br> * Small change to control guidance<br><br><br> ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/icons/checkmark-icon.svg) ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/icons/checkmark-icon.svg) ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/icons/checkmark-icon.svg)
Understanding IBM software currency policy 

Review the following policies to understand how IBM® maintains software currency for VMware® and third-party software.

IBM defines a major release as the first update level after a VMware major release (for example, 8.0u1) with the following exceptions:



*  Third-party certifications on a new release. For example, IBM does not certify that Zerto works on VMware vSphere ESXi™ 8.0u1.
*  IBM code freeze windows.





Table 1. Software currency policies for VMware software

 VMware vSphere and VMware Cloud Director releases  Target         

 Major releases (for example, 7.x)                  Up to 9 months 
 Minor releases (for example, 7.1.x)                Up to 4 months 
 Patches, hotfixes, and maintenance packs           Up to 45 days  
 Day zero uses (IBM security policy)                Within 5 days  





Table 2. Software currency policies for third party software

 Third-party releases                  Target         

 Major releases                        Up to 4 months 
 Minor releases                        Up to 45 days  
 Patches, hotfixes, maintenance packs  Up to 45 days  
 Day zero uses (IBM security policy)   Within 5 days
Cluster version <br><br> * Provide a suite of tools to automate cluster management, such as the Red Hat OpenShift on IBM Cloud [API](https://containers.cloud.ibm.com/global/swagger-global-api//), [CLI plug-in](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-cli), and [console](https://cloud.ibm.com/kubernetes/clusters).<br> * Automatically apply Red Hat OpenShift master patch OS, version, and security updates.<br> * Make major and minor updates for master nodes available for you to apply.<br> * Provide worker node major, minor, and patch OS, version, and security updates.<br> * Fulfill automation requests to update cluster master and worker nodes.<br><br><br> <br><br> * Use the API, CLI, or console tools to [apply](https://cloud.ibm.com/docs/containers?topic=containers-updateupdate) the provided major and minor Red Hat OpenShift master updates and major, minor, and patch worker node updates.<br><br><br> 







 Identity and access management 

You and IBM share responsibilities for controlling access to your Red Hat OpenShift on IBM Cloud instances. For IBM Cloud® Identity and Access Management responsibilities, consult that product's documentation. You are responsible for identity and access management to your application data.



Table 4. Responsibilities for identity and access management

 Resource IBM responsibilities Your responsibilities 

 Observability Provide the ability to integrate IBM Cloud Activity Tracker with your cluster to audit the actions that users take in the cluster. Set up IBM Cloud Activity Tracker or other capabilities to track user activity in the cluster. 







 Security and regulation compliance 

IBM is responsible for the security and compliance of Red Hat OpenShift on IBM Cloud. Compliance to industry standards varies depending on the infrastructure provider that you use for the cluster, such as classic or VPC. You are responsible for the security and compliance of any workloads that run in the cluster and your application data. For more information, see [What standards does the service comply to?]
To perform this action, you need the Network > Manage Network VLAN Spanning[infrastructure permission](https://cloud.ibm.com/docs/containers?topic=containers-access-credsinfra_access), or you can request the account owner to enable it. To check whether VLAN spanning is already enabled, use the ibmcloud oc vlan spanning get --region <region>[command](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_vlan_spanning_get).





 Can I convert my single zone cluster to a multizone cluster? 

To convert a single zone cluster to a multizone cluster, your cluster must be set up in one of the supported [classic](https://cloud.ibm.com/docs/containers?topic=containers-regions-and-zoneszones-mz) or [VPC](https://cloud.ibm.com/docs/containers?topic=containers-regions-and-zoneszones-vpc) multizone locations. VPC clusters can be set up only in multizone metro locations, and as such can always be converted from a single zone cluster to a multizone cluster. Classic clusters that are set up in a single zone data center can't be converted to a multizone cluster. To convert a single zone cluster to a multizone cluster, see [Adding worker nodes by adding a zone to a worker pool](https://cloud.ibm.com/docs/containers?topic=containers-add_workersadd_zone).





 Do my apps automatically spread across zones? 

It depends on how you set up the app. See [Planning highly available deployments](https://cloud.ibm.com/docs/openshift?topic=openshift-plan_deployhighly_available_apps) and [Planning highly available persistent storage](https://cloud.ibm.com/docs/openshift?topic=openshift-storage-plan).







 Multiple public clusters connected with a global load balancer
VRVDR-47358 9.8 N/A CVE-2016-10228, CVE-2017-12132, CVE-20181000001, CVE-2018-6485, CVE-2017-15670, CVE2017-15671, CVE-2017-15804, CVE-2017-12133, CVE-2017-16887, CVE-2017-1000366, CVE-20155180, CVE-2016-6323, CVE-2016-10228: glibc package update 
 VRVDR-47293 7.1 DSA-4462-1 CVE-2019-12749: Debian DSA-4462-1 : dbus - security update 
 VRVDR-47202 N/A DSA-4454-2 Debian DSA-4454-2: qemu regression update 









 1801z 



 Issues Resolved 



Issues resolved for 1801z

 Issue Number Priority Summary 

 VRVDR-46941 Minor Traffic that has SNAT session is filtered using stateless ZBF on return 
 VRVDR-46659 Major I350 intfs with mtu 9000 remains stuck at u/D state on upgrade from 1808* to 1903a 
 VRVDR-46623 Minor Firewall 'description' logs a perl error on commit when the description has more than one word 
 VRVDR-46549 Critical Shell injection privilege escalation/sandbox escape in show ip route routing-instance <name> variance command 
 VRVDR-46389 Major BGP configuration changes may not take effect if applied after (re)boot 
 VRVDR-45949 Minor Netflow generates a NOTICE log for every sample sent when certain non-key fields are configured 
 VRVDR-43169 Minor Logging everytime one calls a configd C based API but doesn't supply an error struct is no longer useful 
 VRVDR-41225 Minor When configuring interface description, every white space is treated as a new line 







 Security Vulnerabilities Resolved 



Security vulnerabilities resolved for 1801z

 Issue Number CVSS score Advisory Summary