[
https://issues.apache.org/jira/browse/YARN-2770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14191174#comment-14191174
]
Zhijie Shen commented on YARN-2770:
-----------------------------------
bq. SecurityUtil#getServerPrincipal may be useful.
bq. Let's make sure the renewer name mangling imitates MR JobClient, it is easy
to get this wrong.
I think we should use HadoopKerberosName#getShortName
(AbstractDelegationTokenSecretManager is using it as well) and RM_Principal
(which should be there in secure mode) to get the RM daemon user, and
HadoopKerberosName will automatically handle auth_to_local if we need to map
the auth name to the real operating system name.
bq. It'll be great to also test separately that renewal can work fine when
https is enabled.
I've verified it will work with SSL. BTW, SystemMetricsPublisher works fine
with SSL too. To make it work, we must make sure RM have seen the proper
configuration for SSL and the truststore.
bq. the same DelegationTokenAuthenticatedURL is instantiated multiple times, is
it possible to store it as a variable ?
It's probably okay to reuse DelegationTokenAuthenticatedURL. However, I'd like
to construct one for each request to isolate the possible resource sharing,
preventing introducing potential bugs. Actually Jersey client also construct a
new URL for each request. It won't be a big overhead, as it doesn't deeply
construct something.
bq. similarly for the timeline client instantiation.
I'm not sure, but guess you're talking about TokenRenewer. Actually I'm
following the way that RMDelegationTokenIdentifier does. If we don't construct
the client per call, we need to make it a service, and have separate stage for
init/start and stop. It may complex the change. Please let me know if you want
this change.
bq. We may replace the token after renew is really succeeded.
According to the design of DelegationTokenAuthenticatedURL, I need to put the
DT into the current DelegationTokenAuthenticatedURL.Token, which will be
fetched internally to do the corresponding operations. So to renew a given DT,
I need to set DT there. However, if it already cached there, the client can
skip the set step.
Otherwise, I've addressed the remaining comments. Thanks Jian and Vinod!
> Timeline delegation tokens need to be automatically renewed by the RM
> ---------------------------------------------------------------------
>
> Key: YARN-2770
> URL: https://issues.apache.org/jira/browse/YARN-2770
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: timelineserver
> Affects Versions: 2.5.0
> Reporter: Zhijie Shen
> Assignee: Zhijie Shen
> Priority: Critical
> Attachments: YARN-2770.1.patch
>
>
> YarnClient will automatically grab a timeline DT for the application and pass
> it to the app AM. Now the timeline DT renew is still dummy. If an app is
> running for more than 24h (default DT expiry time), the app AM is no longer
> able to use the expired DT to communicate with the timeline server. Since RM
> will cache the credentials of each app, and renew the DTs for the running
> app. We should provider renew hooks similar to what HDFS DT has for RM, and
> set RM user as the renewer when grabbing the timeline DT.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
