@KPostOffice Do you assume that automatically https://kueue.sigs.k8s.io/docs/tasks/manage/setup_job_admission_policy/ generation?

@KPostOffice Do you assume that automatically https://kueue.sigs.k8s.io/docs/tasks/manage/setup_job_admission_policy/ generation?

Are you referring to the example AdmissionPolicy outlined in the documentation?

https://kueue.sigs.k8s.io/docs/tasks/manage/setup_job_admission_policy/

Yes, I indicated the ValidatingAdmissionPolicy.

/assign

Yeah, the assumption here would be that the policy would be in place

If we are going to modify API to have "default" field, it might be tricky to validate that only one LQ is a default. Are we going to abandon setting LQ as default if another default LQ is present in the namespace (in this case we do not validate the object itself)? If we can have multiple default LQs, which one is an actual default? It could be a first one or the last one.

To avoid those questions and the API change, I suggest to default LocalQueue that has default name, WDYT?
However this might be a breaking change for someone.

@KPostOffice could you please tell if #2936 (comment) makes sense

Let's have the "default" default LocalQueue and put the whole feature behind a feature gate, so we don't break anyone by accident.

Using the default LQ name behind a feature gate would be a fine solution from my perspective

It feels this feature requires a KEP, even if there is no "API" changed, we still introduce a feature-gate. Also, I feel the mechanism will evolve in the future, so having some reference we can update will be useful. It does not need to be long, just one pager to collect the use-cases and the proposed solution.

It feels this feature requires a KEP, even if there is no "API" changed, we still introduce a feature-gate. Also, I feel the mechanism will evolve in the future, so having some reference we can update will be useful. It does not need to be long, just one pager to collect the use-cases and the proposed solution.

+1