[
https://issues.apache.org/jira/browse/YARN-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13996610#comment-13996610
]
Zhijie Shen commented on YARN-667:
----------------------------------
bq. do you have sense on how possibility it could happen in 2.X as you are
currently work on ATS?
My understanding is that we may have two 2 possible changes in the future:
1. One is data itself. Say if application has one more state in the future, the
new RM will try to persist it into the history store, while the old history
server or client may not understand it. This should be a common problem with
RMStateStore. This is driven by RM itself.
2. The other is change of the timeline server internal. Say in the near future,
we modified the file structure in FileSystemApplicationHistoryStore to improve
the performance, new FileSystemApplicationHistoryStore may not longer
understand the existing data structure written by old
FileSystemApplicationHistoryStore. However, I think this part should be taken
care of by the timeline server itself.
> Data persisted in RM should be versioned
> ----------------------------------------
>
> Key: YARN-667
> URL: https://issues.apache.org/jira/browse/YARN-667
> Project: Hadoop YARN
> Issue Type: Sub-task
> Affects Versions: 2.0.4-alpha
> Reporter: Siddharth Seth
> Assignee: Junping Du
>
> Includes data persisted for RM restart, NodeManager directory structure and
> the Aggregated Log Format.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
