James DeFelice created MESOS-8237:
-------------------------------------
Summary: Mesos injects Resource.allocation_info for all resource
offers, regardless 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
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
https://github.com/apache/mesos/commit/c20744a9976b5e83698e9c6062218abb4d2e6b25#diff-298cc6a77862b7ff3422cd06c215ef28R91
.
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
(v6.4.14#64029)
