Support for XR Conditions

[avarei]

What problem are you facing?

Crossplane handles status conditions for Composite Resources differently to other fields.

they are a seperate part of the RunFunctionResponse and they are ignored if present on the desired.composite

https://github.com/crossplane/function-sdk-go/blob/5c539d73086161e82568d8126c45cc629b54ecdb/proto/v1/run_function.pb.go#L687-L688

How could this Function help solve your problem?

I am not sure if kro allows setting status conditions but from a crossplane point of view it would be nice if it were possible.

maybe they could be detected on the XR and converted into the format wanted by the RunFunctionResponse?

[jbw976]

Thanks for the idea here @avarei! This would be nice functionality to have in this function and I think your instinct about detection + conversion is a decent approach.

The KRO runtime already supports resolving CEL expressions in the instance (XR) status template via soft resolution. So conditions could be declared as regular status fields using the existing ${...} syntax:

apiVersion: kro.fn.crossplane.io/v1alpha1
kind: ResourceGraph
metadata:
  name: cool-network
status:
  networkId: ${vpc.status.atProvider.vpcId}
  conditions:
    - type: "SubnetsMultiAZ"
      status: ${size(subnets.items.map(s, s.status.atProvider.availabilityZone).unique()) > 1 ? "True" : "False"}
      reason: ${size(subnets.items.map(s, s.status.atProvider.availabilityZone).unique()) > 1 ? "MultiAZ" : "SingleAZ"}
      message: "Subnet availability zone distribution"
resources:
  - id: vpc
    template:
      # ...
  - id: subnets
    template:
      # ...

The runtime would resolve the CEL expressions in status.conditions just like it does for any other status field. Then in fn.go, after building the desired XR status, we'd detect those entries under .status.conditions and convert them to RunFunctionResponse.conditions via the function SDK's condition helpers, and exclude them from the desired composite (since Crossplane ignores conditions set there anyway, I think).

No changes to the vendored KRO runtime or the input API would be needed — just detection + conversion logic in fn.go. The soft resolution semantics already handle the case where a CEL dependency isn't available yet by skipping unresolvable fields, so conditions with pending dependencies would just be omitted until they can resolve (i think).

The ease of supporting this is in contrast with #30 (pipeline context support), which requires fundamentally new data flow — feeding external data into the KRO runtime's CEL environment, which the runtime has no concept of today. Conditions go the other direction: data flows out of the runtime through a path that already works, and we just need to route it to the right place in the Crossplane response.

Are you up for working on a PR with this functionality? I'd be happy to support you and provide quick review feedback if you want to give it a go! 💪

[jonasz-lasut]

@jbw976 I'll be happy to implement the support for setting conditions :)
One small nitpick to the example that you've provided - all status.conditions entries for ResourceGraph need to be proper KRO expressions and not static strings otherwise you'll encounter errors during building instance node

pipeline step "kro-run" returned a fatal result: cannot create resource graph: failed to build instance node: status fields without expressions are not supported: [conditions[0].message]

Workaround like this ${"Subnet availability zone distribution"} won't work as well because the other limitation is that fields have to contain a reference to a resource:

pipeline step "kro-run" returned a fatal result: cannot create resource graph: failed to build instance node: instance status field must refer to a resource: status.conditions[0].message

That leads to not so flexible requirement to always refer at least one resource in status.conditions[*].<field-name> and in my experience you end up with fields like this example: type: '${size(resource.status.atProvider.id) > 0 ? "SubnetsMultiAZ" : "SubnetsMultiAZ"}' just to satisfy the runtime requirement to refer a resource when you need a static string

[jbw976]

oh darn, that's definitely a limitation that makes this approach must less desirable. Looks like it was added in kubernetes-sigs/kro#1023. I'm not sure of the full reasoning, but I would have liked for static data to still be allowed in the status fields with my myopic perspective personally 🤔

i'd rather not support conditions still for the time being than have them supported only via wacky workarounds, unless anyone has a better idea to deal with this limitation? 😂

[jonasz-lasut]

Iirc it comes from the fact that conditions are a reserved field for KRO runtime. Kro overrides them if they're defined in the schema of the RGD - docs. I'm also not happy with how this limitation behaves in the context of data propagation, I can see valid usecases for static static fields, even outside of the conditions array.

I think to properly support conditions with CEL-based expressions we'd have to handle resolving them outside of the KRO runtime's CEL environment - fetch all the required data from the runtime after the graph is evaluated and evaluate the status.conditions on our own without the limitations set by the runtime but that's another big piece of work that is way more complex than just taking the ouput of KRO's runtime and doing a simple conversion from core conditions to function runtime conditions

[avarei]

Thank you both very much for looking at it!

I think we should revisit this once kro too supports setting custom status.conditions. I would imagine that when they do they would fix the limitations you experienced.