Description
Most operators need to deal with dependent (also called secondary) resources. The goal of this feature is to support common use cases as simply as possible, in particular using a declarative API.
Right now, dependent resources are implemented using EventSources. This introduce complexity because the EventSource interface doesn't provide any hint as to what it might be used for. The feature is therefore not very discoverable.
Moreover, dealing with dependent resources involves quite a bit of boiler plate and is very often done similarly for a lot of operators. In essence, the process very often boils down to retrieving the resources associated with the primary resource and reconcile their state based on the state of the primary resource. The status of the primary resource is also very often computed based on the aggregate status of the dependent resources.
We propose to introduce specific support for dependent resources that would simplify their handling for simple yet common cases. That support wouldn't interfere with the rest of the framework in the sense that it should still be possible to write reconcilers without ever using the dependent resources support.
We have a prototype implementation that limits the scope of the support to only Kubernetes resources (i.e. external resources are not currently supported with the current implementation, though it could be extended to support such resources at some later time) but provides declarative support for dependent resources (via child fields of the ControllerConfiguration annotation).
In essence, a reconciler defines which is its primary resource (via its parameter type) and can additionally opt-in declaring dependent resources. The DependentResourceConfiguration annotation allows you to specify the behavior of your dependent resource by providing updater / builder "functions" (along with some other aspects of the dependent) that are called automatically by the framework when needed, thus allowing you to focus on the salient parts of the state management instead of having to deal with the low-level wiring of the events.
PR #726 provides a prototype of how things could look like. To get a feel of how this could look like more concretely, please look at https://github.com/java-operator-sdk/java-operator-sdk/pull/726/files#diff-2b32527ca84105529bced8f05e575c973c00abb045b30beb578aaa29cb3fd65b which shows the diff between the updated version of the TomcatReconciler class with its associated DeploymentDependentResource and ServiceDependentResource classes. Similarly, take a look at the WebappReconciler diff implementation: https://github.com/java-operator-sdk/java-operator-sdk/pull/726/files#diff-00b61e3c421a88aa771a8b8f9f7e8ba18d81b751e4cfc85062954dbfd81e1095