[
https://issues.apache.org/jira/browse/FLINK-13573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16901884#comment-16901884
]
TisonKun edited comment on FLINK-13573 at 8/7/19 8:44 AM:
----------------------------------------------------------
Thanks for your attention [~till.rohrmann].
For backwards compatibility, it would be a problem if
A cluster running with a previous version(said 1.9) persisted job
graphs({{SubmittedJobGraph}}) while another cluster(standby) was running with
the same cluster-id(this is only valid in standalone mode) with a new
version(said 1.10) expect job graphs as {{JobGraph}}.
In reality, user would rarely deploy clusters with different version for the
same jobs. And if a user want to execute running jobs with a new cluster, the
formal way is, first cancel with savepoint and submit the job to the new
cluster with savepoint. In this way the job graph will be persisted by the new
dispatcher(should be with a new cluster-id reasonably, hence a new namespace).
Besides, previously we have this commit(FLINK-11649) which would break
serialization compatibility. But so far there has been no user who reported it
as an issue. Thus I think we can merge {{SubmittedJobGraph}} into {{JobGraph}}
without afraid of breaking backwards compatibility. Again, the formal way to
execute a running job with a new cluster is first cancel with savepoint and
submit the job to the new cluster with savepoint.
was (Author: tison):
Thanks for your attention [~till.rohrmann].
For backwards compatibility, it would be a problem if
a cluster ran with a previous version(said 1.9) persisted job
graphs(SubmittedJobGraph)
while another cluster(standby) ran with the same cluster-id(this is only valid
in standalone mode) with a new version(said 1.10) expect job graphs as
{{JobGraph}}
In reality, user would rarely run clusters with different version for the same
jobs. And if user want to execute running jobs with a new cluster, the formal
way is first cancel with savepoint and submit the job to the new cluster with
savepoint. In this way the job graph will be submitted by the new
dispatcher(should be with a new cluster-id reasonably, hence a new namespace).
Besides, previously we have this commit(FLINK-11649) which would break
serialize compatibility and so far there is no user report it as an issue. Thus
I think we can merge {{SubmittedJobGraph}} into {{JobGraph}} without afraid of
backwards compatibility. Again, the formal way to execute a running job with a
new cluster is first cancel with savepoint and submit the job to the new
cluster with savepoint.
> Merge SubmittedJobGraph into JobGraph
> -------------------------------------
>
> Key: FLINK-13573
> URL: https://issues.apache.org/jira/browse/FLINK-13573
> Project: Flink
> Issue Type: Improvement
> Components: Runtime / Coordination
> Affects Versions: 1.10.0
> Reporter: TisonKun
> Priority: Major
> Fix For: 1.10.0
>
>
> As time goes on, {{SubmittedJobGraph}} becomes a thin wrapper of {{JobGraph}}
> without any additional information. It is reasonable that we merge
> {{SubmittedJobGraph}} into {{JobGraph}} and use only {{JobGraph}}.
> WDYT? cc [~till.rohrmann] [~GJL]
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
