----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/59147/#review176726 -----------------------------------------------------------
src/master/http.cpp Lines 4477-4487 (patched) <https://reviews.apache.org/r/59147/#comment250179> You have this same logic in lambda callbacks just before both of the `_startMaintenance` callsites. Is there any reason you couldn't move this into `_startMaintenance` and make use of `defer` here, to eliminate the need for a lambda? src/master/http.cpp Lines 4482-4483 (patched) <https://reviews.apache.org/r/59147/#comment250173> Following on my previous comment regarding calls to `approved` which return an error: let's try to establish some consistent endpoint behavior when authorization attempts return an error. I think that the approach that you use here seems reasonable: if any authorization request returns an error, then fail the request. But if we do this here, we should probably do it elsewhere as well. I don't think the behavior of the endpoint when all authorization requests are successful should influence its behavior in the presence of an error from the authorizer. i.e., this endpoint has all-or-nothing authorization semantics when all authorization requests succeed, and GET_MAINTENANCE_STATUS has filtering-type semantics when all authorization requests succeed. However, I would argue that they should both have the same semantics in the presence of errors from the authorizer. WDYT? src/master/http.cpp Lines 4483 (patched) <https://reviews.apache.org/r/59147/#comment250174> If we return an error here, could you add some helpful output to the message? i.e., ``` return InternalServerError( "Error when authorizing: " + approved.error()); ``` src/master/http.cpp Lines 4597-4598 (patched) <https://reviews.apache.org/r/59147/#comment250177> Ditto here regarding error semantics and the error message. src/master/http.cpp Lines 4675-4685 (patched) <https://reviews.apache.org/r/59147/#comment250180> Ditto regarding moving this logic into `_stopMaintenance`. - Greg Mann On June 1, 2017, 2:57 p.m., Alexander Rojas wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/59147/ > ----------------------------------------------------------- > > (Updated June 1, 2017, 2:57 p.m.) > > > Review request for mesos, Adam B, Greg Mann, and Till Toenshoff. > > > Bugs: MESOS-7415 > https://issues.apache.org/jira/browse/MESOS-7415 > > > Repository: mesos > > > Description > ------- > > Enables the use of authorization for the `START_MAINTENANCE` and > `STOP_MAINTENANCE` v1 API calls, using the ACLs `StartMaintenance` > and `StopMaintenance` respectively as well the actions of the same > name as the API calls. > > It also updates the ApiTests to take into account the authorization > case. > > > Diffs > ----- > > src/master/http.cpp 7060b8fa53e0682681c50e051908ffbbf50fb7da > src/tests/api_tests.cpp faf3242f9c86d866c4bb5e457fcfe47c1063cc09 > > > Diff: https://reviews.apache.org/r/59147/diff/4/ > > > Testing > ------- > > make check > > > Thanks, > > Alexander Rojas > >
