Expose dependent configuration for the case where we have several dependents of the same type

[metacosm]

How do dependents work when we have more than one secondary resource (like having 3 deployments) ?

Originally posted by @sebastienblanc in #785 (comment)

[scrocquesel]

Thinking about this, I see two kinds of multiple dependents of same type:

• fixed : the number of dependents is know at build time and a discriminating name should be enough. Dependents may be optional if the spec do not require it.
• dynamic : the number of dependents is known at reconcile time and depends on the spec of the CR. This is often the case when a CR is a group. After having done such an operator, I do not think it is a good practice. The only pros is that it reduces the number of CRs. Having a lot of CRs and using PerResourcePolling with a low POLL_PERIOD could take down an external system.

[metacosm]

Yes, I tend to think that we should limit ourselves to the fixed case as a start and see how it goes and if we need to make it more dynamic.

[andreaTP]

@csviri can you please point out the documentation or example code to see how this is working? Thanks a lot in advance!

[csviri]

@csviri can you please point out the documentation or example code to see how this is working? Thanks a lot in advance!

@andreaTP pls take a look here:
https://github.com/java-operator-sdk/java-operator-sdk/blob/9c1be9d59151f1673b5b2a5bea60543021fabd34/operator-framework/src/test/java/io/javaoperatorsdk/operator/sample/multiplemanageddependentsametype/MultipleManagedDependentResourceConfigMap1.java#L15-L15

Note that this is on next branch, and the api is going to change probably a little.

[andreaTP]

Thanks for the pointer @csviri , does it make sense to provide "default" discriminators based on something pretty standard like labels?