mesos-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anindya Sinha (JIRA)" <>
Subject [jira] [Commented] (MESOS-4666) Expose total resources of a slave in offer for scheduling decisions
Date Tue, 16 Feb 2016 04:02:18 GMT


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:
>             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

View raw message