OSDOCS-5987-ki:adds storage ki

release_notes/ocp-4-14-release-notes.adoc

@@ -1972,9 +1972,9 @@ This behavior has been fixed, and the references are now accepted and correctly
 
 * Previously, pods were stuck in the `ContainerCreating` state on Google Cloud Platform Confidential Computing instances, which caused a volume mount failure. This fix adds support for the Persistent Disk storage type for Confidential Computing instances in Google Cloud Platform, which can be used as persistent volumes in {product-title}. As a result, pods are able to enter a `Running` state and volumes can be mounted. (link:https://issues.redhat.com/browse/OCPBUGS-7582[*OCPBUGS-7582*])
 
-[discrete]
-[id="ocp-4-14-scalability-and-performance-bug-fixes"]
-==== Scalability and performance
+//[discrete]
+//[id="ocp-4-14-scalability-and-performance-bug-fixes"]
+//==== Scalability and performance
 
 [discrete]
 [id="ocp-4-14-storage-bug-fixes"]
@@ -2760,6 +2760,10 @@ It is anticipated that an upcoming z-stream release will include a fix for this
 
 * There is a known issue after enabling and disabling IPsec during runtime that causes the cluster to be in an unhealthy state with the error message: `an unknown error has occurred: MultipleErrors`. (link:https://issues.redhat.com/browse/OCPBUGS-19408[*OCPBUGS-19408*])
 
+* Creating pods with Microsoft Azure File NFS volumes that are scheduled to the control plane node causes the mount to be denied.
++
+To work around this issue: If your control plane nodes are schedulable, and the pods can run on worker nodes, use `nodeSelector` or Affinity to schedule the pod in worker nodes.(link:https://issues.redhat.com/browse/OCPBUGS-18581[*OCPBUGS-18581*])
+
 [id="ocp-4-14-asynchronous-errata-updates"]
 == Asynchronous errata updates