mesos-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benjamin Mahler (JIRA)" <>
Subject [jira] [Updated] (MESOS-8237) Strip Resource.allocation_info for non-MULTI_ROLE schedulers.
Date Tue, 28 Nov 2017 23:16:00 GMT


Benjamin Mahler updated MESOS-8237:
    Summary: Strip Resource.allocation_info for non-MULTI_ROLE schedulers.  (was: Resource.allocation_info
should be stripped for non-MULTI_ROLE schedulers.)

> Strip Resource.allocation_info for non-MULTI_ROLE schedulers.
> -------------------------------------------------------------
>                 Key: MESOS-8237
>                 URL:
>             Project: Mesos
>          Issue Type: Bug
>            Reporter: James DeFelice
>            Assignee: Benjamin Mahler
>              Labels: mesosphere
> In support of MULTI_ROLE capable frameworks, a Resource.allocation_info field was added
and the Resource math of the Mesos library was updated to check for matching allocation_info
when checking for (in)equality, addability, subtractability, containment, etc. To compensate
for these changes, the demo frameworks of Mesos were updated to set the allocation_info for
Resource objects during the "matching phase" in which offers' resources are evaluated in order
for the framework to launch tasks. The Mesos demo frameworks NEEDED to be updated because
the Resource algebra within Mesos now depended on matching allocation_info fields of Resource
objects when executing algebraic operations. See
> This poses a unique problem for **external** libraries that both aim to support various
frameworks, some that DO and some that DO NOT opt-in to the MULTI_ROLE capability; specifically
those external libraries that implement Resource algebra that's consistent with what Mesos
implements internally. One such example of a library is mesos-go, though there are undoubtedly
others. The problem can be explained via this scenario: 
> {quote}
> Flo's mesos-go framework is running well, it doesn't opt-in to MULTI_ROLE because it
doesn't need multiple roles. His framework runs on a version of Mesos that existed prior to
integration of MULTI_ROLE support. His DC operator upgrades the mesos cluster to the latest
version. Flo rebuilds his framework on the latest version of mesos-go and re-launches it on
the cluster. He observes that his framework receives offers, but rejects ALL of them. Digging
into the code he realizes that Mesos is injecting allocation_info into Resource objects being
offered to his framework, and mesos-go considers allocation_info when comparing Resource objects
(because it's MULTI_ROLE compatible now), but his framework doesn't take this into consideration
when preparing its own Resource objects prior to the "resource matching phase". The consequence
is that Flo's framework is trying to match against Resources that will never align because
his framework isn't setting an allocation_info that might possibly match the allocation_info
that Mesos is always injecting - regardless of the MULTI_ROLE capability (or lack thereof
in this case) of his framework.
> {quote}
> If Mesos were to strip the allocation_info from Resource objects, prior to offering them
to non-multi-role frameworks, then the problem illustrated above would go away.

This message was sent by Atlassian JIRA

View raw message