Hadoop HDFS
  1. Hadoop HDFS
  2. HDFS-2264

NamenodeProtocol has the wrong value for clientPrincipal in KerberosInfo annotation

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.2-alpha
    • Fix Version/s: 2.0.3-alpha, 1.3.0
    • Component/s: namenode
    • Labels:
      None

      Description

      The @KerberosInfo annotation specifies the expected server and client principals for a given protocol in order to look up the correct principal name from the config. The NamenodeProtocol has the wrong value for the client config key. This wasn't noticed because most setups actually use the same value for for both the NN and 2NN principals (hdfs/_HOST@REALM), in which the _HOST part gets replaced at run-time. This bug therefore only manifests itself on secure setups which explicitly specify the NN and 2NN principals.

      1. HDFS-2264.b1.patch
        6 kB
        Jing Zhao
      2. HDFS-2264.patch
        5 kB
        Aaron T. Myers
      3. HDFS-2264.patch
        5 kB
        Aaron T. Myers
      4. HDFS-2264.r1.diff
        0.8 kB
        Harsh J

        Issue Links

          Activity

          Hide
          Harsh J added a comment -

          clientPrincipal ought to use the SNN config.

          Show
          Harsh J added a comment - clientPrincipal ought to use the SNN config.
          Hide
          Jitendra Nath Pandey added a comment -

          NamenodeProtocol is also used by Balancer. If we put SNN config in clientPrincipal, we will be forced to run Balancer with SNN principal. An alternative fix could be to use protocolAcl.

          Show
          Jitendra Nath Pandey added a comment - NamenodeProtocol is also used by Balancer. If we put SNN config in clientPrincipal, we will be forced to run Balancer with SNN principal. An alternative fix could be to use protocolAcl.
          Hide
          Aaron T. Myers added a comment -

          Good point, Jitendra.

          I notice, however, that the balancer only appears to use the versionRequest, getBlockKeys, and getBlocks methods of the NamenodeProtocol. Of these, I believe the 2NN only uses versionRequest. Might it make sense, then, to move the getBlockKeys and getBlocks methods out of NamenodeProtocol and add a new protocol interface, perhaps BalancerProtocol?

          It seems to me now that getBlockKeys and getBlocks should have never been added to NamenodeProtocol in the first place. At least, the comment at the top of NamenodeProtocol is incorrect with those methods in there:

          /*****************************************************************************
           * Protocol that a secondary NameNode uses to communicate with the NameNode.
           * It's used to get part of the name node state
           *****************************************************************************/
          
          Show
          Aaron T. Myers added a comment - Good point, Jitendra. I notice, however, that the balancer only appears to use the versionRequest , getBlockKeys , and getBlocks methods of the NamenodeProtocol . Of these, I believe the 2NN only uses versionRequest . Might it make sense, then, to move the getBlockKeys and getBlocks methods out of NamenodeProtocol and add a new protocol interface, perhaps BalancerProtocol ? It seems to me now that getBlockKeys and getBlocks should have never been added to NamenodeProtocol in the first place. At least, the comment at the top of NamenodeProtocol is incorrect with those methods in there: /***************************************************************************** * Protocol that a secondary NameNode uses to communicate with the NameNode. * It's used to get part of the name node state *****************************************************************************/
          Hide
          Jitendra Nath Pandey added a comment -

          I missed to mention earlier that Checkpointer and BackupNode are also using this protocol. Although, it is reasonable that SNN and Balancer should use different protocols but we should not add different protocols for each of these. Protocol Acls solve this issue, and will allow different principals for different clients talking NamenodeProtocol to the namenode.

          Show
          Jitendra Nath Pandey added a comment - I missed to mention earlier that Checkpointer and BackupNode are also using this protocol. Although, it is reasonable that SNN and Balancer should use different protocols but we should not add different protocols for each of these. Protocol Acls solve this issue, and will allow different principals for different clients talking NamenodeProtocol to the namenode.
          Hide
          Harsh J added a comment -

          Thanks Jitendra Nath Pandey and Aaron T. Myers, so since BN/CN are not available on the 0.20 branch, can we introduce changes that split out balancer methods to its own protocol and then applies separated configs to namenode protocol and balancer protocols for their individual principals? I can open a new JIRA for the proto split if this is OK.

          Also, its highly unlikely that more than 1 of SNN/BN/CN run on the same node, so a generic 'checkpoint'-ish configuration can also make sense here, which all three nodes can share.

          The other, last way is as you propose, to get rid of the clientPrincipal altogether and use only acls.

          I feel going with a split + separated config for nodes + balancer would be a good way, thoughts?

          Show
          Harsh J added a comment - Thanks Jitendra Nath Pandey and Aaron T. Myers , so since BN/CN are not available on the 0.20 branch, can we introduce changes that split out balancer methods to its own protocol and then applies separated configs to namenode protocol and balancer protocols for their individual principals? I can open a new JIRA for the proto split if this is OK. Also, its highly unlikely that more than 1 of SNN/BN/CN run on the same node, so a generic 'checkpoint'-ish configuration can also make sense here, which all three nodes can share. The other, last way is as you propose, to get rid of the clientPrincipal altogether and use only acls. I feel going with a split + separated config for nodes + balancer would be a good way, thoughts?
          Hide
          Aaron T. Myers added a comment -

          Hey Harsh, that seems like a fine plan to me.

          Show
          Aaron T. Myers added a comment - Hey Harsh, that seems like a fine plan to me.
          Hide
          Jitendra Nath Pandey added a comment -

          In the context of HA, BN should be using same principal as the primary namenode, because on a failover, it becomes the primary. Therefore NamenodeProtocol must allow the principal of the primary as well.

          > since BN/CN are not available on the 0.20 branch, can we introduce changes that split out balancer methods to its
          > own protocol and then applies separated configs to namenode protocol and balancer protocols for their individual
          > principals? I can open a new JIRA for the proto split if this is OK.
          OK for the jira, but I will recommend to first do that in trunk. It will probably be an incompatible change, so not really recommended for 20.

          Show
          Jitendra Nath Pandey added a comment - In the context of HA, BN should be using same principal as the primary namenode, because on a failover, it becomes the primary. Therefore NamenodeProtocol must allow the principal of the primary as well. > since BN/CN are not available on the 0.20 branch, can we introduce changes that split out balancer methods to its > own protocol and then applies separated configs to namenode protocol and balancer protocols for their individual > principals? I can open a new JIRA for the proto split if this is OK. OK for the jira, but I will recommend to first do that in trunk. It will probably be an incompatible change, so not really recommended for 20.
          Hide
          Aaron T. Myers added a comment -

          In the context of HA, BN should be using same principal as the primary namenode, because on a failover, it becomes the primary.

          When you say "use the same principal", do you mean the same configured value of "dfs.namenode.kerberos.principal" ? Or literally the same Kerberos principal, e.g. "hdfs/host1.foo.bar.com@BAR.COM" ?

          Show
          Aaron T. Myers added a comment - In the context of HA, BN should be using same principal as the primary namenode, because on a failover, it becomes the primary. When you say "use the same principal", do you mean the same configured value of "dfs.namenode.kerberos.principal" ? Or literally the same Kerberos principal, e.g. "hdfs/host1.foo.bar.com@BAR.COM" ?
          Hide
          Jitendra Nath Pandey added a comment -

          I think for vip failover same kerberos principal like hdfs/vip-hostname@BAR.COM should be used. For some other failover scheme a different principal may work but using same principal except for the hostname as in hdfs/_HOST@BAR.COM, will be simpler.

          Show
          Jitendra Nath Pandey added a comment - I think for vip failover same kerberos principal like hdfs/vip-hostname@BAR.COM should be used. For some other failover scheme a different principal may work but using same principal except for the hostname as in hdfs/_HOST@BAR.COM, will be simpler.
          Hide
          Aaron T. Myers added a comment -

          Yep, I think we're in agreement then. Thanks, Jitendra.

          Show
          Aaron T. Myers added a comment - Yep, I think we're in agreement then. Thanks, Jitendra.
          Hide
          Jitendra Nath Pandey added a comment -

          I think in my previous comment, I digressed and went a bit tangential into HA.

          The clients also use this key to figure out server principal. Now in case of a failover BN takes over as primary, the clients will continue to use this key to figure out server principal and that should work. Therefore it seems to me that BN should also use the same config key. Is that a valid scenario?

          Show
          Jitendra Nath Pandey added a comment - I think in my previous comment, I digressed and went a bit tangential into HA. The clients also use this key to figure out server principal. Now in case of a failover BN takes over as primary, the clients will continue to use this key to figure out server principal and that should work. Therefore it seems to me that BN should also use the same config key. Is that a valid scenario?
          Hide
          Aaron T. Myers added a comment - - edited

          Hey Jitendra, sorry for forgetting about this JIRA for so long (almost exactly a year!)

          I just encountered this issue again in a user's cluster. My new thinking is that we should just remove the expected client principal from the NamenodeProtocol entirely. I think this makes sense since the 2NN, SBN, BN, and balancer all potentially use this interface, so there's no single client principal that could reasonably be expected. The balancer, in particular, should be able to be run from any node, even one not running a daemon at all.

          I think to do what I propose here all we have to do is remove the clientPrincipal parameter from the SecurityInfo annotation on the NamenodeProtocol, and make sure that all of the methods exposed by this interface definitely check for super user privileges. I think most of them do, but we should ensure that they all do.

          How does this sound to you?

          Show
          Aaron T. Myers added a comment - - edited Hey Jitendra, sorry for forgetting about this JIRA for so long (almost exactly a year!) I just encountered this issue again in a user's cluster. My new thinking is that we should just remove the expected client principal from the NamenodeProtocol entirely. I think this makes sense since the 2NN, SBN, BN, and balancer all potentially use this interface, so there's no single client principal that could reasonably be expected. The balancer, in particular, should be able to be run from any node, even one not running a daemon at all. I think to do what I propose here all we have to do is remove the clientPrincipal parameter from the SecurityInfo annotation on the NamenodeProtocol, and make sure that all of the methods exposed by this interface definitely check for super user privileges. I think most of them do, but we should ensure that they all do. How does this sound to you?
          Hide
          Jitendra Nath Pandey added a comment -

          Hey Aaron, sorry for taking this long before responding. I think the general issue here is that for these protocols, annotation for a single client is too restrictive. We should support being able to configure multiple clients, or a group.

          Show
          Jitendra Nath Pandey added a comment - Hey Aaron, sorry for taking this long before responding. I think the general issue here is that for these protocols, annotation for a single client is too restrictive. We should support being able to configure multiple clients, or a group.
          Hide
          Aaron T. Myers added a comment -

          Hi Jitendra, I think that long term it may make sense to extensively change the protocol authorization system to support multiple expected client principal names and/or groups, but a change like that seems like overkill to address this particular issue.

          I think that being able to configure multiple expected client principal names in the annotation still doesn't address the issue of the balancer, which could conceivably be run from any node in the cluster. All that should be required to run the balancer, and hence access this interface, is super user privileges, hence my suggestion to remove the clientPrincipal annotation entirely from the NamenodeProtocol, and just ensure that all the operations check for super user privileges. Would you be OK with that solution for this particular issue?

          Show
          Aaron T. Myers added a comment - Hi Jitendra, I think that long term it may make sense to extensively change the protocol authorization system to support multiple expected client principal names and/or groups, but a change like that seems like overkill to address this particular issue. I think that being able to configure multiple expected client principal names in the annotation still doesn't address the issue of the balancer, which could conceivably be run from any node in the cluster. All that should be required to run the balancer, and hence access this interface, is super user privileges, hence my suggestion to remove the clientPrincipal annotation entirely from the NamenodeProtocol, and just ensure that all the operations check for super user privileges. Would you be OK with that solution for this particular issue?
          Hide
          Aaron T. Myers added a comment -

          Hi Jitendra, does the above approach sound OK to you?

          Show
          Aaron T. Myers added a comment - Hi Jitendra, does the above approach sound OK to you?
          Hide
          Jitendra Nath Pandey added a comment -

          I think that is fine. What do you think about configuring ACL for this protocol, where only superuser group is allowed?

          Show
          Jitendra Nath Pandey added a comment - I think that is fine. What do you think about configuring ACL for this protocol, where only superuser group is allowed?
          Hide
          Aaron T. Myers added a comment -

          Here's a patch which addresses the issue by removing the clientPrincipal from the annotation for the NamenodeProtocol and instead adds a superuser check to every method in the NN implemented as part of the NamenodeProtocol. I also took the liberty of adding a few missing checks for HA operation categories that I noticed.

          I tested this patch by running the balancer from a different host than the NN on a 2 node cluster where the HOST macro _wasn't being used for the NN or 2NN, i.e. the full Kerberos principal was being specified. Everything worked as expected. I also confirmed that the 2NN still successfully checkpoints as expected.

          Show
          Aaron T. Myers added a comment - Here's a patch which addresses the issue by removing the clientPrincipal from the annotation for the NamenodeProtocol and instead adds a superuser check to every method in the NN implemented as part of the NamenodeProtocol. I also took the liberty of adding a few missing checks for HA operation categories that I noticed. I tested this patch by running the balancer from a different host than the NN on a 2 node cluster where the HOST macro _wasn't being used for the NN or 2NN, i.e. the full Kerberos principal was being specified. Everything worked as expected. I also confirmed that the 2NN still successfully checkpoints as expected.
          Hide
          Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12559800/HDFS-2264.patch
          against trunk revision .

          +1 @author. The patch does not contain any @author tags.

          -1 tests included. The patch doesn't appear to include any new or modified tests.
          Please justify why no new tests are needed for this patch.
          Also please list what manual steps were performed to verify this patch.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 eclipse:eclipse. The patch built with eclipse:eclipse.

          +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          -1 core tests. The patch failed these unit tests in hadoop-hdfs-project/hadoop-hdfs:

          org.apache.hadoop.hdfs.server.namenode.TestEditLog

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: https://builds.apache.org/job/PreCommit-HDFS-Build/3619//testReport/
          Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/3619//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12559800/HDFS-2264.patch against trunk revision . +1 @author . The patch does not contain any @author tags. -1 tests included . The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. +1 javac . The applied patch does not increase the total number of javac compiler warnings. +1 javadoc . The javadoc tool did not generate any warning messages. +1 eclipse:eclipse . The patch built with eclipse:eclipse. +1 findbugs . The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit . The applied patch does not increase the total number of release audit warnings. -1 core tests . The patch failed these unit tests in hadoop-hdfs-project/hadoop-hdfs: org.apache.hadoop.hdfs.server.namenode.TestEditLog +1 contrib tests . The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-HDFS-Build/3619//testReport/ Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/3619//console This message is automatically generated.
          Hide
          Daryn Sharp added a comment -

          I think the change generally looks ok if the test failure is unrelated, but I'd suggest splitting out the HA changes or redefining the jira.

          Show
          Daryn Sharp added a comment - I think the change generally looks ok if the test failure is unrelated, but I'd suggest splitting out the HA changes or redefining the jira.
          Hide
          Aaron T. Myers added a comment -

          Thanks a lot for taking a look, Daryn. Though I'm pretty sure the HA changes would be no-ops, it seems fine to me to break out that change. Here's a patch which removes those.

          Show
          Aaron T. Myers added a comment - Thanks a lot for taking a look, Daryn. Though I'm pretty sure the HA changes would be no-ops, it seems fine to me to break out that change. Here's a patch which removes those.
          Hide
          Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12559903/HDFS-2264.patch
          against trunk revision .

          +1 @author. The patch does not contain any @author tags.

          -1 tests included. The patch doesn't appear to include any new or modified tests.
          Please justify why no new tests are needed for this patch.
          Also please list what manual steps were performed to verify this patch.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 eclipse:eclipse. The patch built with eclipse:eclipse.

          +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          +1 core tests. The patch passed unit tests in hadoop-hdfs-project/hadoop-hdfs.

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: https://builds.apache.org/job/PreCommit-HDFS-Build/3620//testReport/
          Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/3620//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12559903/HDFS-2264.patch against trunk revision . +1 @author . The patch does not contain any @author tags. -1 tests included . The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. +1 javac . The applied patch does not increase the total number of javac compiler warnings. +1 javadoc . The javadoc tool did not generate any warning messages. +1 eclipse:eclipse . The patch built with eclipse:eclipse. +1 findbugs . The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit . The applied patch does not increase the total number of release audit warnings. +1 core tests . The patch passed unit tests in hadoop-hdfs-project/hadoop-hdfs. +1 contrib tests . The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-HDFS-Build/3620//testReport/ Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/3620//console This message is automatically generated.
          Hide
          Aaron T. Myers added a comment -

          The test failure was unrelated and was fixed by HDFS-4282. No tests are included in this patch since Kerberos is required to test this stuff out.

          Daryn, how does this patch look now?

          Show
          Aaron T. Myers added a comment - The test failure was unrelated and was fixed by HDFS-4282 . No tests are included in this patch since Kerberos is required to test this stuff out. Daryn, how does this patch look now?
          Hide
          Todd Lipcon added a comment -

          Patch looks good to me. +1

          Show
          Todd Lipcon added a comment - Patch looks good to me. +1
          Hide
          Aaron T. Myers added a comment -

          Thanks a lot for the review, Todd. I've just committed this to trunk and branch-2.

          Thanks also to Jitendra, Harsh, and Daryn for the discussion.

          Show
          Aaron T. Myers added a comment - Thanks a lot for the review, Todd. I've just committed this to trunk and branch-2. Thanks also to Jitendra, Harsh, and Daryn for the discussion.
          Hide
          Hudson added a comment -

          Integrated in Hadoop-trunk-Commit #3109 (See https://builds.apache.org/job/Hadoop-trunk-Commit/3109/)
          HDFS-2264. NamenodeProtocol has the wrong value for clientPrincipal in KerberosInfo annotation. Contributed by Aaron T. Myers. (Revision 1419949)

          Result = SUCCESS
          atm : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1419949
          Files :

          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/NameNodeRpcServer.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/protocol/NamenodeProtocol.java
          Show
          Hudson added a comment - Integrated in Hadoop-trunk-Commit #3109 (See https://builds.apache.org/job/Hadoop-trunk-Commit/3109/ ) HDFS-2264 . NamenodeProtocol has the wrong value for clientPrincipal in KerberosInfo annotation. Contributed by Aaron T. Myers. (Revision 1419949) Result = SUCCESS atm : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1419949 Files : /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/NameNodeRpcServer.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/protocol/NamenodeProtocol.java
          Hide
          Hudson added a comment -

          Integrated in Hadoop-Yarn-trunk #62 (See https://builds.apache.org/job/Hadoop-Yarn-trunk/62/)
          HDFS-2264. NamenodeProtocol has the wrong value for clientPrincipal in KerberosInfo annotation. Contributed by Aaron T. Myers. (Revision 1419949)

          Result = FAILURE
          atm : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1419949
          Files :

          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/NameNodeRpcServer.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/protocol/NamenodeProtocol.java
          Show
          Hudson added a comment - Integrated in Hadoop-Yarn-trunk #62 (See https://builds.apache.org/job/Hadoop-Yarn-trunk/62/ ) HDFS-2264 . NamenodeProtocol has the wrong value for clientPrincipal in KerberosInfo annotation. Contributed by Aaron T. Myers. (Revision 1419949) Result = FAILURE atm : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1419949 Files : /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/NameNodeRpcServer.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/protocol/NamenodeProtocol.java
          Hide
          Hudson added a comment -

          Integrated in Hadoop-Hdfs-trunk #1251 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk/1251/)
          HDFS-2264. NamenodeProtocol has the wrong value for clientPrincipal in KerberosInfo annotation. Contributed by Aaron T. Myers. (Revision 1419949)

          Result = FAILURE
          atm : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1419949
          Files :

          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/NameNodeRpcServer.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/protocol/NamenodeProtocol.java
          Show
          Hudson added a comment - Integrated in Hadoop-Hdfs-trunk #1251 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk/1251/ ) HDFS-2264 . NamenodeProtocol has the wrong value for clientPrincipal in KerberosInfo annotation. Contributed by Aaron T. Myers. (Revision 1419949) Result = FAILURE atm : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1419949 Files : /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/NameNodeRpcServer.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/protocol/NamenodeProtocol.java
          Hide
          Hudson added a comment -

          Integrated in Hadoop-Mapreduce-trunk #1282 (See https://builds.apache.org/job/Hadoop-Mapreduce-trunk/1282/)
          HDFS-2264. NamenodeProtocol has the wrong value for clientPrincipal in KerberosInfo annotation. Contributed by Aaron T. Myers. (Revision 1419949)

          Result = SUCCESS
          atm : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1419949
          Files :

          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/NameNodeRpcServer.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/protocol/NamenodeProtocol.java
          Show
          Hudson added a comment - Integrated in Hadoop-Mapreduce-trunk #1282 (See https://builds.apache.org/job/Hadoop-Mapreduce-trunk/1282/ ) HDFS-2264 . NamenodeProtocol has the wrong value for clientPrincipal in KerberosInfo annotation. Contributed by Aaron T. Myers. (Revision 1419949) Result = SUCCESS atm : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1419949 Files : /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/NameNodeRpcServer.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/protocol/NamenodeProtocol.java
          Hide
          Jing Zhao added a comment -

          Backport to branch-1.

          Show
          Jing Zhao added a comment - Backport to branch-1.
          Hide
          Jing Zhao added a comment -

          The backported patch passed all the unit tests in my local machine, except TestStorageRestore which also failed without the patch.

          Show
          Jing Zhao added a comment - The backported patch passed all the unit tests in my local machine, except TestStorageRestore which also failed without the patch.
          Hide
          Brandon Li added a comment -

          +1 for the branch-1 patch.

          Show
          Brandon Li added a comment - +1 for the branch-1 patch.
          Hide
          Jing Zhao added a comment -

          Thanks for reviewing the backported patch, Brandon! I've merged the patch to branch-1.

          Show
          Jing Zhao added a comment - Thanks for reviewing the backported patch, Brandon! I've merged the patch to branch-1.

            People

            • Assignee:
              Aaron T. Myers
              Reporter:
              Aaron T. Myers
            • Votes:
              0 Vote for this issue
              Watchers:
              18 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development