You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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?
@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.
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.
Activity
csviri commentedon Feb 5, 2024
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 commentedon Feb 5, 2024
@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 commentedon Feb 5, 2024
I see, the only real value I see in this:
java-operator-sdk/operator-framework-core/src/main/java/io/javaoperatorsdk/operator/processing/dependent/BulkDependentResource.java
Line 41 in 1fc9e3e
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.