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

Consider composable non-CRD blocks for workflows / dependencies

Aberta
  • Algo errado?
#2,256 12 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
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
25/100
Tipo de issue
Funcionalidade
Clareza
Precisa de esclarecimento
Status de atividade
Estagnada
Stack de tecnologia
java, kotlin, kubernetes
Domínio
devops, tooling

Direção de pesquisa

Comece lendo os conceitos de workflow model, Reconciler e Resolver referenciados na issue e, em seguida, inspecione AbstractNamedCRUDDependentResource e o exemplo RedisConfigMap. Compare as declarações atuais de dependências baseadas em CRD e anotações com os blocos reutilizáveis solicitados e as dependências por recurso. Considera-se concluído quando o escopo suportado e a API para blocos de dependências componíveis estiverem definidos e demonstrados, com cobertura para recursos reutilizados como ConfigMaps, Secrets e PersistentVolumeClaims.

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

Descrição

Currently, all dependencies using the workflow model (seem to) require either declaring them in their own CRD, or expanding on the blocks used inside a single Reconciler.

It would be nice to be able to define a block of dependencies that is reusable in scope. In my particular case, this is so that we can create separate building blocks for commonly reused entities (see datastores, etc) that do not necessarily meet the case for having a standalone CRD.

This is for two reasons:

  1. The entities themselves maybe managed by other operators and we are considering dependency / ready states for the particular operator.
  2. The the individual deployments themselves do not reflect something that is of a desired scope for its own CRD. In several cases, this may be because we are developing an application and the particular implementation under the hood may change, or it is something that doesn't necessarily warrant its own set of description.
  3. The development of commons libraries for shared patterns between operators or, in the case of multi-controller operators, between different pieces.

Additionally, having a mechanism by which dependencies can be mapped at the level of the individual resource, especially in the case of multiple config maps, secrets, volumeclaims, etc, can then be declared at the point of the dependent resource.

class RedisConfigMap<T: HasMetadata>(val app: App) : AbstractNamedCRUDDependentResource<ConfigMap, T>(ConfigMap::class.java)
{
    companion object {
        fun <T: HasMetadata> withDiscriminator(app: App) : AbstractNamedCRUDDependentResource<ConfigMap, T> {
            return RedisConfigMap<T>(app).withDiscriminator()
        }
    }

    override fun desired(primary: T?, context: Context<T>?): ConfigMap {
        return ConfigMapBuilder()
            .withNewMetadata()
            .withNamespace(primary!!.metadata.name)
            .withName(name())
            .endMetadata()
            .addToData("redis-config", "")
            .build()
    }

    override fun name(): String {
        return "${app.appName}-redis-config"
    }

Is an example of a piece of code I am working on (it's Kotlin, so, bear with me -- and thank you glasskube!)

It would be nice if, instead of piling the configuration into annotations on the Resolver, individual resources could also support declaring their dependencies.

Linguagem predominante
Java
Estrelas
943
Forks
245
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.