The new DRAAdminAccess feature gate has the following effects:
- If disabled in the apiserver, the spec.devices.requests[*].adminAccess
field gets cleared. Same in the status. In both cases the scenario
that it was already set and a claim or claim template get updated
is special: in those cases, the field is not cleared.
Also, allocating a claim with admin access is allowed regardless of the
feature gate and the field is not cleared. In practice, the scheduler
will not do that.
- If disabled in the resource claim controller, creating ResourceClaims
with the field set gets rejected. This prevents running workloads
which depend on admin access.
- If disabled in the scheduler, claims with admin access don't get
allocated. The effect is the same.
The alternative would have been to ignore the fields in claim controller and
scheduler. This is bad because a monitoring workload then runs, blocking
resources that probably were meant for production workloads.
These metrics can provide insights into ResourceClaim usage. The total count is
redundant because the apiserver also provides count of resources, but having it
in the same sub-system next to the count of allocated claims might be more
discoverable and helps monitor the controller itself.
This removes the DRAControlPlaneController feature gate, the fields controlled
by it (claim.spec.controller, claim.status.deallocationRequested,
claim.status.allocation.controller, class.spec.suitableNodes), the
PodSchedulingContext type, and all code related to the feature.
The feature gets removed because there is no path towards beta and GA and DRA
with "structured parameters" should be able to replace it.
* change format of event
* include `from 0` for new replicas
* update describe tests to reflect current output
Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
Fix typo and grammar in comments that get reflected through to the
generated documentation, regarding VolumeAttachments' use of
PersistentVolumes and PersistentVolumeClaims.
Signed-off-by: Eric Blake <eblake@redhat.com>
The endpoints controller store the resource version of the previous
Endpoints objects to avoid issues related to stale information on the
cache.
However, there can be update operations that succeed without increasing
the resource version, causing the endpoints controller to declare stale
the existing Resource Version and stopping the Endpoints to be updated.
Co-Author-By: Quan Tian <quan.tian@broadcom.com>
Co-Author-By: Yang Yang <yyyng@amazon.com>
Improve PVC protection controller's scalability by batch-processing PVCs by namespace & caching live pod list results [fixed dead loop issue with idle work queue]
