kueuectl command to get job + workload

[alculquicondor]

What would you like to be added:

A single command that would output the status (and potentially events) of both workload and job objects.

Maybe it should look something like:

kubectl kueue describe <job type> <job name>

Ideally, this should work not just for CRDs supported by Kueue, but also external extensions. This should be possible using the discovery API and searching for a corresponding Workload object for it that has the matching UID label.

Why is this needed:

A common question users ask is "why is my job not running".

While most of this can be answered by looking at the Workload object, we don't want to force users to understand what the difference is between job and workload.

Furthermore, Kueue might have admitted the job and the job could be pending due to scale ups or failing scheduling (kube-scheduler) attempts.

Completion requirements:

This enhancement requires the following artifacts:

• Design doc
• API change
• Docs update

The artifacts should be linked in subsequent comments.

[alculquicondor]

cc @mwielgus

[trasc]

@alculquicondor could extending the filter/lookup capabilities of list workload be sufficient for this?

kueue/keps/2076-kueuectl/README.md

Lines 202 to 227 in 90689f6

	### List Workloads
	Lists Workloads that match the provided criteria. Format:
	```
	kueuectl list workloads
	--namespace=ns # uses context's default namespace if not specified
	--all-namespaces | -A
	--clusterqueue=cq
	-–localqueue=lq
	-—only-pending
	—-only-admitted
	--selector=selector
	```
	Output:
	* Namespace (if -A is used)
	* Workload name
	* CRD type (truncated to 10 chars)
	* CRD name
	* LocalQueue
	* ClusterQueue
	* Status
	* Position in Queue (if Pending)
	* Age

[alculquicondor]

It could help, something like:

kubectl list workloads --for job/my-job-name

But it could also help to have a dedicated command that shows you both the job and the workload.

[alculquicondor]

Let's start with just --for

/assign @trasc

[trasc]

/assign @IrvingMg

In my opinion the format for --for can be something like [<type>[.<api-group>]/]<name> so :

• --for=my-job includes all the workloads with a parent called my-job regardless of type and api-group
• --for=job/my-job includes all the workloads with a parent called my-job and type job regardless of its api-group
• --for=job.batch/my-job includes all the workloads with a parent called my-job and type job in api-group batch

The filtering is done on the client side so having the filter relaxed when it comes to owner type should not have any performance penalties.

[alculquicondor]

• --for=my-job includes all the workloads with a parent called my-job regardless of type and api-group
• --for=job/my-job includes all the workloads with a parent called my-job and type job regardless of its api-group

To avoid confusion if there happen to be 2 jobs with the same name, I hope we can include the full api name for the owning job in the list table.

The fact that multiple jobs matched will be less obvious if using -o=yaml, but I suppose users of this format are more savvy.