[jira] [Commented] (FLINK-3299) Remove ApplicationID from Environment

["Gyula Fora (JIRA)" <ji...@apache.org>]

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

Gyula Fora commented on FLINK-3299:
-----------------------------------

I am not sure if I would rush to remove it in fact I would probably expose it in multiple places (command line 'list' and web frontend). I think once people start using savepoints it will be necessary to have an identifier across different runs so that different jobs don't get entangled.

Some arguments why I would keep it:
-We could use it as a safeguard to not allow executing multiple jobs at the same time from the same savepoint (we might want or not want this, but this could surely break some checkpointing logic)
-It is a convenient way for users to identify Applications that they have restarted multiple times from savepoints
-It is a convenient way of keeping state and other job metadata in one place so that it is easy to find for users if they want 
-I would also make the FileStateBackend create checkpoint directories based on the app id instead of the job id (makes manual cleanup possible easily)

The question of course is whether we feel confident in this ID for the future.

> Remove ApplicationID from Environment
> -------------------------------------
>
>                 Key: FLINK-3299
>                 URL: https://issues.apache.org/jira/browse/FLINK-3299
>             Project: Flink
>          Issue Type: Improvement
>            Reporter: Ufuk Celebi
>            Assignee: Ufuk Celebi
>             Fix For: 1.0.0
>
>
> {{ApplicationID}} is used to identify an application across many job submissions (for example after restoring from a savepoint). This is currently exposed in the {{Environment}}, which might be unnecessary.
> State backends, which need the ID can generate it themselves and store it as part of their state handle.
> This has to be checked with the DB state backend, which currently uses this.



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