From f31a9267be1bf8e27c26a3ce97b61e97dc7b757d Mon Sep 17 00:00:00 2001
From: Roman Bednar <rbednar@redhat.com>
Date: Mon, 3 Apr 2023 13:58:20 +0200
Subject: [PATCH] update KEP to match latest template

---
 .../README.md                                         | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/keps/sig-storage/3762-persistent-volume-last-phase-transition-time/README.md b/keps/sig-storage/3762-persistent-volume-last-phase-transition-time/README.md
index 47986af9eae..2429054b4d9 100644
--- a/keps/sig-storage/3762-persistent-volume-last-phase-transition-time/README.md
+++ b/keps/sig-storage/3762-persistent-volume-last-phase-transition-time/README.md
@@ -869,6 +869,17 @@ This through this both in small and large cases, again with respect to the
 [supported limits]: https://git.k8s.io/community//sig-scalability/configs-and-limits/thresholds.md
 -->
 
+###### Can enabling / using this feature result in resource exhaustion of some node resources (PIDs, sockets, inodes, etc.)?
+
+<!--
+Focus not just on happy cases, but primarily on more pathological cases
+(e.g. probes taking a minute instead of milliseconds, failed pods consuming resources, etc.).
+If any of the resources can be exhausted, how this is mitigated with the existing limits
+(e.g. pods per node) or new limits added by this KEP?
+Are there any tests that were run/should be run to understand performance characteristics better
+and validate the declared limits?
+-->
+
 ### Troubleshooting
 
 <!--