akukhar commented on PR #1234: URL: https://github.com/apache/flink-kubernetes-operator/pull/1234#issuecomment-6454962325
Thanks for the feedback, @Dennis-Mircea. I agree this isn't specific to the autoscaler ConfigMap: other writes in the operator can fail the same way. This PR fixes the case we hit in production on GKE, and the new tests reproduce it using the fabric8 client against its mock server. Two points about where to handle it: - In general, fabric8 can't tell whether the stored object already contains what the caller meant to write. Only the caller knows which fields matter, so this PR adopts the stored ConfigMap only when its data and owner references equal the local state, and rethrows any other conflict. - `KUBERNETES_REQUEST_TIMEOUT` can't help in every case, because fabric8 also resends a request after a dropped connection or a 5xx response. A longer timeout only makes the timeout case rarer. I'd like to keep this PR limited to the autoscaler case we reproduced, where the condition for accepting the stored state is defined and tested. Other call sites would need to be assessed separately, so I can open follow-up tickets for them. -- 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]
