Informer based CustomResourceEventSource

[csviri]

Using informer instead of a simple Watch in the custom resource event source will make it more reliable. Also it will serve as a cache for, replacing our current approach for caching.

In general informers does the watching little differently then the current approach. First lists the resources then starts watching but just from the last seen resource version (this eliminates some watcher related issues) also handles the watch reconnect in the same way.
Informers also provide caches and other nice features for indexing (+custom indexes, although the custom indexing is not relevant for this issue)

This fits very much into the picture where we want to be with the CustomResourceEventSource and it's not our code that we have to maintain.

Fabric8 provides a nice implementation: https://github.com/fabric8io/kubernetes-client/tree/master/kubernetes-client/src/main/java/io/fabric8/kubernetes/client/informers

Notes:

• For this we will have to make few significant changes to the the framework. One of them is how we address internally custom resources, for now it's by UID. We will have to change this to namespace (optional) and name pair. Since this is how these resources are addressed in informer cache (store). Also this is a more future-proof mechanism, in case we want to implement in future transient caches we would not able to do it with UID, since a resource uid is not indexed (at least for now) in K8S. So in case of a cache miss, reading from api should be based on namespace and name (type we already know based on controller).

[csviri]

This will make the following issue obsolete: #356

[metacosm]

This will make the following issue obsolete: #356

We might end up exposing the informer's cache for configuration at some point, though… 😄

[lburgazzoli]

This issue on fabric8 client may also be relevant fabric8io/kubernetes-client#3472 so we can customize the key and index function if/when it make sense

[csviri]

This will make the following issue obsolete: #356

We might end up exposing the informer's cache for configuration at some point, though… smile

I guess that will be v3 :)

[adam-sandor]

"event source will make it more reliable". How is it going to make things more reliable? Would be great to have a well-reasoned explanation for this major change.

[csviri]

Hi @adam-sandor,
true, probably we should refine these issues on community meeting also.

In general informers does the watching little differently then the current approach. First lists the resources then starts watching but just from the last seen resource version (this eliminates some watcher related issues) also handles the watch reconnect in the same way.
Informers also provide caches and other nice features for indexing (+custom indexes, although the custom indexing is not relevant for this issue)

This fits very much into the picture where we want to be with the CustomResourceEventSource and it's not our code that we have to maintain.

Fabric8 provides a nice implementation: https://github.com/fabric8io/kubernetes-client/tree/master/kubernetes-client/src/main/java/io/fabric8/kubernetes/client/informers