Provide more complex examples in template for accessing XR data

[davejhahn]

What problem are you facing?

When working with data provided in the XR, from my perspective, it is going to be more complicated than simple strings or an array of strings. Those are the two examples included in the template.

What I am struggling with, and I'll admit part of the struggle is that I am just not very familiar with Go, Python was my first choice, but I couldn't get it to build, and after seeing the provider type integration with Go I changed my mind.

An example:

containers:
  - name: test1
     containerAccessType: Private
  - name: test2
    containerAccessType: Private

I just want to be able to access for the example above, "spec.containers", get an array of something, and be able to iterate over a list and have access to the underlying data.

I spent a bit of time looking at the request returned from GetObservedCompositeResource, e.g. GetString, GetStringObject, GetList, GetValue, etc... and I didn't really find anything that was what the intended way of doing this was because as far as I can find it isn't documented and it isn't in the example template. So I went off several directions, ultimately didn't get to what I had hoped, so still kind of not sure of the best approach, but I have to assume I am missing something, it can't be that hard.

So, given the likelihood of just a simple string array or string value not being something that will scale to anything useful, a decent example of more complex data I think would be extremely valuable.

The ask is for either a V2 template or an improved one with more robust capabilities. Also, if anyone has some pointers as to what approach I would use that aligns with the intended use for functions would be create (citing above example above).

Thanks!

How could this Function help solve your problem?

[davejhahn]

This is how I ended up accessing the structured list for the example above:

	containers := xr.Resource.Object["spec"].(map[string]interface{})["containers"].([]interface{})
	for _, container := range containers {
		name := container.(map[string]interface{})["name"].(string)
		containerAccessType := container.(map[string]interface{})["containerAccessType"].(string)
	}

Whether the above is considered the appropriate way to do this, I have no idea--that's where some examples would be great, before I start creating some horrible Go functions. I'm guessing that for anyone already familiar with Go, this is probably not a big deal. If anyone has thoughts on the above, whether this is good or bad, would appreciate comments!

It seems that Go is really the preferred language for working with crossplane functions, with the integrated types and the local debugging (which I think is an absolute) along with almost all of the examples and work being done with it, so I may not be the only one that needs to shift to the unfamiliar.

[lukegAtPaxos]

Adding to this, it would be beneficial to be able to marshall the entire spec to a struct, much like how its done with the function input.

Controlling end to end the XR CompositioinResourceDefinition, with a type structure would be a lot easier to, currently im hand crafting my CompositeResourceDefinition.

[vibe]

Adding to this, it would be beneficial to be able to marshall the entire spec to a struct, much like how its done with the function input.

Controlling end to end the XR CompositioinResourceDefinition, with a type structure would be a lot easier to, currently im hand crafting my CompositeResourceDefinition.

Currently this is what we do, I have an end to end generation of struct -> generated crd -> parse resource into struct