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)
