[
https://issues.apache.org/jira/browse/YARN-5547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15487715#comment-15487715
]
Chris Douglas commented on YARN-5547:
-------------------------------------
bq. Skipping the container entirely would be very bad. The NM would not recover
it, so it would then stop reporting it in heartbeats and the RM would then
think it is dead/lost, but the container is actually still running, unmonitored
and unkillable by YARN.
Agreed. What we were discussing was making container recovery independent, so
containers using unknown features are not recovered, but failed and killed. The
base case should recover nothing- all containers should be killed and cleaned
up- but the NM should always start. I'm not sure every feature is neatly
classified in the mandatory/optional taxonomy, particularly since many will
depend on the version of the client and RM. It seems simpler (and safer) to
always kill/clean up containers using features the NM doesn't understand.
> NMLeveldbStateStore should be more tolerant of unknown keys
> -----------------------------------------------------------
>
> Key: YARN-5547
> URL: https://issues.apache.org/jira/browse/YARN-5547
> Project: Hadoop YARN
> Issue Type: Improvement
> Components: nodemanager
> Affects Versions: 2.6.0
> Reporter: Jason Lowe
> Assignee: Ajith S
> Attachments: YARN-5547.01.patch
>
>
> Whenever new keys are added to the NM state store it will break rolling
> downgrades because the code will throw if it encounters an unrecognized key.
> If instead it skipped unrecognized keys it could be simpler to continue
> supporting rolling downgrades. We need to define the semantics of
> unrecognized keys when containers and apps are cleaned up, e.g.: we may want
> to delete all keys underneath an app or container directory when it is being
> removed from the state store to prevent leaking unrecognized keys.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
