[ 
https://issues.apache.org/jira/browse/HDFS-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jakob Homan updated HDFS-1080:
------------------------------

    Attachment: HDFS-1080-trunk.patch

Patch for trunk.  Exactly the same as the 20 patch, which we've tested manually 
extensively here.  This code is buried quite deep in the guts of the secondary 
namenode; I think a new unit test isn't feasible here, without a serious, 
potentially destabilizing refactor.  I'd like to go ahead without one.

This issue occurs, and prevents the 2ndNN from functioning correctly, when a 
machine is running on a secure cluster and using IP aliasing to run as a 
different host than is returned from getLocalHost.  The NN will attempt to 
connect to the local host (say 192.168.0.1) rather than the alias (say 
secure-2nn), and this will fail the Kerberized SSL authentication and prevent 
the merged image from being downloaded.

> SecondaryNameNode image transfer should use the defined http address rather 
> than local ip address
> -------------------------------------------------------------------------------------------------
>
>                 Key: HDFS-1080
>                 URL: https://issues.apache.org/jira/browse/HDFS-1080
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: name-node
>            Reporter: Jakob Homan
>            Assignee: Jakob Homan
>         Attachments: HDFS-1080-trunk.patch, HDFS-1080-Y20.patch
>
>
> Currently when telling the NN where to get the merged image, SNN uses 
> getLocalHost.getAddr(), which may not return the correct ip addr.  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to