[
https://issues.apache.org/jira/browse/FLINK-27551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17533761#comment-17533761
]
Gyula Fora commented on FLINK-27551:
------------------------------------
[~wangyang0918] Yes you are right this is due to the locking behaviour, this
might be fixed in the josdk 2.1.3, I will test.
But still I think we should consider making FlinkDeployment status updates
manually also. There are cases where we need to persist information into the
status before we can proceed. For this we would now need to retrigger
reconciliation with an intermediate state persisted (such as storing last
savepoint info before shutting down a failed cluster). In these cases we should
simply make the status update ourself. This would simplify the logic and
eliminate some corner cases .
> Consider implementing our own status update logic
> -------------------------------------------------
>
> Key: FLINK-27551
> URL: https://issues.apache.org/jira/browse/FLINK-27551
> Project: Flink
> Issue Type: Improvement
> Components: Kubernetes Operator
> Reporter: Gyula Fora
> Priority: Critical
>
> If a custom resource version is applied while in the middle of a reconcile
> loop (for the same resource but previous version) the status update will
> throw an error and re-trigger reconciliation.
> In our case this might be problematic as it would mean we would retry
> operations that are not necessarily retriable and might require manual user
> intervention.
> Please see:
> [https://github.com/java-operator-sdk/java-operator-sdk/issues/1198]
> I think we should consider implementing our own status update logic that is
> independent of the current resource version to make the flow more robust.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
