Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

BZ1975701: Known issue for Tang on vSphere #37558

Merged
merged 1 commit into from Oct 14, 2021
Merged

BZ1975701: Known issue for Tang on vSphere #37558

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
2 changes: 2 additions & 0 deletions release_notes/ocp-4-9-release-notes.adoc
View file
Open in desktop
Expand Up @@ -2021,6 +2021,8 @@ As a workaround, cluster administrators can delete the `catalog-operator` pod in

* When MetalLB is run in layer 2 mode with the OVN-Kubernetes Container Network Interface network provider, instead of a single node with a speaker pod responding to an ARP or NDP request, every node in the cluster responds to the request. The unexpected number of ARP responses might resemble an ARP-spoofing attack. Although the experience is different than designed, traffic is routed to the service as long as no software on the hosts or subnet is configured to block ARP. This bug is fixed in a future {product-title} release. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1987445[*BZ#1987445*])

* When Tang disk encryption and a static IP address configuration are applied on a VMWare vSphere user-provisioned infrastructure cluster, the nodes fail to boot properly after they are initially provisioned. (link:https://bugzilla.redhat.com/show_bug.cgi?id=1975701[*BZ#1975701*])

[id="ocp-4-9-asynchronous-errata-updates"]
== Asynchronous errata updates

Expand Down