What would you like to be added:
The MPIJob customization (pkg/resourceinterpreter/default/thirdparty/resourcecustomizations/kubeflow.org/v2beta1/MPIJob) defines componentResource, statusAggregation, statusReflection and healthInterpretation, but no dependencyInterpretation. Its siblings TFJob and PyTorchJob both have one that walks the replica specs and collects pod dependencies with kube.getPodDependencies.
So when an MPIJob is propagated by Karmada, ConfigMaps, Secrets or ServiceAccounts referenced from its pod templates are not picked up as dependencies and do not follow the job to the member cluster.
Why is this needed:
Same reason TFJob and PyTorchJob have it. MPI jobs commonly mount ConfigMaps and use a ServiceAccount, and without this the user has to propagate those by hand.
I can add it, mirroring the TFJob script over spec.mpiReplicaSpecs (Launcher and Worker), with testdata like the existing kinds.
/assign
What would you like to be added:
The MPIJob customization (pkg/resourceinterpreter/default/thirdparty/resourcecustomizations/kubeflow.org/v2beta1/MPIJob) defines componentResource, statusAggregation, statusReflection and healthInterpretation, but no dependencyInterpretation. Its siblings TFJob and PyTorchJob both have one that walks the replica specs and collects pod dependencies with kube.getPodDependencies.
So when an MPIJob is propagated by Karmada, ConfigMaps, Secrets or ServiceAccounts referenced from its pod templates are not picked up as dependencies and do not follow the job to the member cluster.
Why is this needed:
Same reason TFJob and PyTorchJob have it. MPI jobs commonly mount ConfigMaps and use a ServiceAccount, and without this the user has to propagate those by hand.
I can add it, mirroring the TFJob script over spec.mpiReplicaSpecs (Launcher and Worker), with testdata like the existing kinds.
/assign