diff --git a/release_notes/ocp-4-18-release-notes.adoc b/release_notes/ocp-4-18-release-notes.adoc index dd354575487b..5576d5ec4c01 100644 --- a/release_notes/ocp-4-18-release-notes.adoc +++ b/release_notes/ocp-4-18-release-notes.adoc @@ -529,7 +529,7 @@ For more information, see xref:../nodes/clusters/nodes-cluster-enabling-features In this release, enhancements have been made to the Rapid Recommendations mechanism for remotely configuring the rules that determine the data that the Insights Operator collects. -The Rapid Recommendations feature is version-independent, and builds on the existing conditional data gathering mechanism. +The Rapid Recommendations feature is version-independent, and builds on the existing conditional data gathering mechanism. The Insights Operator connects to a secure remote endpoint service running on _console.redhat.com_ to retrieve definitions that contain the rules for determining which container log messages are filtered and collected by Red{nbsp}Hat. @@ -609,7 +609,7 @@ You must configure {rh-openstack} prior to deploying your {product-title} cluste [id="ocp-4-18-installation-and-update-nutanix-multiple-nics_{context}"] ==== Installing a cluster on Nutanix with multiple subnets -With this release, you can install a Nutanix cluster with more than one subnet for the Prism Element into which you are deploying an {product-title} cluster. +With this release, you can install a Nutanix cluster with more than one subnet for the Prism Element into which you are deploying an {product-title} cluster. For more information, see xref:../installing/installing_nutanix/installing-nutanix-installer-provisioned.adoc#installation-configuring-nutanix-failure-domains_installing-nutanix-installer-provisioned[Configuring failure domains] and xref:../installing/installing_nutanix/installation-config-parameters-nutanix.adoc#installation-configuration-parameters-additional-nutanix_installation-config-parameters-nutanix[Additional Nutanix configuration parameters]. @@ -2570,18 +2570,18 @@ There is no workaround for this issue. * The following known issues exist for configuring multiple subnets for an existing Nutanix cluster by using a control plane machine set: + --- +-- ** Adding subnets above the existing subnet in the `subnets` stanza causes a control plane node to become stuck in the `Deleting` state. As a workaround, only add subnets below the existing subnet in the `subnets` stanza. ** Sometimes, after adding a subnet, the updated control plane machines appear in the Nutanix console but the {product-title} cluster is unreachable. There is no workaround for this issue. --- +-- + These issues occur on clusters that use a control plane machine set to configure subnets regardless of whether subnets are specified in a failure domain or the provider specification. -(link:https://issues.redhat.com/browse/OCPBUGS-50904[*OCPBUGS-50904*]) +(link:https://issues.redhat.com/browse/OCPBUGS-50904[*OCPBUGS-50904*]) -* There is a known issue with {op-base-system} 8 worker nodes that use `cgroupv1` Linux Control Groups (cgroup). The following is an example of the error message displayed for impacted nodes: `UDN are not supported on the node ip-10-0-51-120.us-east-2.compute.internal as it uses cgroup v1.` As a workaround, users should migrate worker nodes from `cgroupv1` to `cgroupv2`. (link:https://issues.redhat.com/browse/OCPBUGS-49933[*OCPBUGS-49933*]) +* There is a known issue with nodes that use `cgroupv1` Linux Control Groups (cgroup). The following is an example of the error message displayed for impacted nodes: `UDN are not supported on the node ip-10-0-51-120.us-east-2.compute.internal as it uses cgroup v1.` An event of type `Warning` `UDNKubeletProbesNotSupported` is triggered for impacted nodes. As a workaround, users must reconfigure their nodes from `cgroupv1` to `cgroupv2` before creating a user-defined network. For more information, see xref:../nodes/clusters/nodes-cluster-cgroups-2.adoc#nodes-cluster-cgroups-2[Configuring Linux cgroup]. (link:https://issues.redhat.com/browse/OCPBUGS-49933[*OCPBUGS-49933*]) * The current PTP grandmaster clock (T-GM) implementation has a single National Marine Electronics Association (NMEA) sentence generator sourced from the GNSS without a backup NMEA sentence generator. If NMEA sentences are lost before reaching the e810 NIC, the T-GM cannot synchronize the devices in the network synchronization chain and the PTP Operator reports an error. A proposed fix is to report a `FREERUN` event when the NMEA string is lost. Until this limitation is addressed, T-GM does not support PTP clock holdover state. (link:https://issues.redhat.com/browse/OCPBUGS-19838[*OCPBUGS-19838*])