Support Bulk read-only dependent resources

[tomdw]

On https://javaoperatorsdk.io/docs/dependent-resources#read-only-dependent-resources-vs-event-source there is a section on read only dependent resources.

However, as soon as it is more than 1 dingle dependent resource, i.e. a bulk of dependent resources of the same type, then there is not possibility to make it a read-only resource.

Support for bulk resources through BulkDependentResource assumes that creating and updating those resources is needed. For a read-only dependent resource this is not the case.

The scenario is to make a reconciler/operator also listen to additional dependent resources that are not created by the operator itself. We could use an event source only, but the dependent resources would make it easier.

[csviri]

Hi @tomdw , thx for the issue, could you describe the use case more in depth? To be hones I see a little value in this. Around read-only dependents was already a dilemma. So could describe please, where/how exactly this would help in you case?

[tomdw]

@csviri It has the same value as the read-only dependents documented and advised on the link I provided above. The only things this request adds is to also support this for a one-to-many relationship between the primary and the dependents. It is another operator or process or manual action that creates the dependent resources and the primary needs to watch these and react accordingly.

Example: update its status based on the information from the many dependent resources + when the primary is deleted also cleanup the dependents.

[csviri]

I see, the only real value I see in this:

1. as mentioned in the docs, there can be conditions (well mostly ready condition) on a read only dependent - in combination with depends on relation.
2. you can use this API from the condition:

   java-operator-sdk/operator-framework-core/src/main/java/io/javaoperatorsdk/operator/processing/dependent/BulkDependentResource.java

   Line 41 in 1fc9e3e

   Map<String, R> getSecondaryResources(P primary, Context<P> context);

Otherwise in the background will happen exactly the same as when having a (non-bulk) read only dependent / informer.
So I agree that even this might have an added value, even if that is not that large.