----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/63622/#review190323 -----------------------------------------------------------
src/resource_provider/manager.cpp Lines 430 (patched) <https://reviews.apache.org/r/63622/#comment267608> `Call.UpdateOfferOperationStatus.latest_status` is `optional`; we should check if it is set before using it. src/resource_provider/message.hpp Lines 51 (patched) <https://reviews.apache.org/r/63622/#comment267609> Since we seem to mirror `Call.UpdateOfferOperationStatus` pretty closely here, let's use an `Option<OfferOperationStatus> latestStatus`. src/resource_provider/message.hpp Lines 80 (patched) <https://reviews.apache.org/r/63622/#comment267610> We should implement this. src/slave/slave.cpp Lines 6823-6824 (patched) <https://reviews.apache.org/r/63622/#comment267612> Let's remove the reference to `used` from the comment. src/slave/slave.cpp Lines 6847 (patched) <https://reviews.apache.org/r/63622/#comment267613> Let's do a contains check before the substraction. src/slave/slave.cpp Lines 6855 (patched) <https://reviews.apache.org/r/63622/#comment267615> Let's not use `default` when switching over enum values; please enumerate all possible values instead. src/slave/slave.cpp Lines 6861-6865 (patched) <https://reviews.apache.org/r/63622/#comment267616> It seems this would mean that we drop status updates when we are in these states which doesn't sound great. We do not start handling resource provider messages before we entered a running state, but could enter another state later. Given that we don't have a status update manager for offer operation status messaes yet, I believe it might make sense to fail over the agent should we enter any of these states and add a `TODO` to revisit this code once we can reliably deliver status updates. src/tests/resource_provider_manager_tests.cpp Lines 319 (patched) <https://reviews.apache.org/r/63622/#comment267617> I believe we could we could use a `MockResourceProvider` here to simplify the test a bit. src/tests/resource_provider_manager_tests.cpp Lines 376 (patched) <https://reviews.apache.org/r/63622/#comment267618> Not sure we need this, but if you want to keep it let's make it an `ASSERT` on the value from the `event` instead of going through the assignment. - Benjamin Bannier On Nov. 7, 2017, 3:20 p.m., Jan Schlicht wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/63622/ > ----------------------------------------------------------- > > (Updated Nov. 7, 2017, 3:20 p.m.) > > > Review request for mesos, Benjamin Bannier and Jie Yu. > > > Repository: mesos > > > Description > ------- > > When a resource provider has finished an offer operation, it will send > a status update to the resource provider manager and subsequently to an > agent. The agent then updates its internal bookkeeping and forwards the > status update to the master. > > > Diffs > ----- > > src/resource_provider/manager.cpp a878507d71a09a415d8a4573cf2b33c26c985451 > src/resource_provider/message.hpp 3c7c3f2baeb726e04edd6ffbb9784699d7afe521 > src/slave/slave.hpp df1b0205124555dcb6a0efa5c237f5e77fa2bdf7 > src/slave/slave.cpp c10823985154bac19f8952b94311a03b2b9b4ea1 > src/tests/resource_provider_manager_tests.cpp > 4008b1c751d6227b99adef756e95174d7d8a62f2 > > > Diff: https://reviews.apache.org/r/63622/diff/1/ > > > Testing > ------- > > make check > > > Thanks, > > Jan Schlicht > >
