Adam Antal commented on YARN-10215:

The Java part:
- The endpoints in {{LogServlet}} are used already, so we cannot change the 
default behaviour (and their return value), which would break compatibility. So 
the return value of the functions {{LogServlet#getContainerLogsInfo}} and 
{{LogServlet#getLogFile}} should be the same as before (redirect). Keep in mind 
that users can use these UIs without CORS protection, in which scenario the 
servlet is functioning properly with redirect. 
- So what I'd suggest is to add a {{QueryParam}} that would change the return 
value of the request (307 (temporary redirect) to 206 (partial content) if it 
is specified, otherwise just redirect). I think the switch between response 
types can be implemented in the new {{LogServlet#createLocationResponse}} 

The JS part:
- The main logic in {{controllers/yarn-app/logs.js}} seems good to me. Good job!
- If you've tested this patch in a real cluster then I'm assured the conditions 
work fine. Due to the miscellaneous behaviour of JS comparisons, I'd also add a 
{{headers['location'] !== "null"}} part to the condition of the 
{{handleResponse}} functions just to be sure.
- {{createEmptyContainerLogInfo}} can be moved to an util class, and you can 
reference it from there.

> Endpoint for obtaining direct URL for the logs
> ----------------------------------------------
>                 Key: YARN-10215
>                 URL: https://issues.apache.org/jira/browse/YARN-10215
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: yarn
>    Affects Versions: 3.3.0
>            Reporter: Adam Antal
>            Assignee: Andras Gyori
>            Priority: Major
>         Attachments: YARN-10025.001.patch
> If CORS protected UIs are set up, there is an issue when the browser tries to 
> access the logs of a running container in the RM web UIv2.
> Assuming ATS is not up, the browser follows the following call chain:
> - Tries to access ATS, it fails, falls back to JHS
> - From RM the browser received basic app info, we know that the application 
> is running
> - From the JHS we got the list of containers and their log files.
> - When we try to access a specific log file, the JHS redirects the request to 
> the NM's UI (on which node the container is running). This redirect is 
> performed by the browser automatically. In this setup the host is considered 
> as a protected information, thus the browser omits the "Origin" field from 
> the request when this redirect is done. The browser then denies access to the 
> NodeManager's web UI due to the CORS header set up for NM, but the Origin is 
> null in the redirect request. 
> - Finally, "Logs are unavailable" message is shown in the RM web UIv2 due to 
> the CORS violation.
> We should fix this. As an approach we can expose another endpoints which only 
> returns the URL of the NodeManager what we should call directly from the UIv2 
> in order to receive the log. This adds a bit of a complexity, but will enable 
> users to keep the CORS protected setup.

This message was sent by Atlassian Jira

To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org

Reply via email to