[
https://issues.apache.org/jira/browse/HDFS-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13086567#comment-13086567
]
Aaron T. Myers commented on HDFS-2264:
--------------------------------------
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:
{code}
/*****************************************************************************
* Protocol that a secondary NameNode uses to communicate with the NameNode.
* It's used to get part of the name node state
*****************************************************************************/
{code}
> NamenodeProtocol has the wrong value for clientPrincipal in KerberosInfo
> annotation
> -----------------------------------------------------------------------------------
>
> Key: HDFS-2264
> URL: https://issues.apache.org/jira/browse/HDFS-2264
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: name-node
> Affects Versions: 0.23.0
> Reporter: Aaron T. Myers
> Assignee: Harsh J
> Fix For: 0.23.0
>
> Attachments: HDFS-2264.r1.diff
>
>
> 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.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
