----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/61183/#review184751 -----------------------------------------------------------
src/slave/slave.hpp Lines 658 (patched) <https://reviews.apache.org/r/61183/#comment260963> I am not sure if keeping another field just for resoruce provider provided resources in the agent is a good idea or not. I'd much prefer we keep a single `totalResources` for regular resources (both resource provider provided or not), and `oversubscribedResources` only for oversubsribed resources. src/slave/slave.cpp Lines 1361 (patched) <https://reviews.apache.org/r/61183/#comment260956> is it possible that agent is terminating? src/slave/slave.cpp Lines 1370 (patched) <https://reviews.apache.org/r/61183/#comment260955> what about checkpointed resources? I think we need to use `totalResources` (with checkpointed reosurces applied) here. Also, i checked the master handler for `UpdateSlaveMessage`. Should we rescind offer too (like the oversubscription case)? Add a TODO there? - Jie Yu On Sept. 6, 2017, 2:52 p.m., Benjamin Bannier wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/61183/ > ----------------------------------------------------------- > > (Updated Sept. 6, 2017, 2:52 p.m.) > > > Review request for mesos, Jie Yu and Jan Schlicht. > > > Repository: mesos > > > Description > ------- > > The agent's resource provider manager sends a > 'ResourceProviderMessage' when its managed resources change. This > commit adds handling in the agent so that an 'UpdateSlaveMessage' is > sent to the master to update the total resource available on the > agent. We also store this total in the agent memory so that it can be > resent on agent resubscription. > > In order to provide push-like handling of the resource provider > manager's message queue, we chain recursive calls to the handler for > continuous processing. Initially, processing is kicked off from > 'Slave::initialize'. In this simple implementation we e.g., provide no > direct way to stop processing of messages, yet, but it can be achieved > by e.g., replacing the manager with a new instance (this would also > require updating routes). > > Since the agent can only send an 'UpdateSlaveMessage' when it is > registered with a master, a simple back-off of 5 s is implemented which > will defer processing of a ready message should the agent not yet have > registered. > > To facilitate logging we add a stringification function for > 'ResourceProviderMessage's. > > > Diffs > ----- > > src/resource_provider/message.hpp 916926bf278de9ed919384a82a452d3ced06bd04 > src/slave/slave.hpp 7d07868451e93d34ba694d40216c1e4036fd4094 > src/slave/slave.cpp df920ec07cd59c7ba6baccfc1c20ed3809f187d6 > src/tests/slave_tests.cpp 1bdadce4c50cbff958f2be2a4261e130b414acfd > > > Diff: https://reviews.apache.org/r/61183/diff/5/ > > > Testing > ------- > > `make check` > > > Thanks, > > Benjamin Bannier > >
