Umbrella Issue for improved and Utility EventSources provided for V2

[snowdrop-bot]

Event Sources provides functionality to get notifications, thus trigger reconciliation if a dependent resource changes. Withing this issue the topic is revisited, and will try to improve and provide implementation of event sources that would help to cover most of the use cases.

Event Sources Categories

We can divide event sources into two big categories:

1. Event Sources for Kuberentes Resource or InformerEventSource
   This event source covers the watching and caching the Kubernetes resources. Already present in the system. Provides a
   cache of the observed resources too.
2. Non Kubernetes (external) Resources. Think of a object that is not managed by Kubernetes it self, from Database users, to git repositories, etc. But still here we communicate with an API. Ideally still through well defined REST API, thus managing resources in a declarative way. Based how these objects are managed we can divide this to two sub-categories.
   1. Pull based - when we have to basically poll the resource to get the actual state, in regular intervals.
   2. Push based - when a notification in some form is received about the changes of the resource. Like a webhook or sqs queue - you name it.

Polling Event Source for Pull Based Updates

For two Implementations are provided:

1. PerResourcePollingEventSource - Periodically calls a provided function for each custom resource.
2. PollingEventSource - Is for use cases when resources can be queried from an api, but it is done for a generic way. Like listing some object with realted tags. Then these are mapped to ResourceID-s.

Both of these provide caches of the resources. The events are propagated only if resources changed (checked by equals method on pojos).

Inbound Event Sources for Push Based Updates

Inbound event sources are for the case when we receive some notifications about the resources. For now we don't support specific systems, but provide basic implementation that could be used or extended to easily support any notification system. Like webhooks, or messaging systems.

1. SimpleInboundEventSource - tyically for use cases when the notification is not resource based. This event source make it just easy to propagate any event into the system. Does not provide caching.

2. CachingInboundEventSource - Typically for use cases when the notification is resource based, in other works we receive the whole resource within the event. This implementation provides caching.

Note that these event sources also provide addtional functionalities, like filtering of events.

Abstract Event Sources to Support Custom Ones

CachingFilteringEventSource - is an abstract event source (serves as a base class for some above), that supports caching and event filtering.

Custom Resource Event Notifications for Event Source

See also:

operator-framework#651
operator-framework#665
operator-framework#666
operator-framework#673

---

operator-framework#729

---

$upstream:729$