[jira] [Commented] (FLINK-4408) Submit Job and setup ExecutionGraph

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/FLINK-4408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15524664#comment-15524664
 ] 

ASF GitHub Bot commented on FLINK-4408:
---

Github user KurtYoung closed the pull request at:

https://github.com/apache/flink/pull/2480


> Submit Job and setup ExecutionGraph
> ---
>
> Key: FLINK-4408
> URL: https://issues.apache.org/jira/browse/FLINK-4408
> Project: Flink
>  Issue Type: Sub-task
>  Components: Cluster Management
>Reporter: Xiaogang Shi
>Assignee: Kurt Young
>
> Once granted the leadership, JM will start to execute the job.
> Most code remains the same except that 
> (1) In old implementation where JM manages the execution of multiple jobs, JM 
> has to load all submitted JobGraphs from SubmittedJobGraphStore and recover 
> them. Now that the components creating JM will be responsible for the 
> recovery of JobGraphs, JM will be created with submitted/recovered JobGraph, 
> without the need to load the JobGraph.
> (2) JM should not rely on Akka to listen on the updates of JobStatus and 
> Execution.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FLINK-4408) Submit Job and setup ExecutionGraph

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/FLINK-4408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15509612#comment-15509612
 ] 

ASF GitHub Bot commented on FLINK-4408:
---

Github user StephanEwen commented on the issue:

https://github.com/apache/flink/pull/2480
  
This looks quite good to me. Will try to merge it onto the latest `flip-6` 
branch...


> Submit Job and setup ExecutionGraph
> ---
>
> Key: FLINK-4408
> URL: https://issues.apache.org/jira/browse/FLINK-4408
> Project: Flink
>  Issue Type: Sub-task
>  Components: Cluster Management
>Reporter: Xiaogang Shi
>Assignee: Kurt Young
>
> Once granted the leadership, JM will start to execute the job.
> Most code remains the same except that 
> (1) In old implementation where JM manages the execution of multiple jobs, JM 
> has to load all submitted JobGraphs from SubmittedJobGraphStore and recover 
> them. Now that the components creating JM will be responsible for the 
> recovery of JobGraphs, JM will be created with submitted/recovered JobGraph, 
> without the need to load the JobGraph.
> (2) JM should not rely on Akka to listen on the updates of JobStatus and 
> Execution.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FLINK-4408) Submit Job and setup ExecutionGraph

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/FLINK-4408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15472703#comment-15472703
 ] 

ASF GitHub Bot commented on FLINK-4408:
---

GitHub user KurtYoung opened a pull request:

https://github.com/apache/flink/pull/2480

[FLINK-4408][JobManager] Introduce JobMasterRunner and implement job 
submission & setting up the ExecutionGraph

Introduce JobMasterRunner to deal with job level leader election and make 
underlying job manager properly reacted. Also this runner takes care of 
determining whether job should be submitted with recover fashion. 

This PR also implement the job submission skeleton and setting up the 
ExecutionGraph, but the interactions with client has been marked as TODO since 
it may rely on something like JobClientGateway. I'd like to take care of that 
in a seperate PR later.

The main procedure of managing the lifecycle of a job is:

* Once we received a job submission request from the user, we create a 
JobMasterRunner to deal with it. 
* JobMasterRunner will first create leader election service to contend the 
leader of this job, once leadership is granted, it will try to do some real 
submission work. 
* Any error occurred during the submission phase will make this job as 
rejected and dropped.
* Once job is accepted, we will face two levels on job retry:
  1. Retarting upon execution failure, it's been taken care of 
RestartStrategy, and it's mainly __inside__ the ExecutionGraph
  2. Loose of leadership, it will be handled by JobMasterRunner, the old 
ExecutionGraph will be suspended and then disposed. Retrying should re-submit 
the job to the JobMaster with isRecovery marked as true. 



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/KurtYoung/flink flink-4408

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/flink/pull/2480.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2480


commit c5afeb1718f14b47739039b7f4695a791e2f1d20
Author: Kurt Young 
Date:   2016-09-08T04:00:13Z

[FLINK-4408][JobManager] Introduce JobMasterRunner and implement job 
submission & setting up the ExecutionGraph




> Submit Job and setup ExecutionGraph
> ---
>
> Key: FLINK-4408
> URL: https://issues.apache.org/jira/browse/FLINK-4408
> Project: Flink
>  Issue Type: Sub-task
>  Components: Cluster Management
>Reporter: Xiaogang Shi
>Assignee: Kurt Young
>
> Once granted the leadership, JM will start to execute the job.
> Most code remains the same except that 
> (1) In old implementation where JM manages the execution of multiple jobs, JM 
> has to load all submitted JobGraphs from SubmittedJobGraphStore and recover 
> them. Now that the components creating JM will be responsible for the 
> recovery of JobGraphs, JM will be created with submitted/recovered JobGraph, 
> without the need to load the JobGraph.
> (2) JM should not rely on Akka to listen on the updates of JobStatus and 
> Execution.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FLINK-4408) Submit Job and setup ExecutionGraph

