Option to specify a different KUBECONFIG where Analysis vs. Jobs would run about argo-rollouts

[jessesuen]

is it true that a controller could only ever connect to one different cluster or namespace for all jobs

That's correct, it would just be to run workloads in a one specific namespace in a cluster. If multiple namespaces or clusters were allowed, it would create a mapping problem and I wouldn't want to introduce that level of complexity.

[zachaller]

Would this JOB_KUBECONFIG be set at the controller level? I am wondering if say a multi cluster job plugin would make sense?

[jessesuen]

Yes, this would be a controller-level setting, and when set, it would simply change the kube client that would be used for the Job client/informer.

Unfortunately, using plugin isn't desirable, since the entire job/pod spec would have to be duplicated into a plugin stanza, creating unnecessary nesting, and not to mention the overhead of the plugin development itself. Since, Jobs are already a native type we already support, this request is just allowing an operator an added control on where the workload gets created.

Another use case is not necessarily multi-cluster. Another one that came up is that can be desired to create Jobs under a different namespace from the AnalysisRun (e.g. if that namespace has additional node/affinity/networking controls that would allow operators to further restrict where pods get created to improve security).

[zachaller]

Yea that's fair about plugin embedding the whole pod spec is a little "not fun" due to the loss of type information, that said with this as an ENV is it true that a controller could only ever connect to one different cluster or namespace for all jobs? Not saying there is not value in that just want to confirm.