Joseph Wu created MESOS-4385: -------------------------------- Summary: Offers and InverseOffers cannot be accepted in the same ACCEPT call Key: MESOS-4385 URL: https://issues.apache.org/jira/browse/MESOS-4385 Project: Mesos Issue Type: Bug Components: framework, master Affects Versions: 0.25.0 Reporter: Joseph Wu Assignee: Joseph Wu
*Problem* * In {{Master::accept}}, {{validation::offer::validate}} returns an error when an {{InverseOffer}} is included in the list of {{OfferIDs}} in an {{ACCEPT}} call. * If an {{Offer}} is part of the same {{ACCEPT}}, the master sees {{error.isSome()}} and returns a {{TASK_LOST}} for normal offers. (https://github.com/apache/mesos/blob/fafbdca610d0a150b9fa9cb62d1c63cb7a6fdaf3/src/master/master.cpp#L3117) Here's a regression test: https://reviews.apache.org/r/42092/ *Proprosal* The question is whether we want to allow the mixing of {{Offers}} and {{InverseOffers}}. Arguments for mixing: * The design/structure of the maintenance originally intended to overload {{ACCEPT}} and {{DECLINE}} to take inverse offers. * Enforcing non-mixing may require breaking changes to {{scheduler.proto}}. Arguments against mixing: * Some semantics are difficult to explain. What does it mean to supply {{InverseOffers}} with {{Offer::Operations}}? What about {{DECLINE}} with {{Offers}} and {{InverseOffers}}, including a "reason"? * What happens if we presumably add a third type of offer? * Does it make sense to {{TASK_LOST}} valid normal offers if {{InverseOffers}} are invalid? -- This message was sent by Atlassian JIRA (v6.3.4#6332)