Proposal: Templating in the Style of a RunFunctionResponse

[avarei]

What problem are you facing?

When using this function I've been wondering for quite some time now how it would be if we were just writing RunFunctionResponses.
This seems to me like an intuitive pattern, since the Structure must already be learned to effectively use the Variables in the templates.

How could this Function help solve your problem?

I propose to add a new Field to the Inputs that allows toggling the expected format to the users preference.

I've created a small PoC where this composition works and I'm curious to hear your thoughts on this.

Here's an example of how such a composition would look like.

apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  name: example-runfunctionresponse
spec:
  compositeTypeRef:
    apiVersion: example.crossplane.io/v1beta1
    kind: XR
  mode: Pipeline
  pipeline:
    - step: render-templates
      functionRef:
        name: function-go-templating
      input:
        apiVersion: gotemplating.fn.crossplane.io/v1beta1
        kind: GoTemplate
        source: Inline
        style: RunFunctionResponse
        inline:
          template: |
            conditions:
              - type: Progressing
                status: STATUS_CONDITION_TRUE
                reason: Testing
                message: Hello World
                target: TARGET_COMPOSITE
            results:
              - severity: SEVERITY_NORMAL
                reason: norway
                message: foo
                target: TARGET_COMPOSITE_AND_CLAIM
            requirements:
              resources:
                ns:
                  apiVersion: v1
                  kind: Namespace
                  matchName: foo
            desired:
              resources:
                sa:
                  resource:
                    apiVersion: v1
                    kind: ServiceAccount
                    metadata:
                      name: {{ .observed.composite.resource.metadata.name }}
                  ready: READY_TRUE
                {{- with .observed.resources.sa.resource }}
                cm:
                  resource:
                    apiVersion: v1
                    kind: ConfigMap
                    metadata:
                      name: foo
                    data:
                      serviceAccountName: {{ .metadata.name }}
                  ready: READY_FALSE
                {{- end }}

[twobiers]

That's an interesting proposal and I have to say that I quite like it. We heavily use this function internally, and I've already spent a lot of time explaining the behavior of this function and how it maps to crossplanes function schema. This would make the behavior of the function way more explicit and transparent. Also, new features like requirements/namespace scoping would have required less effort in this style.

[avarei]

Awesome! I'm excited!

before moving forwards I am wondering if I should attempt to simplify the expected values of the ENUMs that emerged by using protojson.Unmarshal.

I was playing around with adding custom Unmarshal functions for the go sdk that would allow

conditions:
  - type: Progressing
    status: "True" # or for compatability STATUS_CONDITION_TRUE
    reason: Testing
    message: Hello World
    target: Composite # or for compatability TARGET_COMPOSITE

but protojson does not provide an UnmarshalJSON interface (so we'd need to switch to k8s.io/apimachinery/pkg/util/yaml and i don't know if the maintainers of function-sdk-go are open for the special unmarshaling functions to be placed there.

alternatively I could try to solve the problem in this repository by parsing the intermediate json and looking up for example condition status fields and replace "True" with the "STATUS_CONDITION_TRUE" that is expected by protojson to achieve the same effect.

What do you think?