Support requesting extra resources

[jan-di]

What problem are you facing?

We manage infrastructure with crossplane. Our compositions refer to some observe only resources (via the new beta style management policies). As of today, we need to create observe-only resources for each composition. Those resources could be global networks, flavors/hardware templates, or other resources that are commonly provided by the cloud provider.

How could this Function help solve your problem?

With the new feature of requesting extra resources in Crossplane 1.15, go template could fetch those extra resources and provide them as variables in the go template via the RunFunction request. This would have the following benefits:

• Less observed resources needed (1 per XRD/Composition, instead of 1 per XR) -> therefore, there is less load on the provider
• Faster composition creations. We do not need to wait until the observe resources are ready.

[phisco]

Thanks for opening this! I wanted to do the same for a while!

My thinking was that this could be implemented via an additional resource similar to what we do for the CompositeConnectionDetails, e.g.:

apiVersion: meta.gotemplating.fn.crossplane.io/v1alpha1
kind: ExtraResources
resource-1:
  ...selector...
resource-2:
  ...selector...

The other option would be to have it in the input and not as part of the template, but that would be much less powerful as one could not request extra resources based on the resources available, either observed or desired from previous steps in the pipeline

[Menni27]

@phisco this ExtraResources idea looks great and helps customising compositions using go-templating-function with details from other existing resources. Do we have any timelines for the release of this feature

[phisco]

Just need some more testing on https://github.com/crossplane-contrib/function-go-templating/pull/83. In the meantime you can check function-extra-resources, it should cover most of your needs!

[Menni27]

this is more suitable for my use case where i want to take list of labels as input and use them to get resources , where as in function-extra-resource i should know the keys for all labels before hand and values can be taken from composite (or i need to get all the resources of a type and filter later in go-templating) and also this will avoid using one additional function as well in the composition waiting for this feature to be released

[gtfortytwo]

This would support several use cases for us, too. We've used function-extra-resource, but we have cases where we need a selector that is based on multiple values from the composition, and FER only supports type: FromCompositeFieldPath (no combines or the like). The approach discussed here would provide the most flexible means to construct a resource selector from any of the data available to the function. I'd considered proposing writing desired resource selectors to the Context, but just emitting ExtraResources objects from the template is a much better API (kudos @phisco). Looking forward to seeing this make it in.