[ 
https://issues.apache.org/jira/browse/MESOS-4666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15148063#comment-15148063
 ] 

Anindya Sinha commented on MESOS-4666:
--------------------------------------

Yes, that would work as well for my specific use case. Providing the ratio of 
all resource names (via {{Offer::parameters}}) or a boolean flag 
{{Offer::whole_agent == true}} indeed gives the same info to the framework. 
However, is there a concern of exposing the ratio through in the offer, other 
than the fact that we have not identified a use case where it might be needed 
other than the case to represent if an offer denotes the complete slave or not.

Having said that, either of these 2 approaches do not have the issue that 
[~vinodkone] raised wherein total resources represent resources reserved by a 
framework of another role.

> Expose total resources of a slave in offer for scheduling decisions
> -------------------------------------------------------------------
>
>                 Key: MESOS-4666
>                 URL: https://issues.apache.org/jira/browse/MESOS-4666
>             Project: Mesos
>          Issue Type: Improvement
>          Components: general
>    Affects Versions: 0.25.0
>            Reporter: Anindya Sinha
>            Assignee: Anindya Sinha
>            Priority: Minor
>
> To effectively schedule certain class of tasks, the scheduler might need to 
> know not only the available resources (as exposed currently) but also the 
> maximum resources available on that slave. This is specifically true for 
> clusters having different configurations of the slave nodes in terms of 
> resources such as cpu, memory, disk, etc.
> Certain class of tasks might have a need to be scheduled on the same slave 
> (esp needing shared persistent volumes, MESOS-3421). Instead of dedicating a 
> slave to a framework, the framework can make a very good determination if it 
> had exposure to both available as well as total resources.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to