Problem
The function runner currently hardcodes the base template names:
const (
basePodTemplateName = "base-pod-template"
baseServiceTemplateName = "base-service-template"
)
(podmanager.go, line 53)
Additionally, getBasePodTemplate() unconditionally creates the PodTemplate from an inline default if it doesn't find one in the cluster. There's no way to:
Configure the template names via flags or environment variables.
Disable the auto-creation behavior (e.g. when the template is managed externally by Helm or another tool).
This causes a race condition when deploying with Helm: if the function-runner pod starts before a custom PodTemplate is applied, it creates the inline default. Users then need Helm hook weights or init containers to work around an ordering problem that shouldn't exist.
Proposed Changes
Make template names configurable — expose --base-pod-template-name and --base-service-template-name flags (defaulting to current values for backwards compat).
Add a --skip-template-creation flag — when set, getBasePodTemplate() should return an error instead of auto-creating the template if it's not found. This makes the function-runner fail fast if the expected templates aren't deployed, rather than silently falling back to an inline default.
Consider a retry/wait approach — as an alternative or complement to (2), the function-runner could wait for the template to appear (with a timeout) rather than immediately creating or failing. This is more resilient in environments where deployment ordering isn't guaranteed.
Problem
The function runner currently hardcodes the base template names:
const (
basePodTemplateName = "base-pod-template"
baseServiceTemplateName = "base-service-template"
)
(podmanager.go, line 53)
Additionally, getBasePodTemplate() unconditionally creates the PodTemplate from an inline default if it doesn't find one in the cluster. There's no way to:
Configure the template names via flags or environment variables.
Disable the auto-creation behavior (e.g. when the template is managed externally by Helm or another tool).
This causes a race condition when deploying with Helm: if the function-runner pod starts before a custom PodTemplate is applied, it creates the inline default. Users then need Helm hook weights or init containers to work around an ordering problem that shouldn't exist.
Proposed Changes
Make template names configurable — expose --base-pod-template-name and --base-service-template-name flags (defaulting to current values for backwards compat).
Add a --skip-template-creation flag — when set, getBasePodTemplate() should return an error instead of auto-creating the template if it's not found. This makes the function-runner fail fast if the expected templates aren't deployed, rather than silently falling back to an inline default.
Consider a retry/wait approach — as an alternative or complement to (2), the function-runner could wait for the template to appear (with a timeout) rather than immediately creating or failing. This is more resilient in environments where deployment ordering isn't guaranteed.