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
It's a common practice in controllers to save observed generation in status sub-resource, thus to save the .metadata.generation that was last time reconciled to .status.observedGeneration.
The sdk could support this out of the box.
One way to do it, is to just check if the status POJO, on the resource has this field, and before we make the updateStatus call on API we just update it automatically.
(Note that quarkus needs to be supported, so be cautious about the reflection limitations)
An other more extensible way would be to provide an interface, which can be implemented by the custom resource, with two methods: setObservedGeneration(generation) and getObservedGeneration. The user can implement the methods, to customize the field name or path. Although since it's quite common just to have the .status.observedGeneration in this path, this might be an over engineering.
The second part would be to use the field to make decision if a reconciliation loop should be triggered. Note that now we support generations in a way that controller is executed only if the generation is increased (can be turned off). However we store the last processed generation in memory, so if the operator is restarted we reconcile all the resources, event if the generation is not increased. So using this field would prevent unnecessary reconciliations and spare us some memory.
Note that this can be backwards compatible with the current implementation. But not sure if we should just push this into v2 in a opinionated way, where we just use the value from status, not from memory.
It's a common practice in controllers to save observed generation in status sub-resource, thus to save the
.metadata.generation
that was last time reconciled to.status.observedGeneration
.The sdk could support this out of the box.
One way to do it, is to just check if the status POJO, on the resource has this field, and before we make the updateStatus call on API we just update it automatically.
(Note that quarkus needs to be supported, so be cautious about the reflection limitations)
An other more extensible way would be to provide an interface, which can be implemented by the custom resource, with two methods:
setObservedGeneration(generation)
andgetObservedGeneration
. The user can implement the methods, to customize the field name or path. Although since it's quite common just to have the.status.observedGeneration
in this path, this might be an over engineering.The second part would be to use the field to make decision if a reconciliation loop should be triggered. Note that now we support generations in a way that controller is executed only if the generation is increased (can be turned off). However we store the last processed generation in memory, so if the operator is restarted we reconcile all the resources, event if the generation is not increased. So using this field would prevent unnecessary reconciliations and spare us some memory.
Note that this can be backwards compatible with the current implementation. But not sure if we should just push this into v2 in a opinionated way, where we just use the value from status, not from memory.
operator-framework#563
The text was updated successfully, but these errors were encountered: