Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

Using a Condition to test if dependencies are met

Aberta
  • Algo errado?
#3,643 3 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
62/100
Tipo de issue
Funcionalidade
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
java, kubernetes
Domínio
backend

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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

Linguagem predominante
Java
Estrelas
942
Forks
246
Merge médio
1d 11h
PRs com merge (30d)
28

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de operator-framework/java-operator-sdk

Todas as issues de operator-framework/java-operator-sdk

Issues semelhantes

Mais issues de Java

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.