tagarr commented on code in PR #712:
URL:
https://github.com/apache/flink-kubernetes-operator/pull/712#discussion_r1415815965
##########
flink-kubernetes-operator/src/main/java/org/apache/flink/kubernetes/operator/service/AbstractFlinkService.java:
##########
@@ -195,8 +199,25 @@ public void submitApplicationCluster(
if (requireHaMetadata) {
validateHaMetadataExists(conf);
}
+ try {
+ deployApplicationCluster(jobSpec, removeOperatorConfigs(conf));
+ } catch (RuntimeException e) {
+ LOG.warn("Caught Exception " + e.getMessage());
+ if (!isValidRuntimeException(conf, e)) {
+ throw e;
+ }
+ }
Review Comment:
I'll try and explain the problem. If the tls config for the flinkdeployment
is different to the operator then on creating (deploying) a FlinkDeployment, a
rest client is always returned see
https://github.com/apache/flink/blob/c5808b04fdce9ca0b705b6cc7a64666ab6426875/flink-kubernetes/src/main/java/org/apache/flink/kubernetes/KubernetesClusterDescriptor.java#L232.
This has the tls configuration for the deployment and may not match that of
the operator, so will throw an exception even though the rest client is not and
will never be used. This exception is then propagated into the CR and looks
like its failed. However after a few reconciles it will correct itself. I
thought catching this erroneous exception would prevent users thinking they
have an issue with their deployment
--
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-unsubscr...@flink.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
