Adressed comments

Author: mortent

keps/sig-scheduling/4816-dra-prioritized-list/README.md

@@ -255,36 +255,40 @@ nitty-gritty.
 The `ResourceClaim` object contains a `DeviceClaim`, which in turn contains a
 list of `DeviceRequest` objects. This allows the user to allocate different
 types of devices for the same claim, and apply constraints and configuration
-across those different requests.
-
-The proposal restructures the `DeviceRequest` object so there will be a
-`Name` field just like today, but for supporting either a single request
-or a prioritized list there will be the fields `Exactly` for a request without
-alternatives (type `SpecificDeviceRequest`) and `FirstAvailable` for providing a
-prioritized list of requests (type `DeviceSubRequest`). The other fields that are
-currently in the `DeviceRequest` object will be moved into one or both of the
-`SpecifiecDeviceRequest` and `DeviceSubRequest` objects. 
-The list provided in the `FirstAvailable` field is
-considered a priority order, such that the scheduler will only try to use
-the second item in the list if it is unable to satisfy the first item,
-and so on. The `Exactly` and `FirstAvailable` fields are mutually exclusive.
-This is a breaking change to the `v1beta1` API, so this will be added in a
-new `v1beta2` resource API.
-
-For the `v1beta1` API, there will be a new field called `FirstAvailable`
+across those different requests. These changes allow some flexibility for the
+user to create, say, a "gpu" request, but allow it to be satisfied by one of
+several models of GPU.
+
+To avoid introducing a breaking API change and to ensure round-tripping
+between the APIs, the `v1beta1` API will remain backward compatible 
+(only extended) and the final change will be made in `v1beta2`.
+
+The `v1beta1` API will be extended with a new field called `FirstAvailable`
 which will contain an ordered list of `DeviceSubRequest` objects. In order to
 satisfy the main (containing) request, exactly one of the requests listed in
 `FirstAvailable` must be satisfied. The order listed is considered a priority
 order, such that the scheduler will only try to use the second item in the list
 if it is unable to satisfy the first item, and so on. This extension to the API
 is not breaking, but it makes for a somewhat awkward API where many fields on
-the `DeviceRequest` (in fact all existing fields except `Name`) should not be
-used whenever `FirstAvailable` is used. To avoid this long term we are
-adding the `v1beta2` API described above, while doing the backwards-compatible
-change in the `v1beta1` API to ensure round-tripping between the APIs will work.
-
-These changes allow some flexibility for the user to create, say, a "gpu"
-request, but allow it to be satisfied by one of several models of GPU.
+the `DeviceRequest` (in fact all existing fields except `Name`) must not be
+set whenever `FirstAvailable` is set. To avoid this API in the long term, we are
+adding the `v1beta2` API described next.
+
+For the `v1beta2` API, the `DeviceRequest` object will be restructured
+so that there will be the `Name` field just like today, and for supporting
+either a single request or a prioritized list of subrequests, there will
+be separate fields:
+
+* `Exactly` for a request of type `SpecificDeviceRequest` without alternatives.
+`SpecificDeviceRequest` will include all the fields that exists on the
+`DeviceRequest` type in `v1beta1`, except the `Name` field.
+* `FirstAvailable` for providing a prioritized list of requests, each of
+type `DeviceSubRequest`. The `DeviceSubRequest` type is similar to
+`SpecificDeviceRequest`, except for the `AdminAccess` field that is not
+available when providing multiple alternatives. The list provided in the
+`FirstAvailable` field is considered a priority order, such that the
+scheduler will only try to use the second item in the list if it is unable
+to satisfy the first item, and so on.
 
 ### User Stories
 
@@ -621,13 +625,13 @@ type DeviceRequest struct {
 // is not supported by the client yet, in which case it must refuse to
 // handle the request.
 type DeviceSubRequest struct {
-    // Name can be used to reference this subrequest in a pod.spec.containers[].resources.claims
-    // entry and in a constraint of the claim. References must use the
-    // format <parent request>/<subrequest>.
-    //
-    // Must be a DNS label.
-    //
-    // +required
+	// Name can be used to reference this subrequest in the list of constraints
+	// or the list of configurations for the claim. References must use the
+	// format <main request>/<subrequest>.
+	//
+	// Must be a DNS label.
+	//
+	// +required
     Name string `json:"name" protobuf:"bytes,1,name=name"`
 
     // DeviceClassName references a specific DeviceClass, which can define
@@ -1007,7 +1011,7 @@ they are all local to the control plane.
 
 The proposed API change relaxes a `required` constraint on the
 `DeviceRequest.DeviceClassName` field. The `DeviceRequest` thus becomes a one-of
-that must have either the `DeviceClassName` or the `FirstAvailableOf` field
+that must have either the `DeviceClassName` or the `FirstAvailable` field
 populated.
 
 Older clients have been advised in the current implementation to check this
@@ -1070,7 +1074,7 @@ This is an add-on on top of the `DynamicResourceAllocation` feature gate, which
 also must be enabled for this feature to work.
 
 - [x] Feature gate (also fill in values in `kep.yaml`)
-  - Feature gate name: DRAFirstAvailableOf
+  - Feature gate name: DRAFirstAvailable
   - Components depending on the feature gate:
     - kube-apiserver
     - kube-scheduler
@@ -1506,7 +1510,7 @@ type ResourceClaimSpec struct {
 This is arguably simpler and allows them to be essentially complete, alternate
 claims. It would be more difficult for the user, though, as it would require
 duplication of other device requests. Additionally, if there were multiple
-separate `FirstAvailableOf` requests in a claim, the user would have to specify
+separate `FirstAvailable` requests in a claim, the user would have to specify
 all the combinations of those in order to get the same flexibility.
 
 ## Infrastructure Needed (Optional)

keps/sig-scheduling/4816-dra-prioritized-list/kep.yaml

@@ -28,18 +28,18 @@ stage: alpha
 # The most recent milestone for which work toward delivery of this KEP has been
 # done. This can be the current (upcoming) milestone, if it is being actively
 # worked on.
-latest-milestone: "v1.32"
+latest-milestone: "v1.33"
 
 # The milestone at which this feature was, or is targeted to be, at each stage.
 milestone:
-  alpha: "v1.32"
-  beta: "v1.33"
-  stable: "v1.34"
+  alpha: "v1.33"
+  beta: "v1.34"
+  stable: "v1.35"
 
 # The following PRR answers are required at alpha release
 # List the feature gate name and the components for which it must be enabled
 feature-gates:
-  - name: DRAFirstAvailableOf
+  - name: DRAPrioritizedList
     components:
       - kube-apiserver
       - kube-controller-manager