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

Reply via email to