Skip to content

Using a Condition to test if dependencies are met #3643

Open

Description

@MikeEdgar

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

  1. csviri commented on Oct 9, 2026

    @csviri
    Collaborator

    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?

  2. MikeEdgar commented on Oct 9, 2026

    @MikeEdgar
    ContributorAuthor

    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?

    @csviri that seems reasonable. Something akin to DetailedCondition?

  3. MikeEdgar commented on Oct 12, 2026

    @MikeEdgar
    ContributorAuthor

    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?

  4. added this to the 5.7 milestone on Oct 22, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions