Consider composable non-CRD blocks for workflows / dependencies

Beginne damit, die im Issue referenzierten Konzepte des workflow model, Reconciler und Resolver zu lesen, und untersuche anschließend AbstractNamedCRUDDependentResource sowie das Beispiel RedisConfigMap. Vergleiche die aktuellen CRD- und annotationsbasierten Deklarationen von Abhängigkeiten mit den angeforderten wiederverwendbaren Blöcken und den Abhängigkeiten pro Ressource. Als abgeschlossen gilt die Definition und Demonstration des unterstützten Umfangs und der API für zusammensetzbare Abhängigkeitsblöcke, einschließlich der Abdeckung wiederverwendeter Ressourcen wie ConfigMaps, Secrets und PersistentVolumeClaims.

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.