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
Polling an external system for statuses and propagating event if its 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 spec or other parameters related to particular custom resource instance.
An interesting design question again popping up here is 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 resource is deleted and the TimerEventSource has scheduled event for that event source, we want to cancel it. So there's a callback to let the TimerEventSource know 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.)
The text was updated successfully, but these errors were encountered:
Uh oh!
There was an error while loading. Please reload this page.
Polling an external system for statuses and propagating event if its 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 spec or other parameters related to particular custom resource instance.
An interesting design question again popping up here is 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 resource is deleted and the TimerEventSource has scheduled event for that event source, we want to cancel it. So there's a callback to let the TimerEventSource know 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.)
The text was updated successfully, but these errors were encountered: