----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/63731/#review192104 -----------------------------------------------------------
src/slave/slave.cpp Lines 6900 (patched) <https://reviews.apache.org/r/63731/#comment270131> See my comments in https://reviews.apache.org/r/63843/ What if both the RP and the agent knows about the operation, and RP sends an update total due to speculation failure? This needs more thinking. Any reason not let agent/master knows about the latest state of the offer operation. Is the intention here to rely on status update manager to send the status update? At the very least, let's document this scenario. - Jie Yu On Nov. 28, 2017, 9:32 p.m., Benjamin Bannier wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/63731/ > ----------------------------------------------------------- > > (Updated Nov. 28, 2017, 9:32 p.m.) > > > Review request for mesos, Greg Mann, Jie Yu, and Jan Schlicht. > > > Bugs: MESOS-8207 > https://issues.apache.org/jira/browse/MESOS-8207 > > > Repository: mesos > > > Description > ------- > > When resource providers update their state they send a list of > pending or unacknowledged operations to the agent. This patch add > tracking for such operations to the agent. The agent can then forward > these operations to the master, e.g., for calculating the unused > resources behind an agent. > > We track an operation until we either receive a updated list of > pending or unacknowledged operations from a resource provider, or > until we see an acknowledgement from a framework. This keeps the list > of operations bounded and ensures that we maintain the latest > information in the agent. > > > Diffs > ----- > > src/slave/slave.cpp cd716476dfad619dc6cf7449a32a27842efbe7fb > > > Diff: https://reviews.apache.org/r/63731/diff/6/ > > > Testing > ------- > > `make check`, tested as part of https://reviews.apache.org/r/63843/. > > > Thanks, > > Benjamin Bannier > >
