[
https://issues.apache.org/jira/browse/YARN-819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13772993#comment-13772993
]
Robert Parker commented on YARN-819:
------------------------------------
Here are the primary use cases that this change is trying to cover
Scenario 1) Upgrade the Node Managers (NMs) first in a rolling upgrade, then
upgrade the Resoure Manager(RM)
# Config required:
#* yarn.resourcemanager.nodemanager.minimum.version => EqualToRM
#* yarn.nodemanager.resourcemanager.minimum.version => NONE
# The RM will ensure all NM have at least the same version as the RM, therefore
the NMs can be upgraded in a incremental manner.
# In this scenario the RM could precede the NMs for an emergency bug fix by
changing the yarn.resourcemanager.nodemanager.minimum.version config to the
Original RM version
Scenario 2) Upgrade of the RM first then perform a rolling upgrade on the NMs.
# Config required:
#* yarn.resourcemanager.nodemanager.minimum.version => NONE
#* yarn.nodemanager.resourcemanager.minimum.version => EqualToNM
# The NMs will ensure that the RM version at least the same version as the
current NM's version.
Scenario 3) Ensure the RM version is equal the NM version.
# Config required:
#* yarn.resourcemanager.nodemanager.minimum.version => EqualToRM
#* yarn.nodemanager.resourcemanager.minimum.version => EqualToNM
# Since the check is done on both the RM and the NM the versions will have to
be equal.
> ResourceManager and NodeManager should check for a minimum allowed version
> --------------------------------------------------------------------------
>
> Key: YARN-819
> URL: https://issues.apache.org/jira/browse/YARN-819
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: nodemanager, resourcemanager
> Affects Versions: 2.0.4-alpha
> Reporter: Robert Parker
> Assignee: Robert Parker
> Attachments: YARN-819-1.patch, YARN-819-2.patch
>
>
> Our use case is during upgrade on a large cluster several NodeManagers may
> not restart with the new version. Once the RM comes back up the NodeManager
> will re-register without issue to the RM.
> The NM should report the version the RM. The RM should have a configuration
> to disallow the check (default), equal to the RM (to prevent config change
> for each release), equal to or greater than RM (to allow NM upgrades), and
> finally an explicit version or version range.
> The RM should also have an configuration on how to treat the mismatch:
> REJECT, or REBOOT the NM.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
