Repository navigation
Using a Condition to test if dependencies are met #3643
Description
Is your feature request related to a problem? Please describe.
Currently, we can describe a resource's dependencies using their names in dependsOn and we can also test preconditions with a reconcilePrecondition. However, sometimes a resource may need to depend one "at least one of" some other resource. For example, either an Ingress or a Route depending on the underlying cluster. In this case, dependsOn is not possible and a reconcilePrecondition returning false would delete the resource, which is undesirable for ongoing reconcile cycles.
There could also be cases where, for example, downstream dependents need a generated Route's hostname, but do not depend on the route actually becoming ready for further processing of the workflow, etc. Using a Condition could allow dependencies on sub-resources and not only on a resource's full readiness.
Describe the solution you'd like
An additional option on @Dependent (such as dependenciesMetPrecondition) that would allow programmatic checking on dependencies without removal of an existing secondary resource if it exists. This could be either mutually exclusive with, or in addition to whatever is given in dependsOn. Allowing both would provide a way to test simple dependencies and more complex ones at the same time.
Describe alternatives you've considered
I think more complicated workflows with "virtual" resources (always returning ReconcileResult.noOperation(primary) from reconcile) together with a readyPostcondition could be made to behave similarly, but with the burden of additional code and dependencies in the @Workflow.
Additional context
N/A
Activity
csviri commentedon Oct 9, 2026
Hi @MikeEdgar ,
Thank you we will take a look on this more in depth. Yes the reconcile pre-condition deletes the resource always is probably not something that always fits. Maybe we could extend the result to describe the intention to delete the resource or just keep it as it is for now. With this we would be a more powerful approach n our hand. What do you think?
MikeEdgar commentedon Oct 9, 2026
@csviri that seems reasonable. Something akin to
DetailedCondition?MikeEdgar commentedon Oct 12, 2026
Something that would complement using reconcile pre-conditions in this way would be some kind of "soft" dependency. The purpose would be to ensure the pre-condition is checked only after the dependency has been processed in the reconcile cycle, but it may not necessarily be ready.
Maybe something like
String[] reconcileAfter() default {};on@Dependent?csviri commentedon Oct 30, 2026
Not sure if following. So resource B depends on A, but B is reconciled after A even if precondition for A does not hold?
csviri commentedon Oct 30, 2026
see also design for
afterrelation: #1774MikeEdgar commentedon Nov 6, 2026
Correct. In other words, B "depends on" A when A is present and so must reconcile after A. However, B can tolerate the absence of A.
For example, A TLS secret may or may not be created based on the presence of the key material in the primary custom resource. If the TLS
Secretis to be created, theDeploymentneeds to wait for the secret. Otherwise, the Deployment can reconcile immediately.I think the
afterconcept in the linked issue may be the same. What do you think?csviri commentedon Nov 9, 2026
Yes, to have this completely generic I think we need both
afterandprecondition, no delete(PND) .The question is, how should the depends on relationship work with PND, thus if such prencondition if false for resource A, there is a resource B that depends on it, should it be reconiled? Intuitively I would say no, if user want it to be reconiled still can use
after. What do you think?Also would you be interested to implement this? 😃