Repository navigation
Option to trigger reconciler on all event #2893
Description
Activity
- linked a pull request that will close this issuefeat: option to triggering reconciler on all events #2894
on Aug 11, 2025 Something that we might want to discuss also on commity meeting
- changed the title
[-]Introduce "all-event-mode"[/-][+]Introduce "all-event-reconcile-mode"[/+]on Aug 11, 2025 - changed the title
[-]Introduce "all-event-reconcile-mode"[/-][+]Introduce reconcile all event mode[/+]on Aug 11, 2025 I think it's fine for the SDK to be opinionated and not deal with corner cases which make everything else more complex. Moving forward, supporting such corner cases should be well motivated with concrete explanations as to why they're needed instead of hypothetical use cases and I don't think that's the case here.
There is difference between opionated and not general enough. There is a reason why Go Operator SDK, does not have it this opionated, and I actually got questions regarding cahce cleanups on Delete events. But to give you a real life example:
Glue operator now maintains a in memeory state for which resource is what Informer is created, to clean this up would be perfectly enough to react on Delete event, and not have finalizer.
Finalizers can be in practice quite problematic, when for example some deletes namespaces, and it is very nice to have it avoided.
Not covering such use cases could mean loosing users, so they will choose different framework if we are not generic enough.
This feature provides the same level of generality as the de-facto stanadar thego controller-runtimeAnother way to look at this is we can just simply propagat all event to reconiler so user can act upon those events. Actually will reformulate it the issue, since that might better to see why makes sense.
- changed the title
[-]Introduce reconcile all event mode[/-][+]Allow users to manually manage finalizers[/+]on Sep 3, 2025 - changed the title
[-]Allow users to manually manage finalizers[/-][+]Allow users to manually manage finalizers / propagate all events to reconciler[/+]on Sep 3, 2025 - changed the title
[-]Allow users to manually manage finalizers / propagate all events to reconciler[/-][+]Allow to propagate all events to reconciler[/+]on Sep 3, 2025 I'm not against this feature but we used to propagate these events and decided to remove that option for pretty good reasons. See https://javaoperatorsdk.io/docs/faq/#how-can-i-access-the-events-that-triggered-reconciliation or even your own blog post on event sources, on the topic. So the question of why it would be a better idea now is a pertinent one.
That said, if access to events is added again, then all events should be available and I don't think that it should be implemented as a feature flag, but rather, using a listener architecture so that reconcilers can subscribe to receive these events and propagating these events would only happen in the presence of such listeners.
Ahh sorry, maybe I was not clear on that detail:
the event won't be accessed even now. Only the reconiler will be triggered for the delete event too. There will be a flag to check if the resource is deleted, but that is only to have a generic API. Since we always propagate the resource also in this case as the reconciler paramter. (note that this is different in go, there you just receive the resource ID) , but that resource is missing from the cache when the delete event already received, so in this case will be propagated the resource from the last (delete) event. So user can check if the resource was already deleted or not from the context (it could be checked against the cache but this is a bit nicer API - we can change / discuss that)
- changed the title
[-]Allow to propagate all events to reconciler[/-][+]Trigger reconciler on all event[/+]on Sep 4, 2025 - changed the title
[-]Trigger reconciler on all event[/-][+]Trigger reconciler on all event [/+]on Sep 4, 2025 - changed the title
[-]Trigger reconciler on all event [/-][+]Option to trigger reconciler on all event [/+]on Sep 13, 2025 An alternative would be just have this as the default behavior (maybe for v6), and users will be able to filter out delete event with a filter - what is already there. That way we don't introduce a new feature flag, or any other construct.
We could categorize controller into two groups, when they use finalizers and when they don't. The framework now handles these cases intelligently. Like we add finalizers, and trigger the
cleanupfuntion when needed. Howeever there are cases whis not possible to cover with the current approach:So for sake of completeness would like to an option to not manage finalizer, and propagate all the events to reconciler.
This might be a flag to
propagateAllEvents=true/falseThis way framework will be as generic as
controller-runtimeIf cleaner is implemented, the
cleanupmethod will be called from the point that the resource is marked for deletion, and for delete event. If not reconcile method is called in all cases, on every event (including delete). - but this is up to discussion if we want to support that.