operator-framework / operator-framework/java-operator-sdk

Consider composable non-CRD blocks for workflows / dependencies

Abierto
#2,256 12 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Lenguaje dominante
Java
Estrellas
944
Forks
242
Merge medio
1 d 4 h
PR fusionados (30 d)
43

Descripción

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.

Guía de contribución

Abrir la guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Línea de trabajo

Empieza leyendo los conceptos de workflow model, Reconciler y Resolver referenciados en el issue y, después, inspecciona AbstractNamedCRUDDependentResource y el ejemplo RedisConfigMap. Compara las declaraciones actuales de dependencias basadas en CRD y anotaciones con los bloques reutilizables solicitados y las dependencias por recurso. Se considera terminado cuando estén definidos y demostrados el alcance compatible y la API para bloques de dependencias componibles, con cobertura para recursos reutilizados como ConfigMaps, Secrets y PersistentVolumeClaims.

Escrito por el modelo de indexación a partir del texto del issue.

Evaluación

Stack tecnológico
java, kotlin, kubernetes
Área
devops, tooling
Tipo de issue
Nueva funcionalidad
Dificultad
5/5
Tiempo estimado
Más de una semana
Estado de actividad
Estancado
Claridad
Necesita aclaración
Aptitud para principiantes
25/100

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.