Recently we changed event filtering, see details here: #3484
That bit limits the capabilities of this feature.
In next minor version we could still provide improved alternatives in ResourceOperations that user can use to optimize their specific use cases.
Prevent no-op updates
Things to consider regarding this enhancement:
- Users ideally do just updates/patches on resources when the desired state of those resources are not in the desired state.
- We discovered an issue with event filtering, it only works reliable in all the cases when the update changes the resources (so results in a bump in resource version)
Introducing an update mode for methods in ResourceOperations , that will match the current state with desired state and executes the patch only those cases, would handle these two situations optimally.
We already have such matchers implemented and battle tested partially (not for status updates) for dependent resources, so we can just reuse them here.
Handling the common case for the primary
For the common case when reconciler only updates the status and does not update the spec, actually we can handle in general. By recording the update intent in EventFilterWindow.
Option for the user decide
TODO
Explicit cache-only methods
TODO
Combination of those
TODO
Other Remarks
- In
UpdateControl we still have .patchResource and .patchResourceAndStatus. In future we might:
- want to deprecated this, since generally considered as a bad practice to do updates on the spec of the controller. (Users with some special need will be able to still do it using the
KubernetesClient or ResourceOperations.
- If other than the status is updated we might want to enforce optimistic locking in
UpdateControl since there is a risk that it would override some changes on spec from third party.
Recently we changed event filtering, see details here: #3484
That bit limits the capabilities of this feature.
In next minor version we could still provide improved alternatives in ResourceOperations that user can use to optimize their specific use cases.
Prevent no-op updates
Things to consider regarding this enhancement:
Introducing an update mode for methods in
ResourceOperations, that will match the current state with desired state and executes the patch only those cases, would handle these two situations optimally.We already have such matchers implemented and battle tested partially (not for status updates) for dependent resources, so we can just reuse them here.
Handling the common case for the primary
For the common case when reconciler only updates the status and does not update the spec, actually we can handle in general. By recording the update intent in
EventFilterWindow.Option for the user decide
TODO
Explicit cache-only methods
TODO
Combination of those
TODO
Other Remarks
UpdateControlwe still have.patchResourceand.patchResourceAndStatus. In future we might:KubernetesClientorResourceOperations.UpdateControlsince there is a risk that it would override some changes on spec from third party.