shell-operator icon indicating copy to clipboard operation
shell-operator copied to clipboard

Support for "synchronization with external API" scenario

Open diafour opened this issue 2 years ago • 0 comments

Is your feature request related to a problem? Please describe.

There are reports about usage the shell-operator as a tool to synchronize CR state with external APIs (e.g. #322). Experience with using individual events shows it is not reliable: API server can drop Delete events on reload, Modified event treated as Added for label selectors, etc. Snapshots and groups were introduced to support converge behavior for hooks. This model is working good when everything is in cluster: hook subscribes to objects, gets all of them at once, and may detect modifications and deletions easily. It is difficult to work with external API using 'snapshots' approach: each time hook receives a snapshot of CRs, it should list all corresponding objects via API. It seems reasonable to use the Synchronization event to do the full listing via API only once, and then use this first result to compare against snapshots. The problem is that hook has no simple way to store dynamic data.

Describe the solution you'd like to see

The addon-operator has concept of values: hook can return JSON patches to update hierarchical data and to react on such changes. Here, in the shell-operator, we can implement simplified concept of values only to read and update them.

The other solution is to encourage addon-operator usage for such scenarios.

Another "solution" is to add a flag to prevent binding context combination for similar tasks. (But honestly, it's more like a crazy idea for brainstorming).

Describe alternatives you've considered

Additional context

diafour avatar Apr 18 '22 15:04 diafour