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

RNs-Installer-bugs:adds bug text to RNs

Browse Source
This commit is contained in:
JoeAldinger
2022-07-28 11:39:36 -04:00
parent a57214d4af
commit 1a7348fe69
1 changed files with 20 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
release_notes/ocp-4-11-release-notes.adoc
View File

@@ -1278,6 +1278,26 @@ sourceStrategy:
[id="ocp-4-11-installer-bug-fixes"]
==== Installer
* Previously, if users specified an {product-title} cluster name with a period, the installation failed. This update adds a validation check to the installation program, which returns an error if a period is present in the cluster name. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2084580[*BZ#2084580*])
* Previously, users could select the AWS `us-gov-east-1` region when using the installation program to create the `install-config.yaml` file. This caused the deployment to fail because the installation program could only be used to create the `install-config.yaml` file for a public AWS region. This update removes all of the AWS regions from the installation program that are not supported by the public AWS cloud. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2048222[*BZ#2048222*])
* Previously, users could not select the `ap-north-east-3` region when using the installation program to create the `install-config.yaml` file. The AWS SDK that caused this problem has been updated, and users can now select the `ap-north-east-3` region. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1996544[*BZ#1996544*])
* Previously, installing a private (internal) {product-title} cluster on Azure Stack Hub failed because the installation program did not create the DNS record for the API virtual IP address. This update removes the invalid check that caused this problem. The installation program now correctly creates DNS records for private cluster. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2061549[*BZ#2061549*])
* Previously, uninstalling an IBM Cloud VPC cluster might have caused unexpected results. When a user uninstalled a cluster (cluster 1), the DNS records of another cluster (cluster 2) were removed when either the name of cluster 1 (example) was a subset of the name of cluster 2 (myexample) or both clusters shared a base domain. This update corrects this behavior. Only those resources specific to the cluster that is being uninstalled are now removed. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2060617[*BZ#2060617*])
* Previously, Azure Stack Hub did not support any disk types other than Standard_LRS. This update adds the ability to customize disk types, which allows clusters to have a default disk type with no manual customizations. This resulted in making the switch from hard coding the disk type to accepting the inputs from the user and validating it against the Stack Hub APIs. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2061544[*BZ#2061544*])
* Previously, when destroying a cluster, the ID of the private route5 hosted zone for the cluster was incorrectly reported when the DNS records were deleted from the hosted zone. This caused incorrect host zone IDs to be reported in the log of the destroyer. This update uses the correct host zone ID in the log. As a result, the log shows the correct hosted zone ID when destroying the DNS record in the base domain's hosted zone. (https://bugzilla.redhat.com/show_bug.cgi?id=1965969[*BZ#1965969*])
* Previously, system proxy settings were not considered when requesting an AWS custom service endpoint. This update configures AWS custom service endpoint validation to consider the system proxy settings along with a `HEAD` request to the AWS custom service endpoint. As a result, the AWS custom service endpoint can be accessed from the user's machine. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2048451[*BZ#2048451*])
* Previously, the installer used any Terraform provider in the `$PATH` on the installer host. Therefore, the installation would fail if there were Terraform providers in the `$PATH` that used an incorrect version or provider instead of the providers embedded in the installation program. With this update, the installation program embeds providers to a known directory and sets Terraform to use the known directory. As a result, installation will be successful because the installation program will always use the providers in the known directory. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1932812[*BZ#1932812*])
* Previously, there was an eventual consistency issue in the AWS Terraform provider when updating new load balancers. Therefore, the installation would fail when trying to access the new load balancers. With this fix, the installer is now updated to an upstream Terraform provider, which ensures eventual consistency. As a result, the installation does not fail. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1898265[*BZ#1898265*])
[discrete]
[id="ocp-4-11-kube-api-server-bug-fixes"]
==== Kubernetes API server