Do you expect that we extend the on-demand visibility server or save information on any CustomResource like ClusterQueue?

I don't think we should save it. This is more for on-demand queries.

I don't think we should save it. This is more for on-demand queries.

It makes sense.

Tangentially, do you think adding a running_worloads metric could be useful too?

Tangentially, do you think adding a running_worloads metric could be useful too?

Does it mean Prometheus metric?

Tangentially, do you think adding a running_worloads metric could be useful too?

Does it mean Prometheus metric?

Yes, a Prometheus metric, that would complement the existing pending_workloads metric.

we already have it

we already have it

kueue/pkg/metrics/metrics.go

Lines 120 to 126 in 9afd7e6

	AdmittedActiveWorkloads = prometheus.NewGaugeVec(
	prometheus.GaugeOpts{
	Subsystem: constants.KueueName,
	Name: "admitted_active_workloads",
	Help: "The number of admitted Workloads that are active (unsuspended and not finished), per 'cluster_queue'",
	}, []string{"cluster_queue"},
	)

Ah right, this is the one, thanks!

Would you like to propose something for this area? Maybe along the lines of a new visibility endpoint?

Yes. Do you want it to be initially proposed as a KEP?

Given that it's an API change, a KEP would be good.

Feel free to assign yourself with /assign.
Since you joined this org, the command should work well :)

If no one working for this, I can help.

@KunWuLuan I haven't got the chance to work on it. Feel free to assign it to you.

Do we still need the new endpoints if we already have the KueueCtl?

Maybe less so? One slight advantage would be to filter on the server side.

But maybe it would add unnecessary load to the kueue binary?