----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/39988/#review108510 -----------------------------------------------------------
src/master/http.cpp (lines 1037 - 1040) <https://reviews.apache.org/r/39988/#comment167962> Let's not lose the comment on the left. src/master/http.cpp (lines 1037 - 1041) <https://reviews.apache.org/r/39988/#comment167963> It looks like the `repair` here is to catch the case where `authorizeReserveResources` __fails__ on an invalid reserve request. In https://reviews.apache.org/r/39987/ I asked whether the validation step needs to be within the authorization step. I still think it should be separated. If we were to separate them out, with Jie's suggestion below in mind, this could look like: ```cpp return master->authorizeReserveResources(operation, principal) .then(defer(master->self(), [=](bool authorized) -> Future<Response> { if (!authorized) { return Unauthorized("Mesos master"); } Option<Error> error = validation::operation::validate(operation.reserve(), None(), principal); if (error.isSome()) { return BadRequest("Invalid RESERVE operation: " + error.get().message); } return _operation(slaveId, resources.flatten(), operation); })); ``` src/master/http.cpp (lines 2307 - 2317) <https://reviews.apache.org/r/39988/#comment167965> With Jie's suggestion, we don't need this anymore. However, I would like to point out some weirdness here for future reference. Since the `_operation` is only being used with `.then` or in a direct call, the `authorized` can/should be `bool` rather than `Future<bool>`. Take a look at `_teardown`. The reason this works as-is is because `bool` is implicitly convertible to `Future<bool>`. With that in mind, we can then observe that the `if (!authorized.isReady())` is actually dead code. Whatever error handling that was intended to be done in that if-clause actually gets caught by the `repair` above instead. - Michael Park On Nov. 30, 2015, 8:46 p.m., Greg Mann wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/39988/ > ----------------------------------------------------------- > > (Updated Nov. 30, 2015, 8:46 p.m.) > > > Review request for mesos, Adam B, Jie Yu, Michael Park, and Till Toenshoff. > > > Bugs: MESOS-3062 > https://issues.apache.org/jira/browse/MESOS-3062 > > > Repository: mesos > > > Description > ------- > > Added authorization for dynamic reservation master endpoints. > Note: this review is continued from https://reviews.apache.org/r/37126/ > > > Diffs > ----- > > src/master/http.cpp 9d729ef7f7d7ad6185934648f833e4f8a4f0a123 > src/master/master.hpp 96951e766de32842197506504e5ac67a2caa3efe > src/tests/reservation_endpoints_tests.cpp > f30ff8bc6a3e9773437fa7fd7c8f569b7d7e2d9d > > Diff: https://reviews.apache.org/r/39988/diff/ > > > Testing > ------- > > This is the fourth in a chain of 5 patches. Added new reservation endpoints > tests to validate authorization of reserve and unreserve operations using > ACLs. `make check` was run to test after all patches were applied. > > > Thanks, > > Greg Mann > >
