Returning a list of Objects in `Optional<R> ResourceEventSource.getAssociated(P primary)`

[csviri]

It can happen that multiple resources are created related to one event source, the current api of ResourceEventSource is not covering this.

[csviri]

@metacosm we could probably take a look on this before v2.0 released since it a API change.

[metacosm]

Could we have an example of why this is needed? And yes, we should probably do it before 2.0 if that's the case.

[metacosm]

I'd argue, though, that this use case might actually need to be handled via different event sources… which is why there was originally a qualifier concept (now replaced by event source name).

[csviri]

@andreaTP had a use case, maybe he will describe it more precisely, that for example you might create multiple Jobs and want to watch their status. But I guess can happen with any k8s resources, like managing more Deployments that we want just one informer not notify us about their status change.

[csviri]

I'd argue, though, that this use case might actually need to be handled via different event sources… which is why there was originally a qualifier concept (now replaced by event source name).

AFAIK also @lburgazzoli is using it this way, like watching all the resources of same kind with one event source. It completely makes sense imho. Especially if the resources can be nicely captured by label selectors.

A new event source would create a new watch, what is much less efficient in terms of network resources.

[metacosm]

It makes sense but this would be a significant change and then I'd rather postpone it until after 2.0. This should be done with the same scope as dependent resources, imo.

[csviri]

btw I think the same applies for the public interface Cache<T> interface.
Actually this is event more important, this I would not postpone.

[metacosm]

btw I think the same applies for the public interface Cache<T> interface. Actually this is event more important, this I would not postpone.

What do you mean? There can be only resource associated with a given ResourceID. In any case, if we're going to do these changes, I'd argue that we should push the dependent resources at the same time. The change has been waiting for more than a month now and if we're going to change things significantly at this point, we might as well add the dependent resources support at the same time so that we can make sure everything works well together.

[csviri]

ok, let's do that. There is still the workaround for this case to have the informer in a property and query it directly.

[metacosm]

I'd still like to see a detailed use case of why this is needed to see how it impacts the dependent resources work.

[csviri]

@Andretp could you describe you use case pls?

But IMHO this is quite trivial requirement, to allow for an operator to create multiple instances of same kind.

[csviri]

An other approach would be just to remove the getAssociatedResource from the context now for v2.0.0, but I'm fine to change it later since it's a miner thing also we can make a separate method that returns list.

[metacosm]

Having getAssociatedResource on the context makes things a lot cleaner for simple use cases. We do need to take more complex ones into account, though, but I'd like to see if maybe they could be implemented differently than requiring a change of this part.

[andreaTP]

Use case in Keycloak is tackled here: keycloak/keycloak#9535

TL;DR:

The operator has 2 controllers, one for the actual Deployment and another for "operating" the operand (in this case importing data).
The Controller for the "imports" can spawn multiple Jobs related to the single target Deployment.
Those Jobs needs to be monitored to reflect the status in the Status field of the CR.