Uploaded image for project: 'Hadoop Common'
  1. Hadoop Common
  2. HADOOP-8209

Add option to relax build-version check for branch-1



    • Improvement
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 1.0.0
    • 1.1.0
    • None
    • None
    • Reviewed


      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.


        1. hadoop-8209.txt
          24 kB
          Eli Collins
        2. hadoop-8209.txt
          25 kB
          Eli Collins
        3. hadoop-8209.txt
          19 kB
          Eli Collins

        Issue Links



              eli Eli Collins
              eli2 Eli Collins
              0 Vote for this issue
              17 Start watching this issue