Support providing Go templates as OCI images

[ezgidemirel]

What problem are you facing?

Currently, the function can get template inputs as inline or from a file system directory. As a next step, we can support getting them from OCI images. In this way, users may easily decide which version of the templates to use in their composition.

How could this Function help solve your problem?

Following API is suggested by @turkenh in the comment:

      input:
        apiVersion: gotemplating.fn.crossplane.io/v1beta1
        kind: GoTemplate
        source: Image
        image:
          repo: turkenh/my-templates
          tag: v0.1.0

In this case, templates are expected in a fixed path like /templates.

[negz]

Is there a benefit to having templates in a separate OCI image from the function, as opposed to baking templates into the function? i.e. By adding templates in a new layer and using the filesystem source?

[ezgidemirel]

The main advantage that comes to my mind is separating template life-cycle from the function's. With the suggested way, we can update used templates without building/updating a new function. Also, we may have multiple compositions that use function-go-templating and each one of them may refer a different template image.

[phclark]

I second this use case. Ideally, the function simply transforms the data (templates + input from the composite resource). The templates should be tested and published with a separate lifecycle.

[danielloader]

I've moved to this model with other services in my EKS clusters, namely things like Keycloak templates - using https://oras.land/ to bundle things up much like OP suggested, into convention driven known paths e.g. /templates and just using them as a versioned tarball stored on ECR.

I don't think it's going to be make or break for me, as suggested in the reply I could bundle them into the function images - the issue I think would come down to private registries.

While there's a library that's fairly easy to embed in the function code for interacting with OCI, you'd still need to login and pass something in akin to an imagePullSecret to do this login. Additionally I wonder since I've not tried, whether anything additional would need to be configured on EKS for example to pull from ECR registries when it's a tool like ORAS being used rather than containerd using the node roles.

The other option which is out of scope for the issue but one to think about is supporting S3-alike object stores or configMaps for templates.

[negz]

Yeah, generally our experience with the package manager and alpha functions shows that there's a lot of edge cases to cover when you start pulling OCI images (e.g. credentials, proxies, etc). We'd need to reimplement a lot of that if we have the function itself pull OCI templates.

Coupling of function lifecycle with template lifecycle is a valid concern, but I think it could be addressed with the right UX/tooling. Conceptually this new function is less function-go-templates and more function-whatever-the-templates-do.

Imagine a CLI tool that takes as input a version of function-go-templating and a directory of templates, and outputs a new function OCI image with those templates built in.

fn-go-templates add crossplane-contrib/function-go-templating:v0.3.0 /my-templates myorg/function-my-templates:v0.1.0

I think all this CLI tool would need to do would be to use the function image an OCI base layer and add a new layer with the templates.