[Concept] Improve cached store framework on Invocation

[xiekeyang]

Current the execution chain is about notification-evaluation-rule-scheduler-action. It seems a little long chain. And the methods in invoke cache and store seem a little over checking the elements, that weaken the real-time and concurrency performance.

So I’m considering create a runtime object involving evaluation states. Then we refactor the controller to watch this runtime object, and record it to a real time cache.

I research a couple of days to the similar framework in cache k8s.io/client-go. It provides most of what we need.

Previously I introduce workqueue in it to improve and simply the queue management of EvalState.

I just create an example to show the design and workflow of the cache and watcher. The parameters of watcher is adjustable. According to my experimental, I feel it can simply the current invocation framework, and improve the performance.

The runtime object (put up an example here) can be self defined freely. It is not CRD, and needn’t to store into ETCD. It is W/R just in-memory, so the speed should be very fast.

The controller needn’t connect to k8s API server absolutely (connection to K8S server is slow). The cache comes from here. We can regard it as a pure software cache server with individual watcher routine and mapped store management.

We can design our resource (EvalState) event handle functions freely and registry them to cache informer structure. Then we can get the notification real time sync to EvalState. And then call action functions.

Maybe we can’t inherit the framework totally. But I feel it is a good reference and be worthy to take consideration.

[erwinvaneyk]

Thanks @xiekeyang for the proposal! 😁I am away on a family weekend this weekend. I will read and comment on this proposal next Tuesday

[erwinvaneyk]

We covered this a bit on Slack too, but I agree with the overall approach of repurposing some of the kubernetes scheduling code in the controller. We probably need to depend or copy the Fake implementation in your last link.

Current the execution chain is about notification-evaluation-rule-scheduler-action. It seems a little long chain.

It indeed is. As discussed on Slack, I would be in favor of removing the whole rule-action architecture. It did not work out as well as I thought initially.

And the methods in invoke cache and store seem a little over checking the elements, that weaken the real-time and concurrency performance.

Although I agree that this is probably the case, this seems like a lower-priority issue. Once we have the new/more improved controller we can reduce the smaller latency hogs step-by-step.