[Stephan Ewen (JIRA)]

[ 
https://issues.apache.org/jira/browse/FLINK-4408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15434820#comment-15434820
 ] 

Stephan Ewen commented on FLINK-4408:
-

Agreed

> Submit Job and setup ExecutionGraph
> ---
>
> Key: FLINK-4408
> URL: https://issues.apache.org/jira/browse/FLINK-4408
> Project: Flink
>  Issue Type: Sub-task
>  Components: Cluster Management
>Reporter: Xiaogang Shi
>Assignee: Xiaogang Shi
>
> Once granted the leadership, JM will start to execute the job.
> Most code remains the same except that 
> (1) In old implementation where JM manages the execution of multiple jobs, JM 
> has to load all submitted JobGraphs from SubmittedJobGraphStore and recover 
> them. Now that the components creating JM will be responsible for the 
> recovery of JobGraphs, JM will be created with submitted/recovered JobGraph, 
> without the need to load the JobGraph.
> (2) JM should not rely on Akka to listen on the updates of JobStatus and 
> Execution.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FLINK-4408) Submit Job and setup ExecutionGraph

[Xiaogang Shi (JIRA)]

[ 
https://issues.apache.org/jira/browse/FLINK-4408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15434052#comment-15434052
 ] 

Xiaogang Shi commented on FLINK-4408:
-

I think it's okay to pull the logics about leadership out of the JobManager and 
let the component holding the JobManager to take care of it.

But I think the JobManager still needs to worry about the switches.  The 
JobManager still need the function to submit/execute the job when it is started 
by the component holding it (to be specific, the `submitJob` function in old 
JobManager).  The only difference made by pulling the logics out is that the 
function will be called by the component holding the JobManager but not the 
JobManager itself. 

If I understand your comment correctly, i think we should revise the 
implementation in Flink-4400 to let JobManager not care about leadership. But 
the JobManager still needs to implement the methods to start and cancel the 
execution, which are implemented in this JIRA.

> Submit Job and setup ExecutionGraph
> ---
>
> Key: FLINK-4408
> URL: https://issues.apache.org/jira/browse/FLINK-4408
> Project: Flink
>  Issue Type: Sub-task
>  Components: Cluster Management
>Reporter: Xiaogang Shi
>Assignee: Xiaogang Shi
>
> Once granted the leadership, JM will start to execute the job.
> Most code remains the same except that 
> (1) In old implementation where JM manages the execution of multiple jobs, JM 
> has to load all submitted JobGraphs from SubmittedJobGraphStore and recover 
> them. Now that the components creating JM will be responsible for the 
> recovery of JobGraphs, JM will be created with submitted/recovered JobGraph, 
> without the need to load the JobGraph.
> (2) JM should not rely on Akka to listen on the updates of JobStatus and 
> Execution.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FLINK-4408) Submit Job and setup ExecutionGraph

[Stephan Ewen (JIRA)]

[ 
https://issues.apache.org/jira/browse/FLINK-4408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15433387#comment-15433387
 ] 

Stephan Ewen commented on FLINK-4408:
-

I would actually like to pull this logic out of the JobManager, if possible. 
Once a JobManager runs, it should assume it has leadership.

The component that holds the JobManager would start the JobManager once it was 
granted leadership and would stop/suspend the JobManager once it looses 
leadership.

That way, the JobManager needs not worry about switching between active/not 
active phase, and about picking up new checkpoints once it becomes leader.

> Submit Job and setup ExecutionGraph
> ---
>
> Key: FLINK-4408
> URL: https://issues.apache.org/jira/browse/FLINK-4408
> Project: Flink
>  Issue Type: Sub-task
>  Components: Cluster Management
>Reporter: Xiaogang Shi
>Assignee: Xiaogang Shi
>
> Once granted the leadership, JM will start to execute the job.
> Most code remains the same except that 
> (1) In old implementation where JM manages the execution of multiple jobs, JM 
> has to load all submitted JobGraphs from SubmittedJobGraphStore and recover 
> them. Now that the components creating JM will be responsible for the 
> recovery of JobGraphs, JM will be created with submitted/recovered JobGraph, 
> without the need to load the JobGraph.
> (2) JM should not rely on Akka to listen on the updates of JobStatus and 
> Execution.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)