[jira] [Updated] (MESOS-8237) Strip Resource.allocation_info for non-MULTI_ROLE schedulers.
[ https://issues.apache.org/jira/browse/MESOS-8237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Mahler updated MESOS-8237: --- Target Version/s: 1.3.2, 1.4.2, 1.5.0 > Strip Resource.allocation_info for non-MULTI_ROLE schedulers. > - > > 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 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)
[jira] [Updated] (MESOS-8237) Strip Resource.allocation_info for non-MULTI_ROLE schedulers.
[ https://issues.apache.org/jira/browse/MESOS-8237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] 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: 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 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)