TAS: introduce dedicated TAS label

[mimowo]

What type of PR is this?

/kind feature

What this PR does / why we need it:

This label will be used in two places:

• to trigger reconcile from TopologyUngater only for pods managed by TAS, without relying on the fact that the "workload"
  annotation or "podset" label is only used for TAS
• used when computing usage from non-TAS pods, by selector which avoids TAS pods

Which issue(s) this PR fixes:

Part of #2724

Special notes for your reviewer:

No release note here, as I added one already for TAS in the API PR.

Does this PR introduce a user-facing change?

NONE

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mimowo

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [mimowo]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[mimowo]

/assign @PBundyra @gabesaba @tenzen-y

[netlify]

✅ Deploy Preview for kubernetes-sigs-kueue canceled.

Name	Link
🔨 Latest commit	41f961f
🔍 Latest deploy log	https://app.netlify.com/sites/kubernetes-sigs-kueue/deploys/67163e54c7153400096b8de8

[PBundyra]

/lgtm
/hold for at least one more pair of eyes

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: f8ffe1da94130543750110e71ea0a08145dd95a8

[mimowo]

/hold
I synced on this with @tenzen-y offline and I will investigate if we could use indexer to use a "virtual" field for it based on the Workload object indicated by the kueue.x-k8s.io/workload annotation

[tenzen-y]

I discussed this dedicated label with @mimowo offline.
In conclusion, we will investigate the solution to store TAS usage in the Workload object.

So, for a while, we will keep this open.

[PBundyra]

I discussed this dedicated label with @mimowo offline. In conclusion, we will investigate the solution to store TAS usage in the Workload object.

So, for a while, we will keep this open.

I believe this label in contrary to storing this information in Workload object, brings value from the user perspective. Users can easily filter out pods that were scheduled by TAS using kubectl, which can be useful for scripts and debugging

[mimowo]

I agree, which is another argument with the label rather than indexed virtual field, wdyt @tenzen-y ?

[tenzen-y]

I agree, which is another argument with the label rather than indexed virtual field, wdyt @tenzen-y ?

I discussed this with @mimowo offline.
The TAS label is mainly used by internal mechanisms, and if we justify the label to identify which kueue scheduling mechanism handles the Pod, that will justify adding labels kueue.x-k8s.io/generic-scheduler: "true", or future new Kueue scheduling mechanism labels.

The TAS label implies giving special treatment to the TAS in the Kueue, but I don't think we should do it. We should handle all scheduling mechanisms fairly, and users should not care about the internal mechanism (generic scheduling vs. TAS).
If batch admins want to deeply debug the Kueue behavior, admins can refer to the Workload object.

Hence, if possible, we should store the information in the Workload object.
But, I will approve this label solution for now since the release schedule is slightly tight, and the TAS label is completely guarded by the Alpha feature gate, and the label can be removed in the next release.

cc: @PBundyra

[tenzen-y]

Thanks!
/lgtm

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 0a0db8a2f26c2cf21e719179b0da52910941f814

[tenzen-y]

/hold cancel