[
https://issues.apache.org/jira/browse/YARN-937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alejandro Abdelnur updated YARN-937:
------------------------------------
Attachment: YARN-937.patch
Updated patch fixing typos and making sure the jobtoken file written by the
UnmanagedAMLauncher is readonly by the current user (in addition to the
original behavior of being deleted on JVM exit).
bq. Not quite sure why we have manually use the RM address to re-create the
token....
We need to get the scheduler HOST:PORT to set the service name, from the
ClientRMProxy we can not get it, can we? In the case of failover, if we use the
same patterns/logic as HDFS failover, instead having concrete HOST:PORT
services, we will have logical names that will be resolve appropriately
(commented on similar topic in YARN-701 earlier today).
bq. If the queue ACL's give identical access...
We can do that. However, as I see it, being able to schedule resources should
be done by the AM process itself and only it. the ACLs are for who/what can
manage the AM. (while we can not prevent an AM to to pass the token to another
process and then have 2 processes doing scheduling for the same AM, this will
definitely break the AMs. But we cannot stop this from happening if somebody is
doing something stupid. The best we can do is to check it the same user).
bq. Should we return AMRMToken in getApplicationReport() only if the
currentAppAttempt is in a waiting to register state? ...
Unless I'm missing something, these initial AM state transitions happen in the
RM without interaction from the AM, we cannot guarantee the AM will query the
RM on that particular state. Thus returning it when in RUNNING is safe. We
could return it only once, but that would mean we have to keep track of that on
the RMAppImpl. And what is there is a failure on the AM before it manages to
'save' it, and the AM needs to re-get it?
bq. Similarly the AMLauncher could delete the token file after the app has
entered running state based on getApplicationReport()?
This would mean the AMLauncher would have to have a callback from the forked AM
process. And still the window of existence of the file is there, so you are
still 'vulnerable' to that file being stolen. The current patch, as mentioned
above makes this file user readable only.
> Fix unmanaged AM in non-secure/secure setup post YARN-701
> ---------------------------------------------------------
>
> Key: YARN-937
> URL: https://issues.apache.org/jira/browse/YARN-937
> Project: Hadoop YARN
> Issue Type: Bug
> Affects Versions: 2.1.0-beta
> Reporter: Arun C Murthy
> Assignee: Alejandro Abdelnur
> Priority: Blocker
> Fix For: 2.1.0-beta
>
> Attachments: YARN-937.patch, YARN-937.patch, YARN-937.patch,
> YARN-937.patch
>
>
> Fix unmanaged AM in non-secure/secure setup post YARN-701 since app-tokens
> will be used in both scenarios.
--
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
