-
Notifications
You must be signed in to change notification settings - Fork 306
Description
Feature Description
Problem Statement:
As discussed in #908, the CEL has() macro cannot be used to check for the existence of top-level resource IDs in status field expressions because it only accepts field selections, not identifiers CEL source.
This limitation makes it difficult to conditionally reference status fields from mutually exclusive resources defined in a ResourceGraphDefinition.
Proposed Solution:
Add a custom exist() function (or macro) to kro's CEL environment that can check for the existence of resource IDs. This would enable conditional status field expressions like:
status:
clusterStatus:
infrastructureReady: '${exist(local) ? local.status.infrastructureReady : remote.status.infrastructureReady}'Alternative Approaches:
-
Expose a
resourcesmap: Make all resources available through a map structure that can be checked using the standardhas()macro:infrastructureReady: '${has(resources.local) ? resources.local.status.infrastructureReady : resources.remote.status.infrastructureReady}'
-
Use string parameter for
exist(): Accept resource ID as a string:infrastructureReady: '${exist("local") ? local.status.infrastructureReady : remote.status.infrastructureReady}'
Use Case:
When working with mutually exclusive resources (controlled by includeWhen conditions), being able to conditionally reference their status fields would provide a clean, consistent status interface for custom resources, regardless of which variant was created at runtime.
Implementation Considerations:
- How would this interact with the dependency graph?
- Should resource existence be checked at evaluation time or compile time?
- What should the behavior be if a resource is referenced but doesn't exist (due to
includeWhenconditions)?
Current Workaround:
Currently, the recommended workaround is to replicate the includeWhen logic in status expressions:
status:
clusterStatus:
infrastructureReady: '${!(has(schema.spec.baseCluster) && has(schema.spec.baseCluster.kubeconfigRef)) ? local.status.infrastructureReady : remote.status.infrastructureReady}'While this works, it requires duplicating conditional logic and is less intuitive than directly checking resource existence.
Additional Context:
This feature would significantly improve the ergonomics of working with conditional resources in ResourceGraphDefinitions and make status field expressions more maintainable.
- Please vote on this issue by adding a 👍 reaction to the original issue
- If you are interested in working on this feature, please leave a comment