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
This is just an idea that will allow certain optimizations in the reconciler implementation.
The feature would be to check if there is already a next reconciliation scheduled:
context.isNextReconciliationImminent()
If there is a next reconciliation scheduled means, there was an event regarding a change in the primary resource or some secondary resources. That means that some resources changed since the reconciliation started. Based on this user could decide to skip some possibly heavy operations, like even small things like calling the API server to update the status since there will be a new reconciliation shortly that will do it anyways - so this will reduce the number of K8S API Calls.
On the other hand, now there is no such thing that would be similar to "snapshot isolation" (except for the primary resource), thus when reconciliation happens always the actual resources are accessed in the cache. So unless the event/change arrived after a target secondary resource was reconciled, the reconciliation already happened on the actual resource.
The text was updated successfully, but these errors were encountered:
I think this is a good improvement that would allow controllers to optimise the reconciliations. We could also use it in Flink probably to eliminate some codepaths
This is just an idea that will allow certain optimizations in the reconciler implementation.
The feature would be to check if there is already a next reconciliation scheduled:
context.isNextReconciliationImminent()
If there is a next reconciliation scheduled means, there was an event regarding a change in the primary resource or some secondary resources. That means that some resources changed since the reconciliation started. Based on this user could decide to skip some possibly heavy operations, like even small things like calling the API server to update the status since there will be a new reconciliation shortly that will do it anyways - so this will reduce the number of K8S API Calls.
On the other hand, now there is no such thing that would be similar to "snapshot isolation" (except for the primary resource), thus when reconciliation happens always the actual resources are accessed in the cache. So unless the event/change arrived after a target secondary resource was reconciled, the reconciliation already happened on the actual resource.
The text was updated successfully, but these errors were encountered: