[MESOS-4385] Offers and InverseOffers cannot be accepted in the same ACCEPT call

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Resolved
• Affects Version/s: 0.25.0
• Component/s: framework, master
• Labels: maintenance mesosphere
• Target Version/s: 0.28.0
• Epic Link: Maintenance
• Story Points: 2
• Assignee: Joseph Wu
• Reporter: Joseph Wu
• Shepherd: Benjamin Mahler
• Created: 14/Jan/16 21:32
• Updated: 26/Nov/18 12:43
• Resolved: 26/Nov/18 12:43

Description

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?

Issue Links

• is related to: MESOS-4301 Accepting an inverse offer prints misleading logs
• is related to: MESOS-5296 Split Resource and Inverse offer protobufs for V1 API