[ 
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)

Reply via email to