RuntimeClass handlers ignore TrainingRuntime namespaces when queuing TrainJobs

[DevaanshPathak]

What happened?

The RuntimeClass event handlers in the coscheduling and Volcano plugins resolve namespaced TrainingRuntime objects by RuntimeClass, but then list matching TrainJobs by runtime name across all namespaces.

Because TrainingRuntime is namespaced, two namespaces can legitimately contain runtimes with the same name but different RuntimeClass settings. A RuntimeClass event for one runtime can therefore enqueue unrelated TrainJobs from another namespace.

The handlers also deduplicate collected TrainJobs using only TrainJob.Name. When same-named TrainJobs exist across namespaces, the handler can retain the request from the wrong namespace and omit the TrainJob whose runtime actually uses the changed RuntimeClass.

I reproduced this on current master (c71b4757): with ns-a/runtime using class-a, ns-b/runtime using class-b, and a suspended TrainJob named job in each namespace, an event for class-b queued ns-a/job instead of ns-b/job.

queued namespace = ns-a, want ns-b

The same lookup and deduplication pattern exists in:

• pkg/runtime/framework/plugins/coscheduling/coscheduling.go
• pkg/runtime/framework/plugins/volcano/volcano.go

What did you expect to happen?

RuntimeClass events should enqueue only suspended TrainJobs whose referenced namespaced TrainingRuntime uses that RuntimeClass. Identity and deduplication should use both namespace and name.

Proposed fix

• Scope the TrainJob list for each TrainingRuntime with client.InNamespace(trainingRuntime.Namespace).
• Deduplicate requests by namespace and name.
• Add regression tests for the coscheduling and Volcano RuntimeClass handlers using same-named runtimes and TrainJobs in different namespaces.

Environment

Kubeflow Trainer: current master at c71b4757

Contribution

I would like to implement this fix with regression tests.

AI assistance: Codex assisted with technical drafting; I locally reproduced and verified the behavior.

[DevaanshPathak]

/assign @DevaanshPathak