[
https://issues.apache.org/jira/browse/YARN-7127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16204792#comment-16204792
]
Allen Wittenauer commented on YARN-7127:
----------------------------------------
bq. 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).
bq. However for 'yarn service', it's the command to interact with the service
framework, i.e. the special AM we wrote.
Users don't care about the internals of a command. They want cohesion.
bq. there has to be a differentiator.
It seems as though a lot of the issues raised here are because the RM isn't
keeping track of which frameworks that YARN provides that a given application
is using or used to launch. This is a "record keeping" problem. Passing that
onto the user is going to be problematic when one considers that multiple users
may be interacting with a given AM.
If I'm the ops person that needs to take down a bad acting AM, why should I
have to cycle through a bunch of different commands to figure out which one
works when the RM should be able to provide a hint?
To expand on that:
bq. 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?
Not all command line arguments actually have to work with every AM type. If a
user gives a nonsense request, it's ok to throw a helpful message and error
out. Not everything needs to succeed. In this particular case, the command
should be asking the RM if the given AM was started with the services API and
act appropriately. If not, throw an error.
bq. it seems more of a larger umbrella effort - expanding "yarn application"
to provide a unified support for all disparate apps to roll into it.
e.g., what should have been part of this project from the start. To me, this
is a showstopper issue for the "native services" API. In it's current
incarnation, it definitely feels bolted on rather than real functionality
included as part of YARN.
Just for completeness:
bq. 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?
Apples and oranges and completely ignoring the historical context involved.
[I'd expand on the history here, but it is sort of an orthogonal discussion.
If anyone cares, I can write up though.]
I will say that given hindsight, I'm fairly confident that the mapred command
wouldn't exist and almost all of the features it provides would either not
exist or be merged into the yarn command somewhere.
> 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, YARN-7127.04.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
