But as a note, I would recommend against relying on updated timestamps,
because the clocks may not be synchronized in the system.
On Wed, Oct 1, 2014 at 12:33 PM, Benjamin Mahler benjamin.mah...@gmail.com
wrote:
Updated timestamps will be generated.
On Tue, Sep 30, 2014 at 6:21 AM, Whitney
Yes, only the TaskID is required. The SlaveID is optional and will lead to
a better response rate from the Master.
Good to see these questions, I will be working on some reconciliation
documentation before the 0.21.0 release, your feedback on it would be
appreciated!
On Sun, Oct 5, 2014 at 9:43
Updated timestamps will be generated.
On Tue, Sep 30, 2014 at 6:21 AM, Whitney Sorenson wsoren...@hubspot.com
wrote:
That makes sense and I suppose your first sentence was the real
summary/confirmation of the change in 0.20 that I was looking for.
A quick question - can we trust that the
That makes sense and I suppose your first sentence was the real
summary/confirmation of the change in 0.20 that I was looking for.
A quick question - can we trust that the taskStatus objects sent as a
result of calling reconciliation themselves are the exact same object as
was (possibly) sent
We want reconciliation to be a process that eventually terminates.
In = 0.19.0, the following two cases are conflated through no update being
sent:
(1) No state difference.
(2) Master temporarily cannot reply / dropped message.
As a result, a scheduler cannot determine when it is finished
I'm trying to understand the changes in
https://issues.apache.org/jira/browse/MESOS-1453 and the SchedulerDriver
JavaDoc.
In the 0.19 behavior, it made sense to me that a framework would hold onto
a copy of all the latest task statuses it knew about, and could poll
reconcileTasks with these
6 matches
Mail list logo
