Description
The Workload Detail page's "Admission Checks" section renders each entry from status.admissionChecks[], but drops one of the real fields on that struct.
Per the Kueue v1beta2 API reference, AdmissionCheckState has these fields:
name, state, lastTransitionTime, message, requeueAfterSeconds, retryCount, podSetUpdates
https://kueue.sigs.k8s.io/docs/reference/kueue.v1beta2/#kueue-x-k8s-io-v1beta2-AdmissionCheckState
The plugin's AdmissionCheckState type (kueue/src/resources/workload.ts) declares
name/state/lastTransitionTime/message/requeueAfterSeconds/retryCount, but not podSetUpdates. getAdmissionCheckRows() in
kueue/src/components/workloads/Detail.tsx builds table rows from the same six fields, so podSetUpdates is silently dropped end to end.
podSetUpdates is where an AdmissionCheck controller (for example a ProvisioningRequest-backed check driving cluster-autoscaler) reports the actual pod-set modifications it applied — e.g. the annotation that ties a Pod to its ProvisioningRequest. Kueue's own docs show this as the field operators check first when troubleshooting why an admission check is stuck:
admissionChecks:
- lastTransitionTime: "2023-10-20T06:40:14Z"
message: ""
name: sample-prov
podSetUpdates:
- annotations:
cluster-autoscaler.kubernetes.io/consume-provisioning-request: job-prov-job-9815b-sample-prov
name: main
state: Pending
https://kueue.sigs.k8s.io/docs/concepts/admission_check/
Steps to reproduce
- Connect Headlamp to a cluster with an AdmissionCheck controller that sets podSetUpdates (e.g. a ProvisioningRequest-backed check, or any custom controller that returns pod-set annotations/node selectors/tolerations).
- Create a Workload whose LocalQueue routes through a ClusterQueue using that AdmissionCheck, so status.admissionChecks[0].podSetUpdates gets populated.
- Open Kueue > Workloads, and the detail page for that Workload.
- Look at the "Admission Checks" table.
Actual
The table shows Name / State / Last Transition / Message / Requeue After Seconds / Retry Count only. podSetUpdates isn't rendered anywhere on the page, even though it's present in status.admissionChecks[].
Expected
The Admission Checks section should surface podSetUpdates (pod set name plus whatever annotations/labels/node selectors/tolerations/scheduling gates the check applied), so operators can see it in Headlamp instead of dropping to kubectl describe workload or reading raw YAML.
Environment
- kueue plugin,
main @ (current)
- @kinvolk/headlamp-plugin 0.14.0
Description
The Workload Detail page's "Admission Checks" section renders each entry from
status.admissionChecks[], but drops one of the real fields on that struct.Per the Kueue v1beta2 API reference,
AdmissionCheckStatehas these fields:The plugin's
AdmissionCheckStatetype (kueue/src/resources/workload.ts) declaresname/state/lastTransitionTime/message/requeueAfterSeconds/retryCount, but not podSetUpdates.
getAdmissionCheckRows()inkueue/src/components/workloads/Detail.tsx builds table rows from the same six fields, so podSetUpdates is silently dropped end to end.
podSetUpdates is where an AdmissionCheck controller (for example a ProvisioningRequest-backed check driving cluster-autoscaler) reports the actual pod-set modifications it applied — e.g. the annotation that ties a Pod to its ProvisioningRequest. Kueue's own docs show this as the field operators check first when troubleshooting why an admission check is stuck:
Steps to reproduce
Actual
The table shows Name / State / Last Transition / Message / Requeue After Seconds / Retry Count only. podSetUpdates isn't rendered anywhere on the page, even though it's present in status.admissionChecks[].
Expected
The Admission Checks section should surface podSetUpdates (pod set name plus whatever annotations/labels/node selectors/tolerations/scheduling gates the check applied), so operators can see it in Headlamp instead of dropping to
kubectl describe workloador reading raw YAML.Environment
main@ (current)