We're asking the following questions to evaluate whether or not OCPBUGS-20213 warrants changing update recommendations from either the previous X.Y or X.Y.Z. The ultimate goal is to avoid recommending an update which introduces new risk or reduces cluster functionality in any way. In the absence of a declared update risk (the status quo), there is some risk that the existing fleet updates into the at-risk releases. Depending on the bug and estimated risk, leaving the update risk undeclared may be acceptable.

Sample answers are provided to give more context and the ImpactStatementRequested label has been added to OCPBUGS-20213. When responding, please move this ticket to Code Review. The expectation is that the assignee answers these questions.

Which 4.y.z to 4.y'.z' updates increase vulnerability?

• Customers upgrading from any 4.13.z to 4.14.0.

Which types of clusters?

• Azure Stack Hub clusters.

What is the impact? Is it serious enough to warrant removing update recommendations?

• For users upgrading from 4.13.z to 4.14.0 the impact is increased errors in the logs for the Cloud Controller Manager.
• For users performing a fresh 4.14.0 install the impact is that worker nodes will not be added to the public load balancer, and as such will not join the cluster.

How involved is remediation?

• Remediation is relatively simple and involves adjusting the ConfigMap for the Cloud Controller Manager configuration. See https://access.redhat.com/solutions/7040264 for more details.

Is this a regression?

• Yes, during the Kubernetes version 1.27 upgrade, the cloud-provider-azure project changed the default type for virtual machines when the configuration value is empty. This in turn leads to a condition where the defaults are not compatible with Azure Stack Hub, and as such the configuration value for the default virtual machine type must now be specified explicitly on Azure Stack Hub.