[ https://issues.apache.org/jira/browse/HADOOP-8209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13252125#comment-13252125 ]
Sanjay Radia commented on HADOOP-8209: -------------------------------------- * I thought we were focusing on rolling upgrades for Hadoop 2 not Hadoop 1 given that wire compatibility is only in Hadoop 2. * The jira title should be "Add option to relax build-version check for branch-1" > Add option to enable DN and TT rolling upgrades in branch-1 > ----------------------------------------------------------- > > Key: HADOOP-8209 > URL: https://issues.apache.org/jira/browse/HADOOP-8209 > Project: Hadoop Common > Issue Type: Improvement > Affects Versions: 1.0.0 > Reporter: Eli Collins > Assignee: Eli Collins > Attachments: hadoop-8209.txt, hadoop-8209.txt > > > In 1.x DNs currently refuse to connect to NNs if their build *revision* (ie > svn revision) do not match. TTs refuse to connect to JTs if their build > *version* (version, revision, user, and source checksum) do not match. > This prevents rolling upgrades, which is intentional, see the discussion in > HADOOP-5203. The primary motivation in that jira was (1) it's difficult to > guarantee every build on a large cluster got deployed correctly, builds don't > get rolled back to old versions by accident etc, and (2) mixed versions can > lead to execution problems that are hard to debug. > However there are also cases when users know they two builds are compatible, > eg when deploying a new build which contains the same contents as the > previous one, plus a critical security patch that does not affect > compatibility. Currently deploying a 1 line patch requires taking down the > entire cluster (or trying to work around the issue by lying about the build > revision or checksum, yuck). These users would like to be able to perform a > rolling upgrade. > In order to support this, let's add an option that is off by default, but, > when enabled, makes the DN and TT version check just check for an exact > version match (eg "1.0.2") but ignore the build revision (DN) and the source > checksum (TT). Two builds still need to match the major, minor, and point > numbers, but nothing else. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira