KEP 5075: apply text edit suggestions

Signed-off-by: Sunyanan Choochotkaew <[email protected]>

Author: sunya-ch

keps/sig-scheduling/5075-dra-consumable-capacity/README.md

@@ -95,10 +95,10 @@ SIG Architecture for cross-cutting KEPs).
 
 Items marked with (R) are required *prior to targeting to a milestone / release*.
 
-- [ ] (R) Enhancement issue in release milestone, which links to KEP dir in [kubernetes/enhancements] (not the initial KEP PR)
-- [ ] (R) KEP approvers have approved the KEP status as `implementable`
-- [ ] (R) Design details are appropriately documented
-- [ ] (R) Test plan is in place, giving consideration to SIG Architecture and SIG Testing input (including test refactors)
+- [x] (R) Enhancement issue in release milestone, which links to KEP dir in [kubernetes/enhancements] (not the initial KEP PR)
+- [x] (R) KEP approvers have approved the KEP status as `implementable`
+- [x] (R) Design details are appropriately documented
+- [x] (R) Test plan is in place, giving consideration to SIG Architecture and SIG Testing input (including test refactors)
   - [ ] e2e Tests for all Beta API Operations (endpoints)
   - [ ] (R) Ensure GA e2e tests meet requirements for [Conformance Tests](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/conformance-tests.md) 
   - [ ] (R) Minimum Two Week Window for GA e2e tests to prove flake free
@@ -135,7 +135,9 @@ To achieve this, this KEP introduces
 - a capacity-aware scheduling mechanism that allows limiting or guaranteeing the capacity of devices among the resource claims (or requests) those are sharing,
 - a new capacity requirement field in the device request of the resource claim,
 - a new consumed capacity field in the allocation result of the resource claim,
-- a method to associate the allocated device status to the allocation result in the resource claim,
+- a method to associate the allocated device status to the allocation result in the resource claim.
+
+With those in place, a resource claim with multiple requests might allocate the same device multiple times. This may or may not be desired, so this KEP also introduces:
 - a distinct attribute constraint to prevent allocating the same shareable device in the same claim multiple times.
 
 Relations to other KEPs:
@@ -165,7 +167,7 @@ In other words, the device capacity allocation is determined by the user's claim
 
 - Define driver-specific attributes and configs (such as CNI parameter config).
 - Support network security policy.
-- Supports aggregated resource consumption where multiple devices are allocated to satisfy a single capacity request.
+- Support aggregated resource consumption where multiple devices are allocated to satisfy a single capacity request.
   This is related to [the comment about `distinctAttributes`](https://github.com/kubernetes/enhancements/pull/5104#discussion_r1943835445).
 - Support an extended use case where the resource guaranteeing behavior is determined by the first user request.
   For example, if the first request does not require a guarantee, the resource remains unguaranteed.
@@ -212,7 +214,7 @@ users specifies their required guaranteed bandwidth. Otherwise, the default valu
   **Mitigation:**
   - To preserve the original behavior during this transition, the driver should set the default consumed capacity to the maximum value. This ensures consistency with the previous non-shareable configuration.
   - The existing allocation result, which has no share ID (as it was previously a non-shareable device), will be included in the allocated list
-  and cannot be reallocated to another pod during the scheduling process.
+  and ensures that the device cannot be allocated for another resource claim during the scheduling process.
 
 - When a driver changes a capacity from non-consumable to consumable for a device that is already shareable, the behavior of resource claims changes.
   While the capacity is non-consumable, a resource claim for that specific capacity will always guarantee a value of zero.
@@ -233,7 +235,7 @@ For examples of device driver migration, see the [Examples](#examples) section b
 This enhancement introduces a `allowMultipleAllocations` field within the `Device` of the ResourceSlice
 to mark whether the device is shareable among multiple resource claims (or requests).
 The multi-allocatable device can be assigned to more than one request if it satisfies the selection criteria and constraints.
-The select condition `device.allowMultipleAllocations == true/false` is used to identify to select the device with a `allowMultipleAllocations` property or not.
+The select condition `device.allowMultipleAllocations == true/false` can be used to select the device with a `allowMultipleAllocations` property or not in a CEL selector.
 
 The enhancement also adds a `SharingPolicy` field to `DeviceCapacity`.
 This field specifies how the capacity can be shared between different requests.
@@ -301,11 +303,11 @@ type DeviceCapacity struct {
 
 // CapacitySharingPolicy defines how requests consume the available capacity.
 // A policy must have a default value to be applied when no value is explicitly provided.
-// ValidSharingValues can either specify a range of valid values or a discrete set of them.
+// It can either specify a range of valid values or a discrete set of them.
 // Exactly one of them must be defined.
 // The default value must be a valid value.
 type CapacitySharingPolicy struct {
-   // Default specifies the default capacity to be used for a consumption request
+   // Default specifies the default capacity to be used for a consumption request.
    //
    // +required
    Default resource.Quantity
@@ -865,7 +867,7 @@ implementing this enhancement to ensure the enhancements have also solid foundat
 - can gather consumed capacity from allocated resource claims
 - can add/remove consumed capacity of allocating devices
 - can round up and compute user-requesting minimum capacity according to sharing policy range and chunk size
-- can check sharing policy violation
+- requested capacity for non-consumable capacity acts like a `>=` filter
 
 **Distinct Attribute**
 - can prevent allocating the same device in the same request with a distinct constraint