[
https://issues.apache.org/jira/browse/YARN-7218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16247767#comment-16247767
]
Eric Yang edited comment on YARN-7218 at 11/10/17 4:58 PM:
-----------------------------------------------------------
Service REST API was written to use Jackson natural serialization format to
serialize and deserialize entities. Some of the entity classes make use of
generic type such as Map in the object. ResourceManager's REST API has a
custom provider {{JAXBContextResolver}} to provide hints on how to serialize
object. The entire {{/ws/\*}} servlet is controlled by the custom resolver,
and this prevents Service REST API entity object from serialize properly due to
use of generic type maps. If we do not change data model for Service REST API,
then we must move Service REST API outside of /ws/* prefix to provide a
separate servlet and initialize Jersey with separate set of configuration to
enable Jackson natural serialization format. This reopens the dialog of how to
choose prefix properly for REST API for YARN because this change will breaks
existing format of using {{/ws/v1/\*}} for YARN REST API. For dealing with
large scale project, it is often recommended to use
{{resource_prefix}}/{{version}}/{{resource}}. Where resource_prefix is name
branding that has specific reference. Where YARN "ws" stands for webservices,
this prefix has been overloaded with various version of REST API of not related
functions. If we are designing the convention of next generation REST API for
YRAN, in order to support generic type entities. We should discuss the URL
format to keep majority of API format more less consistent.
was (Author: eyang):
Service REST API was written to use Jackson natural serialization format to
serialize and deserialize entities. Some of the entity classes make use of
generic type such as Map in the object. ResourceManager's REST API has a
custom provider {{JAXBContextResolver}} to provide hints on how to serialize
object. The entire {{/ws/*}} servlet is controlled by the custom resolver, and
this prevents Service REST API entity object from serialize properly due to use
of generic type maps. If we do not change data model for Service REST API,
then we must move Service REST API outside of /ws/* prefix to provide a
separate servlet and initialize Jersey with separate set of configuration to
enable Jackson natural serialization format. This reopens the dialog of how to
choose prefix properly for REST API for YARN because this change will breaks
existing format of using {{/ws/v1/*}} for YARN REST API. For dealing with
large scale project, it is often recommended to use
[resource_prefix]/[version]/[resource]. Where resource_prefix is name branding
that has specific reference. Where YARN "ws" stands for webservices, this
prefix has been overloaded with various version of REST API of not related
functions. If we are designing the convention of next generation REST API for
YRAN, in order to support generic type entities. We should discuss the URL
format to use for future proof.
> 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
>
> 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: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
