crossplane-contrib / crossplane-contrib/function-go-templating
ExtraResources works as expected only in local environment
- Dominant language
- Go
- Stars
- 100
- Forks
- 65
- Avg merge
- 2d 6h
- Merged PRs (30d)
- 9
Description
Hi guys!
### What happened?
I encountered a problem where the `ExtraResources` and `getExtraResources` function only work in a local environment when executing the `crosplain render` command.
The same composite does not work in a real Kubernetes cluster.
### How can we reproduce it?
SandBox:
definition.yaml
```yaml
apiVersion: apiextensions.crossplane.io/v2
kind: CompositeResourceDefinition
metadata:
name: democlaims.example.io
spec:
scope: Namespaced
group: example.io
names:
kind: DemoClaim
plural: democlaims
singular: democlaim
versions:
- name: v1alpha1
served: true
referenceable: true
schema:
openAPIV3Schema:
type: object
properties:
status:
type: object
properties:
debug:
type: string
nullable: true
```
composition.yaml
```yaml
apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
name: democlaim
spec:
compositeTypeRef:
apiVersion: example.io/v1alpha1
kind: DemoClaim
mode: Pipeline
pipeline:
- step: extra-resources
functionRef:
name: crossplane-contrib-function-go-templating
input:
apiVersion: gotemplating.fn.crossplane.io/v1beta1
kind: GoTemplate
source: Inline
inline:
template: |
apiVersion: meta.gotemplating.fn.crossplane.io/v1alpha1
kind: ExtraResources
requirements:
config:
apiVersion: v1
kind: ConfigMap
matchName: dummy-config
---
{{ $debug := index . "extraResources" }}
apiVersion: example.io/v1alpha1
kind: DemoClaim
status:
debug: |
{{ $debug | toJson }}
- step: automatically-detect-ready-composed-resources
functionRef:
name: crossplane-contrib-function-auto-ready
```
extraresources.yaml
```yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: dummy-config
data:
debug: "dummy"
```
functions.yaml
```yaml
apiVersion: pkg.crossplane.io/v1beta1
kind: Function
metadata:
name: crossplane-contrib-function-go-templating
spec:
package: xpkg.crossplane.io/crossplane-contrib/function-go-templating:v0.11.3
---
apiVersion: pkg.crossplane.io/v1beta1
kind: Function
metadata:
name: crossplane-contrib-function-auto-ready
spec:
package: xpkg.crossplane.io/crossplane-contrib/function-auto-ready:v0.5.2
```
xr.yaml
```yaml
apiVersion: example.io/v1alpha1
kind: DemoClaim
metadata:
name: dummy-claim
namespace: default
spec: {}
```
on local machine I can see entire required object
```bash
$ crossplane render xr.yaml composition.yaml functions.yaml -e extraresources.yaml
---
apiVersion: example.io/v1alpha1
kind: DemoClaim
metadata:
name: dummy-claim
namespace: default
status:
conditions:
- lastTransitionTime: "2024-01-01T00:00:00Z"
reason: Available
status: "True"
type: Ready
debug: "{\"config\":{\"items\":[{\"resource\":{\"apiVersion\":\"v1\",\"data\":{\"debug\":\"dummy\"},\"kind\":\"ConfigMap\",\"metadata\":{\"name\":\"dummy-config\"}}}]}}
\ \n"
```
But in a real Kubernetes cluster:
```yaml
apiVersion: example.io/v1alpha1
kind: DemoClaim
metadata:
...
status:
conditions:
...
debug: |
{"config":{}}
```
### What environment did it happen in?
Crossplain
```
chart: crossplane
repoURL: "https://charts.crossplane.io/stable"
targetRevision: 2.1.1
```
Function
```
apiVersion: pkg.crossplane.io/v1beta1
kind: Function
metadata:
name: crossplane-contrib-function-go-templating
spec:
package: xpkg.crossplane.io/crossplane-contrib/function-go-templating:v0.11.3
```
Kubernetes
```
Client Version: v1.35.0
Kustomize Version: v5.7.1
Server Version: v1.33.4
```
```
$ k get xrd
NAME ESTABLISHED OFFERED AGE
democlaims.example.io True 30m
$ k get composition
NAME XR-KIND XR-APIVERSION AGE
democlaim DemoClaim example.io/v1alpha1 29m
$ k get DemoClaim dummy-claim
NAME SYNCED READY COMPOSITION AGE
dummy-claim True True democlaim 28m
```
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with the provided definition.yaml, composition.yaml, extraresources.yaml, functions.yaml, and xr.yaml, then reproduce the difference between `crossplane render ... -e extraresources.yaml` and the Kubernetes cluster using the listed versions. Trace how the ExtraResources requirement is handled in the cluster and verify done when the ConfigMap appears in the rendered XR status there as it does locally.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, kubernetes
- Domain
- infrastructure
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100