[
https://issues.apache.org/jira/browse/YARN-5630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15477825#comment-15477825
]
Jason Lowe commented on YARN-5630:
----------------------------------
We could do the refcounting thing, but what I'm thinking is that we don't need
to mess with the schema version key at all. The presence of a container
version key already acts like a new schema version since it causes the old NM
to not survive startup. That's exactly what incrementing the schema version
would do, so there's not a lot of net benefit by going through the complicated
refcount incr/decr schema thing. Either a container version key is present and
prevents the old NM from starting up or no container version key exists and the
old NM can startup like before.
Is there a compelling reason to bother updating the schema version given the
presence of a container version key (or really any unrecognized container key)
will prevent the old software from starting?
> NM fails to start after downgrade from 2.8 to 2.7
> -------------------------------------------------
>
> Key: YARN-5630
> URL: https://issues.apache.org/jira/browse/YARN-5630
> Project: Hadoop YARN
> Issue Type: Bug
> Components: nodemanager
> Reporter: Jason Lowe
> Assignee: Jason Lowe
> Priority: Blocker
> Attachments: YARN-5630.001.patch, YARN-5630.002.patch
>
>
> A downgrade from 2.8 to 2.7 causes nodemanagers to fail to start due to an
> unrecognized "version" container key on startup. This breaks downgrades from
> 2.8 to 2.7.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
