[GitHub] [flink-kubernetes-operator] gyfora commented on pull request #439: [FLINK-29959] Use optimistic locking when updating the status

[GitBox <gi...@apache.org>]

gyfora commented on PR #439:
URL: https://github.com/apache/flink-kubernetes-operator/pull/439#issuecomment-1314970498

   > Makes sense, note that this just needed in case a persistent state is managed in status. If that state would be in a separate ConfigMap/Secret might feel less "unnatural" to update it with optimistic locking. Status in Kubernetes by definition is "best effort", basically product of latest observation, so storing state little bit out of this definition.
   > 
   > Also note that it is not guaranteed that in next reconciliation you will receive the latest object unless you call one of these: https://github.com/java-operator-sdk/java-operator-sdk/blob/80e0696e4f3af371be21c15ced805ba4c2e9a1b6/operator-framework-core/src/main/java/io/javaoperatorsdk/operator/processing/event/source/informer/ManagedInformerEventSource.java#L80-L91 For `ControllerResourceEventSource` in this case.
   
   Thanks @csviri , I will check the cache update methods, but currently we have our own status cache in the `StatusRecorder` that we use to always set the latest status on the received object to get the same effect.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@flink.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org