Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Using a Condition to test if dependencies are met

Ouverte
  • Quelque chose ne va pas ?
#3,643 3 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
62/100
Type d'issue
Fonctionnalité
Clarté
Clairement spécifiée
Activité
Active
Stack technique
java, kubernetes
Domaine
backend

Piste de recherche

Start from the @Dependent annotation and the code that interprets dependsOn and reconcilePrecondition (io.javaoperatorsdk.operator.processing.dependent.* and the Condition interface) to see where deletion on a false precondition is triggered. Design where the new dependenciesMetPrecondition option would be evaluated in the reconcile cycle so it gates work without deleting an existing secondary resource, and decide how it interacts with dependsOn. Done looks like: the new option is honored during ongoing reconcile cycles, existing precondition deletion behavior is unchanged, and unit/integration tests around dependent resources pass.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

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

Langage dominant
Java
Étoiles
942
Forks
246
Merge moyen
1 j 11 h
PR mergées (30 j)
28

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de operator-framework/java-operator-sdk

Toutes les issues de operator-framework/java-operator-sdk

Issues similaires

Plus d'issues Java

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.