Description
Polling an external system for statuses and propagating even if it's state changed is something that we can support in a generic way with an Event Source that handles the polling and caching part.
Some aspects to discuss:
-
There are 2 ways a polling could happen. Generic poller (not making a request per custom resource), like listing some changes from an API. The other approach is polling per custom resource, thus make requests for each custom resource, since the request could be different based on a specs or other parameters related to particular custom resource instance.
-
An interesting design question again popping up here how the event source knows about the custom resources, if some information is needed from them. This is something that we've already discussed before. For cleanup for example we propagate an event for all the event sources, if a custom resources deleted and the TimerEventSource has scheduled event for that event source, we want to cancel it. So to let the TimerEventSource know that the custom resource now gets a callback that the custom resource is deleted. The question is if we should not have callback on other cases, like when a custom resource created or updated. (Such callback could be implemented now of course manually from the controller.)