[
https://issues.apache.org/jira/browse/HADOOP-5891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12712132#action_12712132
]
Todd Lipcon commented on HADOOP-5891:
-------------------------------------
Steve: I agree that service location can be improved across the board. However,
I don't think it's necessarily a good idea to overload the NameNode as a
service name daemon. Personally, I'd prefer to use something like ZooKeeper
here. Obviously there needs to be at least one host that is in a "well-known"
location, which could be configured by default as a "hadoop-zk" hostname which
has multiple A records pointing to all of the ZK nodes.
Anyway, I agree that we should work towards the ideal goal, but I'd like to
have that discussion in a new JIRA. This one is a very simple fix whereas that
one could be pretty significant.
> 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.
