Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support requesting extra resources #77

Open
jan-di opened this issue Mar 15, 2024 · 5 comments · May be fixed by #83
Open

Support requesting extra resources #77

jan-di opened this issue Mar 15, 2024 · 5 comments · May be fixed by #83
Labels
enhancement New feature or request

Comments

@jan-di
Copy link
Contributor

jan-di commented Mar 15, 2024

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.
@jan-di jan-di added the enhancement New feature or request label Mar 15, 2024
@phisco
Copy link
Collaborator

phisco commented Mar 16, 2024

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
Copy link

Menni27 commented Apr 17, 2024

@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
Copy link
Collaborator

phisco commented Apr 17, 2024

Just need some more testing on #83.
In the meantime you can check function-extra-resources, it should cover most of your needs!

@Menni27
Copy link

Menni27 commented Apr 18, 2024

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants