[ 
https://issues.apache.org/jira/browse/YARN-6069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15869865#comment-15869865
 ] 

Varun Saxena edited comment on YARN-6069 at 2/16/17 12:54 PM:
--------------------------------------------------------------

Now coming to the patch, the thing we have to consider is that we already have 
yarn timeline-service related CORS configurations. So if somebody looks at it, 
they may think this has to be used for ATSv2 too. Please note that we reuse 
most of the existing ATSv1 configurations for ATSv2 too (wherever possible).
However, as ATSv2 is a new system, so we can decide what to use. We can use 
either old timeline service configurations(as we did in 1st patch) or reuse 
existing http CORS configurations (as in 2nd patch).
The advantage of first is that if we are using same config file for multiple 
modules; and if we want to enable/disable CORS for ATS or use different set of 
allowed headers, irrespective of what is configured for other modules, we can 
do it.
This however is not a use case for us as we use distinct set of config files 
for each module. 
So I am fine with either.

I am -0 on what has been done in 2nd patch. Therefore, we can go with the 
majority opinion here.
If majority wants to go with approach in 2nd patch, I would suggest to have a 
link to HTTP Authentication page's CORS section in timeline service HTML page's 
CORS section telling user to refer to other CORS related configurations there, 
in addition to the config for enabling and disabling it, already mentioned in 
md file in the patch.



was (Author: varun_saxena):
Now coming to the patch, the thing we have to consider is that we already have 
yarn timeline-service related CORS configurations. So if somebody looks at it, 
they may think this has to be used for ATSv2 too. Please note that we reuse 
most of the existing ATSv1 configurations for ATSv2 too (wherever possible).
However, as ATSv2 is a new system, so we can decide what to use. We can use 
either old timeline service configurations(as we did in 1st patch) or reuse 
existing http CORS configurations (as in 2nd patch).
The advantage of first is that if we are using same config file for multiple 
modules; and if we want to enable/disable CORS for ATS or use different set of 
allowed headers, irrespective of what is configured for other modules, we can 
do it.
This however is not a use case for us as we use distinct set of config files 
for each module. 
So I am fine with either.

I am -0 on what has been done in 2nd patch. Therefore, we can go with the 
majority opinion here.
If majority wants to go with approach in 2nd patch, I would suggest to link 
HTTP Authentication page's CORS section in timeline service HTML page telling 
user to refer to other CORS related configurations in addition to enabling and 
disabling it.


> CORS support in timeline v2
> ---------------------------
>
>                 Key: YARN-6069
>                 URL: https://issues.apache.org/jira/browse/YARN-6069
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: timelinereader
>            Reporter: Sreenath Somarajapuram
>            Assignee: Rohith Sharma K S
>         Attachments: YARN-6069-YARN-5355.0001.patch, 
> YARN-6069-YARN-5355.0002.patch
>
>
> By default the browser prevents accessing resources from multiple domains. In 
> most cases the UIs would be loaded form a domain different from that of  
> timeline server. Hence without CORS support, it would be difficult for the 
> UIs to load data from timeline v2.
> YARN-2277 must provide more info on the implementation.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

---------------------------------------------------------------------
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