TAS: validate the preferred and required annotations for Job and JobSet

[mimowo]

What type of PR is this?

/kind feature

What this PR does / why we need it:

Which issue(s) this PR fixes:

Part of #2724

Special notes for your reviewer:

Only covering Job and JobSet in the PR, but I would like to follow this up extending the support for all Job types hopefully for alpha. If the pattern is established it should be rather fast.

Does this PR introduce a user-facing change?

NONE

[netlify[bot]]

✅ Deploy Preview for kubernetes-sigs-kueue canceled.

Name	Link
🔨 Latest commit	7c70a6ec8bd5e82fcfc959a7d159c1641cb16e56
🔍 Latest deploy log	https://app.netlify.com/sites/kubernetes-sigs-kueue/deploys/671bb99fc2f43200083ae67c

[mimowo]

/cc @PBundyra @tenzen-y

[mimowo]

actually, @tenzen-y wdyt about instead of webhook validation just deactivate the workload in workload controller? it would be much less code and work for free for all integrations? it would be a form of 'soft' validation as we plan for CQs.

/hold to clarify on the approach, I can prototype it in a separate pr next week

[tenzen-y]

actually, @tenzen-y wdyt about instead of webhook validation just deactivate the workload in workload controller? it would be much less code and work for free for all integrations? it would be a form of 'soft' validation as we plan for CQs.

/hold to clarify on the approach, I can prototype it in a separate pr next week

I believe that the validation approach is better than deactivation since, in the case of deactivation, they need to seek the reason why their Job was not admitted. They do not have knowledge of the TAS limitations that can not be specified in both fields (preferred and required) at the same time. So I guess that they often fall in rabbit hole.

[mimowo]

Yeah, I agree it is better from user's perspective to fail fast. I was just thinking it might be less code to validate at the workload level. If you think it is more important pros the user experience then I consider the PR ready to review and merge

[tenzen-y]

Yeah, I agree it is better from user's perspective to fail fast. I was just thinking it might be less code to validate at the workload level. If you think it is more important pros the user experience then I consider the PR ready to review and merge

Yeah, your POV also has a point, but I believe that the UX is more important. So, let me merge this PR.

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: bdb8fa29c32107425363c45675c395c9fcc4a156

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mimowo, tenzen-y

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:

• ~~pkg/controller/OWNERS~~ [mimowo,tenzen-y]

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

[mimowo]

/hold cancel