[
https://issues.apache.org/jira/browse/FLINK-28187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17557522#comment-17557522
]
Gyula Fora commented on FLINK-28187:
------------------------------------
We do upgrades in 2 steps, in the UPGRADING state the expected upgrade target
generation is already in the status.
We have to put the generation in the jobid otherwise we don't know if a job in
upgrading state was already upgraded or not.
Please look at this commit:
[https://github.com/apache/flink-kubernetes-operator/commit/ab59d6eb980512775590d0d01e697fe0c28d1b3b]
This is not so different how applications work also. You always have a single
application cluster but still you need to attach the generation info otherwise
you cannot deal with errors happening during or directly after submission.
> Duplicate job submission for FlinkSessionJob
> --------------------------------------------
>
> Key: FLINK-28187
> URL: https://issues.apache.org/jira/browse/FLINK-28187
> Project: Flink
> Issue Type: Bug
> Components: Kubernetes Operator
> Affects Versions: kubernetes-operator-1.0.0
> Reporter: Jeesmon Jacob
> Priority: Critical
> Attachments: flink-operator-log.txt
>
>
> During a session job submission if a deployment error (ex:
> concurrent.TimeoutException) is hit, operator will submit the job again. But
> first submission could have succeeded in jobManager side and second
> submission could result in duplicate job. Operator log attached.
> Per [~gyfora]:
> The problem is that in case a deployment error was hit, the
> SessionJobObserver will not be able to tell whether it has submitted the job
> or not. So it will simply try to submit it again. We have to find a mechanism
> to correlate Jobs on the cluster with the SessionJob CR itself. Maybe we
> could override the job name itself for this purpose or something like that.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
