[
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:55 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, for NM and RM we do not use RM/NM specific configurations. 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. Also it is somewhat unlikely somebody would enable CORS filter
for one module and not for other.
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 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.
> 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
