[
https://issues.apache.org/jira/browse/HDFS-5237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13776568#comment-13776568
]
Colin Patrick McCabe commented on HDFS-5237:
--------------------------------------------
I'm not so sure that we need to remove this, now. If it's heavily used in unit
tests, and also used by end-users in certain configurations, it's going to be
an uphill battle.
Validating it *sounds* like a good idea, but in practice it's going to add up
to failing DN registrations if the reported hostname can't be resolved, which
doesn't seem that friendly. DNS is sometimes unreliable like any other network
service, after all.
Why don't we add some JavaDoc to DatanodeID explaining the reasons why hostName
may in fact not be a real host name?
I also wonder why we need {{DatanodeID#peerHostName}}. It doesn't seem to be
used anywhere, and it definitely muddies the waters in that class.
> Get rid of nodes' registration names
> ------------------------------------
>
> Key: HDFS-5237
> URL: https://issues.apache.org/jira/browse/HDFS-5237
> Project: Hadoop HDFS
> Issue Type: Bug
> Reporter: Junping Du
> Fix For: 3.0.0
>
> Attachments: HDFS-5237.patch
>
>
> Per discussion in HDFS-5208 and may be some other discussions before, Node's
> registration name is pretty confusing and shouldn't be used in production
> environment as topology resolving issues. So we remove related configuration
> dfs.datanode.hostname or its old one "slave.host.name".
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
