[
https://issues.apache.org/jira/browse/YARN-689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13663217#comment-13663217
]
Alejandro Abdelnur commented on YARN-689:
-----------------------------------------
[~hitest], in my use case, the AM is requesting resources for external services
running side to side with yarn nodes. These services are not controlled by
yarn. The AM is effectively only reserving capacity for these services.
Containers are started to keep the current yarn resource/container lifecycle
intact, but this containers do absolutely nothing (ie 'cat -'), all the
allocated resources are used out of band from YARN. These external services
manage memory and CPU completely independent of each other, thus forcing it to
request 1GB or 1CPU when it does not use is a significant waste. Thus, in this
scenario a minimum of zero is required (for strictly enforcing memory/cpu via
cgroups, this would be address with a minimum bump when the resource is set to
zero, ie for cgroup cpu shares, assigning 10 shares).
> Add multiplier unit to resourcecapabilities
> -------------------------------------------
>
> Key: YARN-689
> URL: https://issues.apache.org/jira/browse/YARN-689
> Project: Hadoop YARN
> Issue Type: Bug
> Components: api, scheduler
> Affects Versions: 2.0.4-alpha
> Reporter: Alejandro Abdelnur
> Assignee: Alejandro Abdelnur
> Attachments: YARN-689.patch, YARN-689.patch, YARN-689.patch
>
>
> Currently we overloading the minimum resource value as the actual multiplier
> used by the scheduler.
> Today with a minimum memory set to 1GB, requests for 1.5GB are always
> translated to allocation of 2GB.
> We should decouple the minimum allocation from the multiplier.
> The multiplier should also be exposed to the client via the
> RegisterApplicationMasterResponse
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
