[kueuectl] Support filter by custom job type on the list pods command.

[mbobrovskyi]

What would you like to be added:

Why is this needed: We need to allow to support filtering pods by custom job type on the list pods command as discussed on https://github.com/kubernetes-sigs/kueue/pull/2280#discussion_r1654280733.

Completion requirements:

This enhancement requires the following artifacts:

• [ ] Design doc
• [ ] API change
• [x] Docs update

The artifacts should be linked in subsequent comments.

[rainfd]

/assign

[mbobrovskyi]

@rainfd Do you want to take it?

[rainfd]

@mbobrovskyi The user case is that user have crd job type and use kueue to summit it, and you want to support to list their pod? I'm a little confused. Because the code metioned in the discussed https://github.com/kubernetes-sigs/kueue/pull/2280#discussion_r1654280733 don't block the case.

[alculquicondor]

There is already support for arbitrary label selectors, but you can do the same using kubectl get. So, we wouldn't be adding much value.

Maybe something we can do is to do a client-side filtering using the owner references? But not all custom jobs own the pods directly, so it's not generally useful.

Thoughts?

[rainfd]

There is already support for arbitrary label selectors, but you can do the same using kubectl get. So, we wouldn't be adding much value.

Maybe something we can do is to do a client-side filtering using the owner references? But not all custom jobs own the pods directly, so it's not generally useful.

Thoughts?

User's CRD -> Operator -> Workload supported by kueue.

To support kueue, the custom operator should create a workload which is supported in kueue, like pod/job/jobset/...

If the workload is pod, we can filter using the owner references, but the user should provide the full crd name like batch.kubernetes.io/job-name=xx because we don't the relationship between job/xx and batch.kubernetes.io/job-name=xx.

Another simpler way to find the pod is using the label selectors directly, because the pod must have a queue name in order to be managed by kueue.

If the workload is not a pod, we should look through all the workload supported by kueue to find the original reference workload , and then find the pods through that workload. But is there such a user case?

[mbobrovskyi]

For built-in integration, users can build the kueuectl binary and use it. It should work if JobWithPodLabelSelector interface is implemented. However, for external integration, I’m honestly not sure.

[mbobrovskyi]

I can see only one way to add some flag like --selector and use it instead of JobWithPodLabelSelector interface.

[mbobrovskyi]

Looks like, we already have --selector flag for kueuectl list pod command.

https://github.com/kubernetes-sigs/kueue/blob/425ece197331d6b0c9b6d2bf4cc82326420c9f0a/cmd/kueuectl/app/list/list_pods.go#L72

Currently, the --for flag is required, and we can’t use the command without it. It might make sense to relax the validation and allow filtering Pods with the --selector flag, enabling users to filter custom jobs.

@alculquicondor WDYT?

[alculquicondor]

but then it's just the same as kubectl get pods. Not very useful IMO.