Support Go templates with Sprig functions in TenantResource

[CorentinPtrl]

Describe the feature

Add support for Go templating (with Sprig) to GlobalTenantResource/TenantResource definitions. This enhancement would allow users to leverage Go templates and Sprig functions to generate more dynamic, context-aware manifests for example based on tenant metadata, annotations, labels.

What would the new user story look like?

1. A tenant owner creates or updates a Tenant.
2. The TenantResource controller renders the provided manifest template using Go templates + Sprig functions.
3. Context (tenant metadata, labels, etc.) is passed to the template engine.
4. The rendered resource is applied to the appropriate namespaces.

Example:

With Sprig, users could do things like:

metadata:
  name: "{{ .Tenant.metadata.name | lower | trunc 20 }}"

Expected behavior

• TenantResource manifests are processed using Go templates with Sprig functions available.
• Capsule passes structured context (Tenant, Namespace) to the template.
• Validation errors are surfaced clearly if templates fail to render.
• Backward compatibility

I’d be happy to work on implementing this feature if it's accepted

[prometherion]

I'm a bit worried about templating since it increase the chances of rendering issues, and when things don't work as expected the software is blamed.

IIRC we're already providing some templating for those resources, isn't it?

[CorentinPtrl]

There’s actually little to no real templating right now it’s just a simple string replace and doesn’t pass labels or annotations. It’s pretty limited and error-prone, only working for things like {{namespace}}, not proper Go template syntax
Ref:

capsule/controllers/resources/processor.go

Line 250 in e983c51

t := fasttemplate.New(template, "{{ ", " }}")

[prometherion]

I think we can accept this feature request: @Svarrogh1337 @oliverbaehler thoughts?

[oliverbaehler]

I would offload this to a dedicated API via Templates and TemplateInstances. I can already see new issues for this regarding loading additional context etc. Better to split it to a new api to make it reuseable.

[oliverbaehler]

Btw do you have the requirement to generate multiple manifests from one template (eg via iteration)?

[CorentinPtrl]

Yeah, I think it could function similarly to the GlobalTenantResource and TenantResource, but instead of rawItems, it would be templateItems

[CorentinPtrl]

Maybe it should also be implemented inside the Tenant kind

[oliverbaehler]

Definitly not in the Tenant