[jira] [Commented] (MESOS-9313) Document speculative offer operation semantics for framework writers.

["Benno Evers (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/MESOS-9313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16809972#comment-16809972 ] 

Benno Evers commented on MESOS-9313:
------------------------------------

I'm not so sure that framework authors can just treat this as an opaque implementation detail, because I'd assume the `reason` field would be different between a task launching on reserved resources that were not reserved on the agent, and a task failing for other reasons.

Additionally, I think it's just better user experience to get people to understand *why* certain state transitions can happen, as opposed to just saying nothing is ever certain so deal with it.

That said, it doesn't look like anyone is currently working on this so I'm removing the 1.8 target version designation from this task.

> Document speculative offer operation semantics for framework writers.
> ---------------------------------------------------------------------
>
>                 Key: MESOS-9313
>                 URL: https://issues.apache.org/jira/browse/MESOS-9313
>             Project: Mesos
>          Issue Type: Documentation
>          Components: documentation
>            Reporter: James DeFelice
>            Priority: Major
>              Labels: mesosphere, operation-feedback, operations
>
> It recently came to my attention that a subset of offer operations (e.g. RESERVE, UNRESERVE, et al.) are implemented speculatively within mesos master. Meaning that the master will apply the resource conversion internally **before** the conversion is checkpointed on the agent. The master may then re-offer the converted resource to a framework -- even though the agent may still not have checkpointed the resource conversion. If the checkpointing process on the agent fails, then subsequent operations issued for the falsely-offered resource will fail. Because the master essentially "lied" to the framework about the true state of the supposedly-converted resource.
> It's also been explained to me that this case is expected to be rare. However, it *can* impact the design/implementation of framework state machines and so it's critical that this information be documented clearly - outside of the C++ code base.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)