Mailing-List: contact issues-help@mesos.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@mesos.apache.org
Date: Tue, 28 Nov 2017 03:14:00 +0000 (UTC)
From: "Benjamin Mahler (JIRA)" <jira@apache.org>
To: issues@mesos.apache.org
Message-ID: <JIRA.13118644.1510778908000.330411.1511838840044@Atlassian.JIRA>
In-Reply-To: <JIRA.13118644.1510778908000@Atlassian.JIRA>
References: <JIRA.13118644.1510778908000@Atlassian.JIRA> <JIRA.13118644.1510778908551@jira-lw-us.apache.org>
Subject: [jira] [Updated] (MESOS-8237) Mesos injects
 Resource.allocation_info for all resource offers, regardless of MULTI_ROLE
 opt-in
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Tue, 28 Nov 2017 03:14:05 -0000


     [ https://issues.apache.org/jira/browse/MESOS-8237?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:all-tabpanel ]

Benjamin Mahler updated MESOS-8237:
-----------------------------------
    Sprint: Mesosphere Sprint 69

> Mesos injects Resource.allocation_info for all resource offers, regardles=
s of MULTI_ROLE opt-in
> -------------------------------------------------------------------------=
----------------------
>
>                 Key: MESOS-8237
>                 URL: https://issues.apache.org/jira/browse/MESOS-8237
>             Project: Mesos
>          Issue Type: Bug
>            Reporter: James DeFelice
>            Assignee: Benjamin Mahler
>              Labels: mesosphere
>
> In support of MULTI_ROLE capable frameworks, a Resource.allocation_info f=
ield was added and the Resource math of the Mesos library was updated to ch=
eck for matching allocation_info when checking for (in)equality, addability=
, subtractability, containment, etc. To compensate for these changes, the d=
emo frameworks of Mesos were updated to set the allocation_info for Resourc=
e objects during the "matching phase" in which offers' resources are evalua=
ted in order for the framework to launch tasks. The Mesos demo frameworks N=
EEDED to be updated because the Resource algebra within Mesos now depended =
on matching allocation_info fields of Resource objects when executing algeb=
raic operations. See https://github.com/apache/mesos/commit/c20744a9976b5e8=
3698e9c6062218abb4d2e6b25#diff-298cc6a77862b7ff3422cd06c215ef28R91 .
> This poses a unique problem for **external** libraries that both aim to s=
upport 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 oth=
ers. The problem can be explained via this scenario:=20
> {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 oper=
ator upgrades the mesos cluster to the latest version. Flo rebuilds his fra=
mework 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. D=
igging into the code he realizes that Mesos is injecting allocation_info in=
to Resource objects being offered to his framework, and mesos-go considers =
allocation_info when comparing Resource objects (because it's MULTI_ROLE co=
mpatible 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 Resource=
s that will never align because his framework isn't setting an allocation_i=
nfo that might possibly match the allocation_info that Mesos is always inje=
cting - regardless of the MULTI_ROLE capability (or lack thereof in this ca=
se) of his framework.
> {quote}
> If Mesos were to strip the allocation_info from Resource objects, prior t=
o offering them to non-multi-role frameworks, then the problem illustrated =
above would go away.


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)