[
https://issues.apache.org/jira/browse/YARN-7218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16252723#comment-16252723
]
Eric Yang commented on YARN-7218:
---------------------------------
[~billie.rinaldi] This is good practice to add root level wrapper to help
developer to understand the context of the returning json. For large scale
project which involves a lot of entities, it would be easier to manage with
high level wrapper to indicate the data payload. For YARN, at this time, there
are custom resolvers for each of the web application that is attached to
resource manager, node manager, and application history server. The change
does not affect timeline service, or web proxy by unit test and manual
inspection. Hence, it seems like a good time to add this to avoid having to
add custom resolver per web application. I agree that
YarnJacksonJaxbJsonProvider change is optional, and can be removed on request.
> ApiServer REST API naming convention /ws/v1 is already used in Hadoop v2
> ------------------------------------------------------------------------
>
> Key: YARN-7218
> URL: https://issues.apache.org/jira/browse/YARN-7218
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: api, applications
> Reporter: Eric Yang
> Assignee: Eric Yang
> Attachments: YARN-7218.001.patch, YARN-7218.002.patch,
> YARN-7218.003.patch
>
>
> In YARN-6626, there is a desire to have ability to run ApiServer REST API in
> Resource Manager, this can eliminate the requirement to deploy another daemon
> service for submitting docker applications. In YARN-5698, a new UI has been
> implemented as a separate web application. There are some problems in the
> arrangement that can cause conflicts of how Java session are being managed.
> The root context of Resource Manager web application is /ws. This is hard
> coded in startWebapp method in ResourceManager.java. This means all the
> session management is applied to Web URL of /ws prefix. /ui2 is independent
> of /ws context, therefore session management code doesn't apply to /ui2.
> This could be a session management problem, if servlet based code is going to
> be introduced into /ui2 web application.
> ApiServer code base is designed as a separate web application. There is no
> easy way to inject a separate web application into the same /ws context
> because ResourceManager is already setup to bind to RMWebServices. Unless
> ApiServer code is moved into RMWebServices, otherwise, they will not share
> the same session management.
> The alternate solution is to keep ApiServer prefix URL independent of /ws
> context. However, this will be a departure from YARN web services naming
> convention. This can be loaded as a separate web application in Resource
> Manager jetty server. One possible proposal is /app/v1/services. This can
> keep ApiServer code modular and independent from Resource Manager.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
