[
https://issues.apache.org/jira/browse/YARN-7127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16200955#comment-16200955
]
Jian He commented on YARN-7127:
-------------------------------
[~eyang], This is just one of the reasons. There more reasons from design point
of view.
Let's look at what 'yarn application' subcommand stands today:
It's the command to interact with *ResourceManager* which does listing /
updating of application *metadata* to YARN's point of view. Although it's
called application, It's *NOT* a command specific to the app. (i.e. AM).
However for 'yarn service', it's the command to interact with the *service
framework*, i.e. the special AM we wrote.
E.g. MapReduce is a customized AM on YARN, it has its own *mapred* command to
interact with its own AM, which only makes sense to itself. like "mapred
distcp". Will it make sense to merge the 'distcp' sub command to 'yarn
application' command?
Similarly, for service framework, it's a special AM. It has its own semantics
and use cases.
E.g. flex the component count, upgrade the component. The component is the
concept only specific to service, not to the yarn generic app. If we merge it
with generic "application" command, what will the 'component' mean for other
apps like MR? There will be many other use cases that will only make sense to
this service framework. Hence, this is the concept separation.
So your previous comment below is not true, other than launching/shutdown,
there are whole bunch other concepts/operations only applicable to this service
framework.
bq. The only distinction is the launching and shutdown of services may be
different from batch jobs.
=====================
Now coming to the feasibility of the implementation of the approach. Even
though it's merged to application subcommand, how are we going to
differentiate the generic app and the service app from CLI. E.g. the yarn
application -status is getting the *metadata* of YARN, but the "yarn service
status" command is supposed to get the status of the service AM. Are we going
to add an option say "-type service" ? Ultimately, you still end up having the
separation, it cannot be avoided.
> Merge yarn-native-service branch into trunk
> -------------------------------------------
>
> Key: YARN-7127
> URL: https://issues.apache.org/jira/browse/YARN-7127
> Project: Hadoop YARN
> Issue Type: Sub-task
> Reporter: Jian He
> Assignee: Jian He
> Attachments: YARN-7127.01.patch, YARN-7127.02.patch,
> YARN-7127.03.patch
>
>
--
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
