[jira] [Commented] (MESOS-8626) The 'allocatable' check in the allocator is problematic with multi-role frameworks

["Benjamin Bannier (JIRA)" <ji...@apache.org>]

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

Benjamin Bannier commented on MESOS-8626:
-----------------------------------------

Linking MESOS-8935 which as I was told should introduce a way for frameworks to communicate their minimum requirements for each resource kind. Solving this issue likely needs to wait until the infrastructure from MESOS-8935 is in place.

We could in principle still apply the patch from https://reviews.apache.org/r/67344/ as a short-term solution, though, so I am leaving it open for now.

> The 'allocatable' check in the allocator is problematic with multi-role frameworks
> ----------------------------------------------------------------------------------
>
>                 Key: MESOS-8626
>                 URL: https://issues.apache.org/jira/browse/MESOS-8626
>             Project: Mesos
>          Issue Type: Bug
>          Components: allocation
>    Affects Versions: 1.3.2, 1.4.1, 1.5.0
>            Reporter: Jie Yu
>            Assignee: Benjamin Bannier
>            Priority: Major
>              Labels: mesosphere, multitenancy
>
> The [allocatable|https://github.com/apache/mesos/blob/1.5.x/src/master/allocator/mesos/hierarchical.cpp#L2471-L2479] check in the allocator (shown below) was originally introduced to help alleviate the situation where a framework receives only disk, but not cpu/memory, thus cannot launch a task.
> {code}
> bool HierarchicalAllocatorProcess::allocatable(
>     const Resources& resources)
> {
>   Option<double> cpus = resources.cpus();
>   Option<Bytes> mem = resources.mem();
>   return (cpus.isSome() && cpus.get() >= MIN_CPUS) ||
>          (mem.isSome() && mem.get() >= MIN_MEM);
> }
> {code}
> When we introduce multi-role capability to the frameworks, this check makes less sense now. For instance, consider the following case:
> 1) There is a single agent and a single framework in the cluster
> 2) The agent has cpu/memory reserved to role A, and disk reserved to B
> 3) The framework subscribes to both role A and role B
> 4) The framework expects that it'll receive an offer containing the resources on the agent
> 5) However, the framework receives no disk resources due to the following [code|https://github.com/apache/mesos/blob/1.5.x/src/master/allocator/mesos/hierarchical.cpp#L2078-L2100]. This is counter intuitive.
> {code}
> void HierarchicalAllocatorProcess::__allocate()
> {
>   ...
>   Resources resources = available.allocatableTo(role);
>   if (!allocatable(resources)) {
>     break;
>   }
>   ...
> }
> bool Resources::isAllocatableTo(
>     const Resource& resource,
>     const std::string& role)
> {
>   CHECK(!resource.has_role()) << resource;
>   CHECK(!resource.has_reservation()) << resource;
>   return isUnreserved(resource) ||
>          role == reservationRole(resource) ||
>          roles::isStrictSubroleOf(role, reservationRole(resource));
> }
> {code}
> Two comments:
> 1) If `allocatable` check is still necessary (see MESOS-7398)?
> 2) If we want to keep `allocatable` check for the original purpose, we should do that based on framework not role, given that a framework can subscribe to multiple roles now?
> Some related JIRAs:
> MESOS-1688
> MESOS-7398



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)