[
https://issues.apache.org/jira/browse/YARN-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Varun Vasudev updated YARN-1702:
--------------------------------
Attachment: apache-yarn-1702.11.patch
{quote}
1. There're lot of formatting changes in TestRMWebServicesApps, which seem no
to be necessary, and affect review.
{quote}
My apologies - I’ve fixed this.
{quote}
2. "getAppState" seem not to be necessary, as we have "getApp", which returns a
full report including the state.
3. I'm not sure it is good idea to have a "updateAppState" API, but only allow
to change the state to KILLED. Why not having "killApp" directly, and accepting
an appId?
+ @PUT
+ @Path("/apps/\{appid\}/state")
+ @Produces(\{ MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML \})
+ @Consumes(\{ MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML \})
+ public Response updateAppState(AppState targetState,
+ @Context HttpServletRequest hsr, @PathParam("appid") String appId)
+ throws AuthorizationException, YarnException, InterruptedException,
+ IOException \{
{quote}
It’s generally not REST-ful to have APIs such as /kill. The current
implementation also makes it easier to support future state changes(if we ever
allow users to have more fine grained control of app state). With respect to
getAppState, I wanted to provide a equivalent GET for the PUT so that users
could just get the state, modify and send a PUT request.
{quote}
4. We should make killApp work in insecure mode as well, as we can do it via
PRC.
{quote}
Given the current implementation of YARN web security(admins can enable
security but the security for web consoles has to enabled separately), I’m not
sure this is a good idea.
{quote}
5. In YarnClientImpl, we have implemented the logic to keep sending the kill
request until we get confirmed that the app is killed. IMHO, as the user of
REST API should be a thin client, we may want to implement this logic at the
server side, blocking the response until we confirm that the app is killed. In
RPC we have limited the number of concurrent threads. However, at the web side,
we don't have this limitation, right?
{quote}
I’d like to avoid taking up threads which can potentially sit idle while the
kill is being executed.
{quote}
6. As to the authentication filter, I think it's not just the problem of
killApp, the whole RM web is unprotected, but we can handle this issue
separately. Some lessons from implementing security for the timeline server:
a) It's better to have separate configs for RM only, and load the
authentication filter for RM daemon only instead of all.
b) RM may also want
Kerberos + DT authentication style.
{quote}
Thanks for the pointers. I’ll keep it in mind for supporting delegation tokens.
> Expose kill app functionality as part of RM web services
> --------------------------------------------------------
>
> Key: YARN-1702
> URL: https://issues.apache.org/jira/browse/YARN-1702
> Project: Hadoop YARN
> Issue Type: Sub-task
> Reporter: Varun Vasudev
> Assignee: Varun Vasudev
> Attachments: apache-yarn-1702.10.patch, apache-yarn-1702.11.patch,
> apache-yarn-1702.2.patch, apache-yarn-1702.3.patch, apache-yarn-1702.4.patch,
> apache-yarn-1702.5.patch, apache-yarn-1702.7.patch, apache-yarn-1702.8.patch,
> apache-yarn-1702.9.patch
>
>
> Expose functionality to kill an app via the ResourceManager web services API.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
