Support Cross-Resource References Between Datadog SLO and Synthetic Test Resources

[af-ilya]

What problem are you facing?
I'm trying to define a ServiceLevelObjective Kubernetes object using the Datadog Upbound provider with apiVersion: datadog.upbound.io/v1alpha1 and kind: ServiceLevelObjective. This object includes a field monitorIds which is currently hardcoded.

The associated monitor is created using a separate object of apiVersion: synthetics.datadog.upbound.io/v1alpha1 and kind: Test. The problem is that it's currently not possible to create both resources together in an automated way. The workflow requires manually creating the Test, locating its monitor ID in the Datadog UI, and then updating the ServiceLevelObjective YAML with that ID before applying it.

This breaks infrastructure-as-code principles and makes automation difficult.

How could Upbound help solve your problem?
It would be helpful if the ServiceLevelObjective resource could reference the Test resource directly using a dependsOn or a ref-like mechanism. This would allow both resources to be created in a single pass without requiring manual intervention to fetch and inject IDs. Supporting references between these resources would greatly improve the developer experience and align with GitOps and declarative infrastructure practices.

[clarkritchie]

This would be nice. If you are using Helm, the lookup function can help, e.g.

{{- range .Values.slos }}
---
apiVersion: datadog.upbound.io/v1alpha1
kind: ServiceLevelObjective
metadata:
  annotations:
    meta.upbound.io/example-id: monitor/v1alpha1/monitor
  labels:
    name: {{ .custom_name | quote }}
  name: {{ printf "%s-%s" .custom_name .env | trunc 253 | quote }}
spec:
  forProvider:
...
    type: "monitor"
    monitorIds:
    {{- range .synthetics }}
    {{- $test := lookup "synthetics.datadog.upbound.io/v1alpha1" "Test" "datadog" (printf "%s-%s" .uuid .custom_name) -}}
    {{- if $test }}
      - {{ $test.status.atProvider.monitorId }}
    {{- end }}
    {{- end }}
  ...

☝ This appears to render correctly for me though I haven't actually used it yet. Make sure to use the --dry-run=server argument, e.g. helm template . -f stuff.yaml --dry-run=server.