[
https://issues.apache.org/jira/browse/YARN-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14588487#comment-14588487
]
Wangda Tan commented on YARN-1197:
----------------------------------
Thanks [~mding],
I think (c) sounds like a very good proposal, it has advantages
- Latency is better than (a) (If we assume network conditions between
AM-RM/RM-NM are same, since RM send response to NM at the same heartbeat).
- Doesn't expose container token, etc. to AM when increase approved which is
not necessary, AM only needs to poll NM about status of changing resource.
- It can be considered as an additional step of (b). ((c) = (b) +
rm_response_to_am_when_increase_approved + am_poll_nm_about_increase_status).
Good for planning as well.
bq. We can have option (b) enabled by default, and use a configuration
parameter to turn on option (c) for framework like Spark.
I think the two can be enabled together, I don't see any conflict between them,
AM can poll NM if it doesn't want to wait another NM-RM heartbeat.
Thoughts? [~sandyr], [~vinodkv].
> Support changing resources of an allocated container
> ----------------------------------------------------
>
> Key: YARN-1197
> URL: https://issues.apache.org/jira/browse/YARN-1197
> Project: Hadoop YARN
> Issue Type: Task
> Components: api, nodemanager, resourcemanager
> Affects Versions: 2.1.0-beta
> Reporter: Wangda Tan
> Attachments: YARN-1197 old-design-docs-patches-for-reference.zip,
> YARN-1197_Design.pdf
>
>
> The current YARN resource management logic assumes resource allocated to a
> container is fixed during the lifetime of it. When users want to change a
> resource
> of an allocated container the only way is releasing it and allocating a new
> container with expected size.
> Allowing run-time changing resources of an allocated container will give us
> better control of resource usage in application side
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
