[
https://issues.apache.org/jira/browse/HDFS-9001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14745770#comment-14745770
]
Aaron T. Myers commented on HDFS-9001:
--------------------------------------
Hey Daniel,
I think this makes sense, thanks very much for the lucid explanation. I think
the really correct thing to do (ignoring backward compatibility concerns) would
be to make fs.defaultFS a client-side config only. It's only for historical
reasons that it's not, in that I believe in the NN we fall back to having the
NN bind to that as its RPC address if no {{rpc-address}} address is actually
configured. We can only change that behavior in a major version, though, so I
don't think we should do that here.
I think the way to go is to fix this JIRA as you propose, and then file a
separate, backward-incompatible JIRA to change the NN (and all admin commands)
to no longer look at fs.defaultFS at all. We'd then only commit that to trunk
(and not branch-2) so it'll show up in Hadoop 3.0.
Does that make sense?
> DFSUtil.getNsServiceRpcUris() can return too many entries in a non-HA,
> non-federated cluster
> --------------------------------------------------------------------------------------------
>
> Key: HDFS-9001
> URL: https://issues.apache.org/jira/browse/HDFS-9001
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: HDFS
> Affects Versions: 2.6.0, 2.7.0, 2.7.1
> Reporter: Daniel Templeton
> Assignee: Daniel Templeton
>
> If defaultFS differs from rpc-address, then DFSUtil.getNsServiceRpcUris()
> will return two entries: one for the [service] RPC address and one for the
> default FS. This behavior violates the expected behavior stated in the
> JavaDoc header.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
