gyfora commented on PR #199:
URL:
https://github.com/apache/flink-kubernetes-operator/pull/199#issuecomment-1123201475
Thanks for raising this @wangyang0918
To be very specific here, the `statusCache` is needed because the
java-operator-sdk-framework does not know about the status update for already
"scheduled" reconcile operations so it might give us a stale one. The
`statusCache` is always consistent with the real status.
I think the we need both features in the long run:
1. Robust status updates
2. Persist status mid-reconciliation
V3 of the operator sdk will definitely solve 1. and they might actually
solve 2. eventually for us. There is a larger design change that we should do
after the release to help with 2:
Instead of storing non-user-facing information into the status we could use
an extra configmap per FlinkDeployment. This is the supported approach by the
operator framework for storing peristent states for the reconciliation logic.
This would already work today so we don't need to wait for any additional
feature. Then we could simply move out things like lastReconciledSpec,
reconciliationStatus etc that are only important for the operator and update
them on the fly.
So to conclude my thoughts:
Long term solution would be a combination of moving to v3 and coming up with
something nicer for the on-the-fly status updates which are necessary to keep
some things consistent and clean.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
