fixup! PRR review

Author: pohly

keps/sig-scheduling/5027-dra-admin-controlled-device-attributes/README.md

@@ -211,12 +211,15 @@ part of this proposal.
 Perhaps `kubectl describe resourceslices` can be extended to include the
 additional information. For now this is out of scope.
 
-Creating a ResourceSlicePatch is racing with on-going scheduling attempts,
-which is unavoidable. Removing a device from a ResourceSlice has the same
-problem.
-
 ### Risks and Mitigations
 
+Creating a ResourceSlicePatch is racing with on-going scheduling attempts.
+This is unavoidable. Removing a device from a ResourceSlice has the same
+problem: updates need to reach the scheduler before it can consider them.
+Evaluating a patch on the client-side instead of [having a controller update
+slices]((#storing-result-of-patching-in-resourceslice) mitigates this risk by
+shortening the time window where updates must be sent to the scheduler.
+
 From a security perspective, permission to patch device attributes is
 expected to be limited to privileged users who already have the ability to add
 or remove DRA drivers, so there won't be a substantial difference.
@@ -277,9 +280,14 @@ type DevicePatch struct {
     // capacity, the value of the DevicePatch is used. If multiple
     // different DevicePatches match the same device, then the one with
     // the highest priority wins. If priorities are equal, the older
-    // patch wins. This ensures that adding a new patch does not
+    // patch wins, where "older" is determined based on the creation time.
+    // This ensures that adding a new patch does not
     // accidentally change the effect of some existing patch unless
-    // that is clearly intended according to the priority.
+    // that is clearly intended according to the priority. Updates
+    // do not change the creation time, so it could still happen that
+    // a more recent change is preferred because it happens to be in
+    // an older DevicePatch. Overall it is better to set the
+    // priority to different values to avoid such ambiguities.
     //
     // +optional
     Priority *int

keps/sig-scheduling/5055-dra-device-taints-and-tolerations/README.md

@@ -207,6 +207,14 @@ ResourceSlicePatch with a unique name, then remember to remove that
 ResourceSlicePatch again. For beta, support in `kubectl` for common
 operations may be needed.
 
+Users might be tempted to tolerate taints to get their pods running. They do
+that at their own risk. Depending on the taint, the application then may not
+get the performance it needs (degraded hardware) or may fail at runtime
+(hardware gets turned off). Admission controllers or validating admission
+policies could be deployed to limit which tolerations may be used, but as
+taints are not defined by Kubernetes itself, none of that is part of Kubernetes
+itself.
+
 ## Design Details
 
 The feature is following the approach and APIs taken for node taints and