Example KCL to pass resource data between created cloud resources

[markphillips100]

I'm writing KCL code to create Azure resources using the KCL crossplane function as part of a composition. I need to supply some of one resource's "atProvider" data to another resource's "forProvider" data.

In the past this would be achieved by using a patch with the patch and transform function but I would prefer to keep this encapsulated within the KCL code if possible.

Should I use the option("params").ocds some how to access the named resource and obtain its atProvider data? If so, can you provide an example of accessing a a resource this way. Please also let me know if this is not the preferred way of doing this.

[Peefy]

Do you mean this?

apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  name: function-template-go
spec:
  compositeTypeRef:
    apiVersion: example.crossplane.io/v1
    kind: XR
  mode: Pipeline
  pipeline:
  - step: normal1
    functionRef:
      name: kcl-function
    input:
      apiVersion: krm.kcl.dev/v1alpha1
      kind: KCLRun
      metadata:
        name: basic
      spec:
        target: Resources
        source: |
          {
              metadata.name = "resource1"
              spec.forProvider.network: "somenetwork"
          }
  - step: normal2
    functionRef:
      name: kcl-function
    input:
      apiVersion: krm.kcl.dev/v1alpha1
      kind: KCLRun
      metadata:
        name: basic
      spec:
        target: Resources
        source: |
          {
              metadata.name = "resource2"
              spec.atProvider = option("params").dcds["resource1"].Resource.spec.forProvider
          }

[markphillips100]

Thanks @Peefy . Other way around, i.e. atProvider holds the data created by the remote provider (Azure in my case), and forProvider has data properties I need to set.

Is dcds the correct collection to use for resources that have are "ready" as in synced with crossplane and also created at the provider?

[Peefy]

I think dcds it is a suitable field for any synchronized resources. Or the function-auto-ready function is your need in the document https://github.com/crossplane-contrib/function-go-templating

[markphillips100]

Thanks @Peefy. I think I'll be fine by just copying the data with dcds rather than waiting for ready. reconcile loops should eventually resolve the data.

[markphillips100]

@Peefy FYI I need to use ocds as the crossplane atProvider data hangs off the status property rather than spec, and only observable resources carry this status object. I'm also composing both resources in the same step as one KCL package.

Problem I have at the moment is the names of the resources in the ocds dictionary. They get prepended with whatever name is specified in the pipeline step's input metadata. In my case, my step is called "normal" and there's a metadata name of "basic". This results in "basic-" being prepended to every resource name. Thing is, from my KCL code perspective it only knows of the names I give. I wouldn't want the KCL code to make assumptions either by prepending names with "basic-" when looking up the ocds dictionary.

Is this expected behaviour of the kcl function to prepend resource names, and is there a way to disable it entirely so only the names I give are used? I tried just removing the name: basic from the metadata entirely and this results in the ocds dictionary having each of my resource names prepended with a "-" character.

[Peefy]

Make sense. Did you mean this fields? I think there is an opportunity to improve it

[markphillips100]

Yes exactly. The ocds keys use that annotation value rather than the metadata name (which is the only name I know within the kcl code).

[markphillips100]

I'm assuming the dcds dictionary does the same too I would imagine.

[Peefy]

I've opened a PR to remove the component resource prefix from the name field of KCLRun. https://github.com/crossplane-contrib/function-kcl/pull/57

[Peefy]

Closed by #57