Uploaded image for project: 'Mesos'
  1. Mesos
  2. MESOS-8626

The 'allocatable' check in the allocator is problematic with multi-role frameworks

    XMLWordPrintableJSON

    Details

    • Target Version/s:
    • Sprint:
      Mesosphere Sprint 2018-21, Mesosphere Sprint 2018-22, Mesosphere Sprint 2018-23
    • Story Points:
      3

      Description

      The allocatable 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.

      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);
      }
      

      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. This is counter intuitive.

      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));
      }
      

      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

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                bbannier Benjamin Bannier
                Reporter:
                jieyu Jie Yu
                Shepherd:
                Jie Yu
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: