[
https://issues.apache.org/jira/browse/HDFS-2904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13211020#comment-13211020
]
Mahadev konar commented on HDFS-2904:
-------------------------------------
bq. I was thinking it wouldn't, necessarily. Our current client side code has
no notion of being able to list all of the potential NNs, only of being able to
get a proxy to the active one. With ZK, you wouldn't necessarily have a list of
the standbys. For example, it might be that when you submit the job, the SBN
happened to be down for maintenance. Then when you bring it back up and do a
failover to it, it wouldn't have been listed for DT renewal.
I was thinking more along the lines of all the NN's would be listed as a
persistent nodes on ZK (unless NN's unregister explicitly), so you would
probably be able to get a list of NN's even when some are down, but again I am
not an expert on what is going on in HA. I will let you folks decide on the
right model. As far as MR is concerned I think it should be ok to deploy all NN
configs on the RM as a stop gap solution. Longer term we should be able to get
rid of that.
> HA: Client support for getting delegation tokens to an HA cluster
> -----------------------------------------------------------------
>
> Key: HDFS-2904
> URL: https://issues.apache.org/jira/browse/HDFS-2904
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: ha, hdfs client, name-node, security
> Affects Versions: HA branch (HDFS-1623)
> Reporter: Todd Lipcon
> Assignee: Todd Lipcon
> Priority: Critical
> Attachments: hdfs-2904.txt, hdfs-2904.txt, hdfs-2904.txt, test-dt.sh
>
>
> Currently we have server-side support for delegation tokens in HA, and some
> tests to verify it, but the client throws NPEs when trying to fetch a DT.
> This is because the cluster doesn't have a single hostname, but instead a
> logical nameservice name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
