Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Using a Condition to test if dependencies are met

Aperta
  • Qualcosa non va?
#3,643 3 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
62/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
java, kubernetes
Ambito
backend

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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

Lingua principale
Java
Stelle
942
Fork
246
Merge medio
1g 11h
PR unite (30g)
28

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di operator-framework/java-operator-sdk

Tutte le issue di operator-framework/java-operator-sdk

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.