is there any interest in platform-level override for default service account to use for k8s pods? right now if there is no k8s service account explicitly set in the launch plan spec, it uses ‘default’. likely constitutes a simple change here: https://github.com/flyteorg/flyteplugins/blob/d2f64cb8c49adccadb01f46960031df3219dce32/go/tasks/pluginmachinery/flytek8s/pod_helper.go#L72 @hallowed-mouse-14616: it seems likely that the pod template is respected here. does that sound right?

Hey @freezing-boots-56761! Yeah the default PodTemplate work should cover this. The dream is to some day deprecate all of the

Default*

configuration fields in the K8sPluginConfig. Up until now everything has been added on a one-off basis, but moving forward they can be configured using a PodTemplate as you mentioned.

not yet, but i can't express how excited we are about default pod templates 🙂

But wait, now we have defaults per project / domain etc. cc @acceptable-policeman-57188

@freezing-airport-6809 are these managed in admin and propagated through to the propeller execution config?

in general per-project level attributes are managed in admin and can be used when creating the flyte workflow crd

For completeness I will update here. After some searching / discussion it turns out there may be a few ways we can do this: (1) using the default PodTemplate as mentioned above (2) flyteadmin has a default configuration option, which is where the "default" value you see comes from. Example configuration:

flyteadmin:
  // ...
  k8sServiceAccount: foo

(3) using matchable attributes users can set per project / domain or workflow specific attributes using flytectl