----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/62636/#review191707 -----------------------------------------------------------
src/resource_provider/daemon.cpp Lines 78 (patched) <https://reviews.apache.org/r/62636/#comment269590> This line is not needed. Mostly for consistence reason, you don't see this pattern of `nullptr` initializing anything, in this case default constructing a pointer sets it to `nullptr` but also not adding it to the initializer list will default construct it to `nullptr` src/resource_provider/daemon.cpp Lines 112 (patched) <https://reviews.apache.org/r/62636/#comment269591> From the code here is not clear who owns the instance of `secretGenerator`. The fact that it is a private attribute tells me it is owned by this process, but it doesn't delete it on destruction. If you go for it, there should be a comment on why is it ok not to destroy this instance and why is not a memory leak, but really what you want is to use a managed pointer even if it is a const reference to an existing one. check `process::Owned`. I'm not so sure if we can now use `std::unique_ptr` or `std::shared_ptr`. src/resource_provider/daemon.cpp Lines 237 (patched) <https://reviews.apache.org/r/62636/#comment269593> We don't make use of the booleaness of pointers. Replace with `secretGenerator == nullptr`. Also Tthe code is more readable if you do: ```c++ if (secretGenerator == nullptr) { return None(); } ... ``` Since you don't have to go to the end of the code to see what happens in the `else` case (which is only one line), and you save yourself one indentation, which with 80 characters is a great compromise. src/resource_provider/daemon.cpp Lines 253 (patched) <https://reviews.apache.org/r/62636/#comment269594> This is a personal preference, but I don't see the reason to add more strings to a string which most likely already says it failed to validate a secret. You could just do `return error.get()`. src/resource_provider/storage/provider.cpp Lines 104 (patched) <https://reviews.apache.org/r/62636/#comment269595> is there any situatio when the `authToken` is `None`? - Alexander Rojas On Nov. 21, 2017, 1:10 a.m., Chun-Hung Hsiao wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/62636/ > ----------------------------------------------------------- > > (Updated Nov. 21, 2017, 1:10 a.m.) > > > Review request for mesos, Alexander Rojas, Greg Mann, Jie Yu, and Joseph Wu. > > > Bugs: MESOS-8100 > https://issues.apache.org/jira/browse/MESOS-8100 > > > Repository: mesos > > > Description > ------- > > `LocalResourceProviderDaemon` now uses `Slave::secretGenerater` to > generate an authentication token for each local resource provider. The > authentication token can then be used to call the V1 agent API. In order > to generate the tokens, `LocalResourceProviderDaemon::load()` is now an > asynchronous function. > > > Diffs > ----- > > src/resource_provider/daemon.hpp ef6c356cb6ddb2594d767d7dd6052e9fd8df8263 > src/resource_provider/daemon.cpp d584eb9d7aa75522aec97277674321061b90fbed > src/resource_provider/local.hpp ebaa07d03ad77d516066ee2d4b60864be0611b5f > src/resource_provider/local.cpp ad98f333c5668ca81de6e7ed3fc8f59323b151da > src/resource_provider/storage/provider.hpp > 6de88c2329b358fcf48bc39ddda0132170991c3c > src/resource_provider/storage/provider.cpp > 46224997430ac0c568904d80014166a6f059907f > src/slave/slave.cpp d8edc5e6bbfa265bca4d19bbaa7db3063949dbc0 > > > Diff: https://reviews.apache.org/r/62636/diff/8/ > > > Testing > ------- > > make > > > Thanks, > > Chun-Hung Hsiao > >
