Adressed comments

Author: mortent

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

@@ -255,23 +255,15 @@ 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
@@ -283,8 +275,21 @@ 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.
+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
 
@@ -1007,7 +1012,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 +1075,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 +1511,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)