openshift/openshift-docs
1
0
Fork 0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00
Code Issues Releases Activity

Merge pull request #94704 from dfitzmau/bug-batch-4-19-d-i

Browse Source 
bug-batch-4-19-d-i: Bug batching
This commit is contained in:
Darragh Fitzmaurice
2025-06-13 12:06:14 +01:00
committed by GitHub
parent a838555f25 656524d9fe
commit 75b8d15a6d
1 changed files with 88 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

91
release_notes/ocp-4-19-release-notes.adoc
View File

@@ -1636,15 +1636,18 @@ With this release, availability sets are no longer modified after creation, allo
[id="ocp-release-note-driver-toolkit-bug-fixes_{context}"]
==== Driver ToolKit (DTK)
[discrete]
[id="ocp-release-note-cloud-etcd-operator-bug-fixes_{context}"]
==== etcd Cluster Operator
[discrete]
[id="ocp-release-note-image-registry-bug-fixes_{context}"]
==== Registry
[id="ocp-release-note-image-streams-bug-fixes_{context}"]
==== ImageStreams
* Previously, image import blocked registries that would fail if those registries were configured with `NeverContactSource`, even when mirror registries were set up. With this update, image importing is no longer blocked when a registry has mirrors configured. This ensures that image imports succeed even if the original source was set to `NeverContactSource` in the `ImageDigestMirrorSet` or `ImageTagMirrorSet` resources. (link:https://issues.redhat.com/browse/OCPBUGS-44432[OCPBUGS-44432])
* Previously, image importing from blocked registries would fail if those registries were configured with `NeverContactSource`, even when mirror registries were set up. With this update, image importing is no longer blocked when a registry has mirrors configured. This ensures that image imports succeed even if the original source was set to `NeverContactSource` in the `ImageDigestMirrorSet` or `ImageTagMirrorSet` resources. (link:https://issues.redhat.com/browse/OCPBUGS-44432[OCPBUGS-44432])
[discrete]
[id="ocp-release-note-installer-bug-fixes_{context}"]
@@ -1652,6 +1655,82 @@ With this release, availability sets are no longer modified after creation, allo
* Previously, if you attempted to install an {aws-first} cluster with minimum privileges and you did not specify an instance type in the `install-config.yaml` file, installation of the cluster failed. This issue happened because the installation program could not find supported instance types that the cluster could use in supported availability zones. For example, the `m6i.xlarge` default instance type was unavailable in `ap-southeast-4` and `eu-south-2` availability zones. With this release, the `openshift-install` program now requires the `ec2:DescribeInstanceTypeOfferings` {aws-short} permission to prevent the installation of the cluster from failing in situations where `m6i.xlarge` or another supported instance type is unavailable in a supported availability zone. (link:https://issues.redhat.com/browse/OCPBUGS-46596[OCPBUGS-46596])
* Previously, the installation program did not prevent users from attempting to install a single-node cluster on bare metal, which resulted in a failed installation. With this update, the installation program prevents single-node cluster installations on unsupported platforms. (link:https://issues.redhat.com/browse/OCPBUGS-56811[OCPBUGS-56811])
* Previously, when you diagnosed issues related to running the `openshift-install destroy cluster` command for {vmw-first}, the logging information provided insufficient detail. As a consequence, it was unclear why clusters were not removed from virtual machines (VMs). With this release, when you destroy a cluster, enhanced debug logging is provided and the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-56372[OCPBUGS-56372])
* Previously, when installing into an existing virtual private cloud (VPC) on {aws-first}, a potential mismatch could occur in the subnet information in the {aws-short} Availability Zone between the machine set custom resources for control plane nodes and their corresponding {aws-short} EC2 instances. As a consequence, where the control plane nodes were spread across three Availability Zones and one was recreated the discrepancy could result in an unbalanced control plane as two nodes occurred within the same Availability Zone. With this release, it is ensured that the subnet Availability Zone information in the machine set custom resources and in the EC2 instances match and the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-55492[OCPBUGS-55492])
* Previously, when installing a cluster with the `OVNKubernetes` network plugin, the installation could fail if the plugin is specified as `OVNkubernetes` with a lowercase "k". With this update, the installation program correctly interprets the plugin name regardless of case. (link:https://issues.redhat.com/browse/OCPBUGS-54606[OCPBUGS-54606])
* When a Proxy is configured, the installation program adds the `machineNetwork` CIDR to the `noProxy` field. Previously, if the `machineNetwork` CIDR had also been configured by the user in the `noProxy` field, this would result in a duplicate entry, which is not allowed by ignition and could prevent the host from booting properly. With this release, the installation program will not add the `machineNetwork` CIDR to the `noProxy` field if it has already been set. (link:https://issues.redhat.com/browse/OCPBUGS-53183[OCPBUGS-53183])
* Previously, API and ingress VIPs were automatically assigned even when a user-managed load balancer was in use. This behavior was unintended. Now, API and ingress VIPs are no longer automatically assigned. If these values are not explicitly set in the `install-config.yaml` file, the installation fails with an error, prompting the user to provide them. (link:https://issues.redhat.com/browse/OCPBUGS-53140[OCPBUGS-53140])
* Previously, when using the Agent-based Installer, the WWN of Fibre Channel (FC) multipath volumes was not detected during hardware discovery. As a result, when the `wwn` root device hint was specified, all multipath FC volumes were excluded by it. With this release, the WWN is now collected for multipath FC volumes, so when more than one multipath volume is present, users can select between them by using the `wwn` root device hint. (link:https://issues.redhat.com/browse/OCPBUGS-52994[OCPBUGS-52994])
* Previously, when installing a cluster on {azure-short}, the installation program did not include support for NVMe or SCSI, which prevented the use of VM instance families that require it. With this update, the installation program can make use of VM instance families that require NVMe or SCSI support. (link:https://issues.redhat.com/browse/OCPBUGS-52658[OCPBUGS-52658])
* Previously, when installing a cluster on {gcp-short} with a user-provided encryption key, the installation program could fail to find the key ring. With this update, the installation program finds the user-provided encryption key ring so the installation does not fail. (link:https://issues.redhat.com/browse/OCPBUGS-52203[OCPBUGS-52203])
* Previously, when installing a cluster on {gcp-short}, the installation could fail if network instability prevented the fetching of {gcp-short} tags during installation. With this update, the installation program has been improved to tolerate network instability during installation. (link:https://issues.redhat.com/browse/OCPBUGS-50919[OCPBUGS-50919])
* Previously, the installer was not checking for ESXi hosts that were powered off within a {vmw-first} cluster, which caused the installation to fail because the OVA could not be uploaded. With this release, the installer now checks the power status of each ESXi host and skips any that are powered off, which resolves the issue and allows the OVA to be imported successfully. (link:https://issues.redhat.com/browse/OCPBUGS-50649[OCPBUGS-50649])
* Previously, when using the Agent-based Installer, erroneous error messages regarding "unable to read image" were output when building the Agent ISO image in a disconnected environment. With this release, these erroneous messages have been removed and no longer appear. (link:https://issues.redhat.com/browse/OCPBUGS-50637[OCPBUGS-50637])
* Previously, when installing a cluster on {azure-short}, the installation program would crash with a segmentation fault error if it did not have the correct permissions to check IP address availability. With this update, the installation program correctly identifies the missing permission and fails gracefully. (link:https://issues.redhat.com/browse/OCPBUGS-50534[OCPBUGS-50534])
* Previously, when the `ClusterNetwork` classless inter-domain routing (CIDR) mask value is greater than the `hostPrefix` value and the `networking.ovnKubernetesConfig.ipv4.internalJoinSubnet` section is provided in the `install-config.yaml` file, the installation program failed a validation check and returned a Golang runtime error. With this release, the installation program still fails the validation check and now outputs a descriptive error message that indicates the invalid `hostPrefix` value. (link:https://issues.redhat.com/browse/OCPBUGS-49784[OCPBUGS-49784])
* Previously, when installing a cluster on {ibm-cloud-name}, the installation program failed to install on the `ca-mon` region even though it is available. With this update, the installation program is up to date with the latest available {ibm-cloud-name} regions. (link:https://issues.redhat.com/browse/OCPBUGS-49623[OCPBUGS-49623])
* Previously, after installing a cluster on {aws-short} with minimum permissions in an existing VPC with a user-provided public IPv4 pool, the cluster could not be destroyed due to a missing permission. With this update, the installation program propagates the `ec2:ReleaseAddress` permission so that the cluster can be destroyed. (link:https://issues.redhat.com/browse/OCPBUGS-49594[OCPBUGS-49594])
* Previously, the installer for {vmw-first} did not validate the number of networks provided in the `install-config.yaml` for failure domains. This caused the installation to proceed with an unsupported configuration if more than the maximum of 10 networks were specified, without providing an error. With this release, the installer now validates the number of configured networks, which resolves the issue by preventing the use of a configuration that exceeds the maximum limit. (link:https://issues.redhat.com/browse/OCPBUGS-49351[OCPBUGS-49351])
* Previously, installing a cluster on {aws-short} with existing subnets (BYO VPC) in Local or Wavelength zones resulted in the edge subnets resource missing the `kubernetes.io/cluster/<InfraID>:shared` tag. With this release, a fix ensures that all subnets used in the `install-config.yaml` file have the required tags. (link:https://issues.redhat.com/browse/OCPBUGS-48827[OCPBUGS-48827])
* Previously, an issue prevented configuring multiple subnets in the failure domain of a Nutanix cluster during installation. The issue is resolved in this release. (link:https://issues.redhat.com/browse/OCPBUGS-49885[OCPBUGS-49885])
* Previously, when installing a cluster on {aws-short}, the `ap-southeast-5` region was not available in the installation program survey, even though this region was supported by {product-title}. With this update, the `ap-southeast-5` region is available. (link:https://issues.redhat.com/browse/OCPBUGS-47681[OCPBUGS-47681])
* Previously, when destroying a cluster installed on {gcp-short}, some resources could be left behind because the installation program did not wait to ensure that all destroy operations completed successfully. With this update, the destroy API waits to ensure that all resources are appropriately deleted. (link:https://issues.redhat.com/browse/OCPBUGS-47489[OCPBUGS-47489])
* Previously, when installing a cluster on {aws-short} in the `us-east-1` regions, the installation could fail if no zone is specified in the `install-config.yaml` file because the `use1-az3` zone does not support any instance types supported by {product-title}. With this update, the installation program prevents the use of the `use1-az3` zone when no zones are specified in the installation configuration file. (link:https://issues.redhat.com/browse/OCPBUGS-47477[OCPBUGS-47477])
* Previously, if you attempted to install an {aws-first} cluster with minimum privileges and you did not specify an instance type in the `install-config.yaml` file, installation of the cluster failed. This issue happened because the installation program could not find supported instance types that the cluster uses in availability zones. For example, the `m6i.xlarge` default instance type was unavailable in `ap-southeast-4` and `eu-south-2` regions. With this release, the `openshift-install` program now requires the `ec2:DescribeInstanceTypeOfferings` {aws-short} permission so to prevent the installation of the cluster from failing in situations where `m6i.xlarge` or another support instance type is unavailable in a supported availability zone. (link:https://issues.redhat.com/browse/OCPBUGS-46596[OCPBUGS-46596])
* Previously, when installing a cluster on {gcp-short}, the installation would fail if you enabled the `constraints/compute.vmCanIpForward` constraint on your project. With this update, the installation program disables this constraint if it is enabled, allowing the installation to succeed. (link:https://issues.redhat.com/browse/OCPBUGS-46571[OCPBUGS-46571])
* Previously, when installing a cluster on {gcp-short}, the installation program would fail to detect if the user provided an encryption key ring that did not exist, causing the installation to fail. With this update, the installation program correctly validates the existence of user provided encryption key rings, preventing failure. (link:https://issues.redhat.com/browse/OCPBUGS-46488[OCPBUGS-46488])
* Previously, when destroying a cluster that was installed on {azure-first}, the inbound NAT rules and security groups for the bootstrap node were not deleted. With this update, the correct resource group ensures that all resources are deleted when the cluster is destroyed. (link:https://issues.redhat.com/browse/OCPBUGS-45429[OCPBUGS-45429])
* Previously, when installing a cluster on {aws-short} in the `ap-southeast-5` region, the installation could fail due to a malformed load balancer hostname. With this update, the installation program has been improved to form the correct hostname so that installation succeeds. (link:https://issues.redhat.com/browse/OCPBUGS-45289[OCPBUGS-45289])
* Previously, when installing a cluster on {gcp-short}, the installation program could fail to locate the service account it created due to a delay in activating the service account on Google's servers. With this update, the installation program waits an appropriate amount of time before attempting to use the created service account. (link:https://issues.redhat.com/browse/OCPBUGS-45280[OCPBUGS-45280])
* Previously, when installing a cluster on {aws-short}, the installation could fail if you specified an edge machine pool but did not specify an instance type. With this update, the installation program requires that an instance type be provided for edge machine pools. (link:https://issues.redhat.com/browse/OCPBUGS-45218[OCPBUGS-45218])
* Previously, when destroying a cluster installed on {gcp-short}, PVC disks with the label `kubernetes-io-cluster-<cluster-id>: owned` were not deleted. With this update, the installation program correctly locates and deletes these resources when the cluster is destroyed. (link:https://issues.redhat.com/browse/OCPBUGS-45162[OCPBUGS-45162])
* Previously, during a disconnected installation, when the `imageContentSources` parameter was configured for more than one mirror for a source, the command to create the agent ISO image could fail, depending on the sequence of the mirror configuration. With this release, multiple mirrors are handled correctly when the agent ISO is created and the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-44938[OCPBUGS-44938])
* Previously, when installing a cluster on {aws-short}, if the `publicIPv4Pool` parameter was set but the `ec2:AllocateAddress` permission was not present, the installation would fail. With this update, the installation program requires that this permission is present. (link:https://issues.redhat.com/browse/OCPBUGS-44925[OCPBUGS-44925])
* Previously, during a shared Virtual Private Cloud (VPC) installation, the installer added the records to a private DNS zone created by the installer instead of adding the records to the cluster’s private DNS zone. As a consequence, the installation failed. With this release, the installer searches for an existing private DNS zone and, if found, pairs that zone with the network that is supplied by the `install-config.yaml` file and the issue is resolved. (link:https://issues.redhat.com/browse/OCPBUGS-44641[OCPBUGS-44641])
* Previously, you could add white space to {aws-first} tag names but the installation program did not support them. This situation resulted in the installation program outputting an `ERROR failed to fetch Metadata` message. With this release, the regular expression for {aws-short} tags now validates any tag name that has white space so that the installation program accepts these tags and no longer outputs an error because of white space. (link:https://issues.redhat.com/browse/OCPBUGS-44199[OCPBUGS-44199])
* For clusters that were installed with the Agent-based Installer for versions 4.15.0 to 4.15.26, root certificates that were built in from CoreOS were added to the user-ca-bundle, even though they were not explicitly specified by the user. In previous releases, when adding a node to one of these clusters using the `oc adm node-image create` command, the `additionalTrustBundle` obtained from the cluster's user-ca-bundle was too large to process, resulting in a failure to add the node. With this release, the built-in certificates are filtered out when generating the `additionalTrustBundle`, so that only explicitly user-configured certificates are included, and nodes can be added successfully. (link:https://issues.redhat.com/browse/OCPBUGS-43990[OCPBUGS-43990])
* Previously, when destroying a cluster that was installing on {gcp-short}, forwarding rules, health checks and firewall rules were not deleted, leading to errors. With this update, all resources are deleted when the cluster is destroyed. (link:https://issues.redhat.com/browse/OCPBUGS-43779[OCPBUGS-43779])
* Previously, when installing a cluster on {azure-full}, specifying the `Standard_M8-4ms` instance type resulted in an error due to that instance type specifying its memory in decimal format instead of integer format. With this update, the installation program correctly parses the memory value. (link:https://issues.redhat.com/browse/OCPBUGS-42241[OCPBUGS-42241])
* Previously, when installing a cluster on {vmw-full}, installations could fail if the API and Ingress server virtual IPs were outside of the machine network. With this update, the installation program includes the API and Ingress server virtual IPs in the machine network by default. If you specify the API and Ingress server virtual IPs, ensure that they are in the machine network. (link:https://issues.redhat.com/browse/OCPBUGS-36553[OCPBUGS-36553])
[discrete]
[id="ocp-release-note-insights-operator-bug-fixes_{context}"]
==== Insights Operator
@@ -1728,6 +1807,12 @@ With this release, availability sets are no longer modified after creation, allo
[id="ocp-release-note-storage-bug-fixes_{context}"]
==== Storage
[discrete]
[id="ocp-release-note-image-registry-bug-fixes_{context}"]
==== Registry
* Previously, image importing from blocked registries would fail if those registries were configured with `NeverContactSource`, even when mirror registries were set up. With this update, image importing is no longer blocked when a registry has mirrors configured. This ensures that image imports succeed even if the original source was set to `NeverContactSource` in the `ImageDigestMirrorSet` or `ImageTagMirrorSet` resources. (link:https://issues.redhat.com/browse/OCPBUGS-44432[OCPBUGS-44432])
[discrete]
[id="ocp-release-note-windows-containers-bug-fixes_{context}"]
==== Windows containers