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
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
The text was updated successfully, but these errors were encountered:
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
The text was updated successfully, but these errors were encountered: