[jira] Commented: (HADOOP-5891) If dfs.http.address is default, SecondaryNameNode can't find NameNode

["Steve Loughran (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HADOOP-5891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12712083#action_12712083 ] 

Steve Loughran commented on HADOOP-5891:
----------------------------------------

this whole problem of bootstrapping a cluster where machines don't know who they are is pretty brittle right now. In an ideal world, even the NN would be able to work out its name/address and share it with the rest, but failing that, having everything else work out the details by asking the NN would be handy. It would also be good if everything provided (in the same process and via JMX) a list of (service, address, port) for all the different things that the node runs. I try to reverse engineer that, but it adds more scheduling problems (don't start the downstream nodes until the NN and JT are live), and for some reason jetty comes up bonded to 0:0:0:0:0:1 on one machine, which is particularly irritating.

so: +1 to this, I can see the BackupNode having the same problem on scaled up, as it needs to know both the NN and 2N addresses (note addresses, not hostnames. 

Maybe we should open this up to a general "nodes to come up better on an under-configured network" bugrep which those of us who do underconfigure their networks can deal with. 



> If dfs.http.address is default, SecondaryNameNode can't find NameNode
> ---------------------------------------------------------------------
>
>                 Key: HADOOP-5891
>                 URL: https://issues.apache.org/jira/browse/HADOOP-5891
>             Project: Hadoop Core
>          Issue Type: Bug
>          Components: dfs
>            Reporter: Todd Lipcon
>            Assignee: Todd Lipcon
>         Attachments: hadoop-5891.txt
>
>
> As detailed in this blog post:
> http://www.cloudera.com/blog/2009/02/10/multi-host-secondarynamenode-configuration/
> if dfs.http.address is not configured, and the 2NN is a different machine from the NN, the 2NN fails to connect.
> In SecondaryNameNode.getInfoServer, the 2NN should notice a "0.0.0.0" dfs.http.address and, in that case, pull the hostname out of fs.default.name. This would fix the default configuration to work properly for most users.

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