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

Varun Saxena commented on YARN-6323:
------------------------------------

bq. this is very hard to enforce it from RM. RM can't differentiate between 
recovered apps and newly submitted apps. 
Yeah, we will have to write code to ensure this happens i.e. store a flag in 
state store (non-existence of which indicates data being written to v1). Just 
wanted to point out another possibility if we wanted to ensure incomplete app 
data does not exist. 
However, as I said this approach has the drawback that we may lose data from v1 
if user decides to not take up v2 and its unlikely to be a user scenario too, 
so I do not suggest following this approach.

> Rolling upgrade/config change is broken on timeline v2. 
> --------------------------------------------------------
>
>                 Key: YARN-6323
>                 URL: https://issues.apache.org/jira/browse/YARN-6323
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: timelineserver
>            Reporter: Li Lu
>            Assignee: Vrushali C
>              Labels: yarn-5355-merge-blocker
>         Attachments: YARN-6323.001.patch
>
>
> Found this issue when deploying on real clusters. If there are apps running 
> when we enable timeline v2 (with work preserving restart enabled), node 
> managers will fail to start due to missing app context data. We should 
> probably assign some default names to these "left over" apps. I believe it's 
> suboptimal to let users clean up the whole cluster before enabling timeline 
> v2. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org

Reply via email to