is there any interest in platform-level override f...
# feature-discussions
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: @Dan Rammer (hamersaw): it seems likely that the pod template is respected here. does that sound right?
👍 3
@Greg Gydush fyi
Hey @jeev! Yeah the default PodTemplate work should cover this. The dream is to some day deprecate all of the
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.
Are you guys using default PodTemplates yet?
I should note that they're a little more powerful than the k8s plugin config in that you can set them up by namespace as well.
not yet, but i can't express how excited we are about default pod templates 🙂
❤️ 2
But wait, now we have defaults per project / domain etc. cc @katrina
@Ketan (kumare3) 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:
Copy code
  // ...
  k8sServiceAccount: foo
(3) using matchable attributes users can set per project / domain or workflow specific attributes using flytectl