Cache for Reconciler for Whole Primary Life-cycle

[csviri]

There are cases when users would like to cache some information that persists across the reconciliation of primary resources.

Typical use case what we see in some controllers, that in status the state is persisted, but it is not guaranteed that in the next reconciliation, the up-to-date primary resource will be present (although we might be able to guarantee that in the future - but that is a question mark for now), in that case, the status can be also cached, thus made sure that it is available as such in next reconciliation.

From the controller side what we can do is also clean this cache when a DELETE event is received for the primary resource. (In Processor already such cleanup is happening regarding other states)

API could look like this.

Map<String,Object> Context.getCache()

or just:

Context.putToCache(String key, T value);

T Context.getFromCache(String key);

[gyfora]

How will this cache relate to status updates triggered through the JOSDK vs the ones triggered through fabric8 directly? Do we need to use the cache in both cases?

To set some context for our question, in the Flink operator we perform status patches in multiple places throughout the reconciliation logic to guarantee that the state is persisted before proceeding with some potentially destructive action. We have similar caching logic implemented completely independently and we always replace the status from that.

[csviri]

Good question, regarding status updates, in UpdateControl we could have an additional flag to cache the response.

Regarding the fabric8 client, it would not be integrated with it at all. But note that DependentResources already has guaranteed there for secondary resources.

So most cases this API should be called explicitly, unfortunately, this form would not put too much on the table, just that the cache would be cleaned up automatically - compared to that if users want to implement such functionality the Cleaner needs to be implemented and clean up the cache explicitly. (For this reason, I'm also a little hesitant regarding this feature)

[gyfora]

In our case it's not a secondary resource for which we do this but the primary resource that we are controlling. If the user needs to do this everywhere explicitly I agree that this is not too useful and probably should be left to the user.

[csviri]

I agree, this would have little benefit. Will close the issue for now.